https://www.ory.sh/ logo
Join Slack
Powered by
Hey friends, I just wanted to share that we recent...
# ory-network
t
Hey friends, I just wanted to share that we recently launched our Ory cloud integration @ zezam (-> https://my.zez.am/login). We decided to move from our internal solution to a managed/hosted solution mainly because we want auth to be mostly hands-off from our end. We're a relatively small team and need to spend our time on our core product, not already solved problems. We chose Ory for a couple of reasons; the main ones are that the headless integration points are what we're looking for and the pricing seems "fair". As an example, our usage patterns would put us into the Auth0 enterprise tier which starts at 2k p/m which is just ridiculous compared to our overall infrastructure costs. I'll share some things we noticed along the way in the thread ->
👍 1
🙌 4
- Importing existing users with hashed passwords worked perfectly 👍 - Implementing the self-service UI was a lot more difficult than expected. Mostly that was due to the API being inconsistent and/or non-intuitive at times, especially around error handling/messaging. The documentation was not always helpful. @helpful-table-77025 lead the implementation on our end and I'm sure she has a ton of insights on the topic. - Adding social login providers works like a charm for the "known" providers in the UI, but less so for generic providers. For example, I wasn't able to add Twitter or Instagram (which would be very important for our use case) because their flow is incompatible with what Ory expects. I think exposing all the available Kratos providers in the UI would go a long way. - Configuring custom emails is a bit clunky (i.e. takes some getting used to) but works perfectly in the end 👍 - Sending emails has a delay of 1-2 minutes, which is "acceptable" but not ideal. - Exposing logs or at least errors would make debugging much easier.
c
@thankful-dog-96817 did you try setting up your own email provider as well? I noticed a delay when using Amazon SES but I sort of just assumed it was SES related
t
yeah I did some testing and I'm reasonably confident that the delay is with ory. using the default sender has the same delay
whereas our sender has no delay at all from other sources
h
Thank you Dan, I love the message! Thank you for being a part of Ory 🙂 @magnificent-energy-493 maybe something to distill in a short blog post? (cc @orange-needle-13244)
Also cc @fast-lunch-54279 PTAL
- Sending emails has a delay of 1-2 minutes, which is “acceptable” but not ideal.
Are those sent from our domain or from your domain?
t
from our domain via https://postmarkapp.com/smtp-service. we use postmark for all our transactional emails, but only ory via smtp
h
I see, do you know if postmark has some type of queue that takes a bit? For our provider (mailgun) we get email delivery prety much instantaneously
t
I don't, but tbh it's not such a big deal that I want to spend a lot of time investigating right now. I did some quick testing and reverted back to the default sender and noticed the same delay, so my assumption is that the delay is with the app, not the sender
h
Ok I see, we’ll take this into consideration and see what’s going on there…
t
fwiw, https://console.ory.sh/recovery seems to have the same delay
at least it does for me. if it's fine for you the problem would be with gmail on the receiving end 🙃
h
- Exposing logs or at least errors would make debugging much easier.
Agree 100% - https://github.com/ory/cloud/issues/117
- Adding social login providers works like a charm for the “known” providers in the UI, but less so for generic providers. For example, I wasn’t able to add Twitter or Instagram (which would be very important for our use case) because their flow is incompatible with what Ory expects. I think exposing all the available Kratos providers in the UI would go a long way.
Also agree, we need to add those to the UI!
That’s really strange, for me it’s almost instantaneously. It takes about 10-15 seconds though
- Implementing the self-service UI was a lot more difficult than expected. Mostly that was due to the API being inconsistent and/or non-intuitive at times, especially around error handling/messaging. The documentation was not always helpful. @helpful-table-77025 lead the implementation on our end and I’m sure she has a ton of insights on the topic.
Thank you here too, and I definitely agree, this is way too complex at the moment. The problem is that a UI is not easy to write, you have so many different forms to cover (mfa, settings, login, login failed, mfa missing, mfa failed, …). I think we’ll advice our users in the future to use the managed UI. Also what we’re thinking of is to build a component library similar to stripe elements for react/angular/vue that brings these form elements out of the box
no, actually, you’re right, it does take it’s sweet time
t
the delay caused me massive headache when configuring smtp if you remember the thread from last week. I didn't expect it, so whenever I tried a new setting and got no email after waiting for like 10-15 seconds I assumed that the config was wrong
plus the fact that the UI always errors when a custom smtp is configured.... 🙃
h
ah yes…i see
plus the fact that the UI always errors when a custom smtp is configured.... 🙃
shit yes, I lost track of that, thank you for reminding me
ah no i didn’t it’s here: https://github.com/ory/cloud/issues/116 🙂
p
Agree on the UI development, it's really hard to be confident that you covered it all. What I did was manually test the nominal cases and redirect to the managed UI on any error as an escape hatch, but that would not be viable for a commercial product. I think a collection of flow responses covering all cases, as a repo of json files would have been very helpful. Turning it up to 11 would be having these responses served by a mocked kratos, wiring them up to different emails (eg. login with notverified@ory.sh to get a "need email verification" error), but that's a significant investment.
Could be a good ramp-up task for a new hire, for them to learn the Kratos flows and all the features 😉
h
Thank you Xavier, it’s indeed feedback with heard quite a lot and I remember it taking its sweet time to cover all the use cases. Regarding mocked Kratos, @proud-plumber-24205 had some ideas but it’s currently in the backlog. Definitely a good task for a new hire, although I even think that we could probably run a real kratos locally with the config from cloud so instead of mocking it, you get the real thing on your machine
we’ll most likely try to steer people to not bring their own UI for the time being, while we figure out a concept that is easier to work with
p
A kratos container with seeded settings and user database could indeed go a long way. The added value of a mocked endpoint would be to have stable flow IDs of each scenario. I can point my dev UI to that endpoint with flow ID 1234, and I can replay the same account recovery while iterating on my code.
h
I see, that makes sense indeed
p
The server could even validate the form submission, to confirm all required fields are present.
p
Adding to the mocking discussion. An idea for mocking would be to intercept the current API calls with expected responses through something like https://mswjs.io/. This would make integrating Ory pretty seamless since your UI team wouldn't need to setup complicated docker images or cli tools that require an Ory project. You can just develop all the flows with the expected responses and once complete, flip the switch to the real Ory project. This would also make testing your business logic easier in the CI, since you would just use the mocked APIs.
p
My project uses server-side (golang) templating with some JS progressive enhancement, so that would not for me; but I know I'm the weird one stuck in the 90s ;)
h
we’ll most likely try to steer people to not bring their own UI for the time being, while we figure out a concept that is easier to work with
~gets a mild heart attack 🥲 Hello everyone! First of all, thank you for your hard work and always being there with help 🙌 🍦 Implementing Ory with our UI was so complicated that I had to take a long vacay after 🥵 (jk, but I did take a long vacay after 😆). Talking about my experience implementing Ory UI from scratch: I could share my insights and pain points, but I assume the Ory team is well aware of them by now and has a lot of future plans to improve it. But let me know if it can help and I will get back to you, I do have a list 🙂 (and I did write a short documentation on Ory implementation for my team to help them to get around). I personally think the idea to have components like Stripe is a great solution. This way you can cover all the flows and error handling without page reload and without the need of the end user to search for edge cases and cover them.
h
@helpful-table-77025 sorry to hear that 😞 We are aware of the issues here, building it from scratch is a lot of work because the “state” behind a login ui is actually not as simple as one thinks when starting out. However, the good news is this: @proud-plumber-24205 has been working on an extremely exciting solution for this issue which works cross-framework in NodeJS / JS. They are re-usable components (like in React) and will solve a lot of the headaches you probably had!
h
That sounds great! Keep doing great work 🥹
h
It will be sort of like 
<Login showOnly="password"/>
drop-ins… 🙂
h
Wait, does it mean I will have to rewrite the whole UI again? help 😆
p
Hi @helpful-table-77025 Sorry about the frustrations 😔 As @high-optician-2097 said, I'm currently getting an Ory component library up and running which will also provide the complete experience out of the box with a singular component. I don't want to share too many details yet since this is still a work in progress, but here are a couple of examples:
Astro using Ory react components
Or maybe Preact is more your thing? 🙃
Wait, does it mean I will have to rewrite the whole UI again? help
No, not at all. The Api is not changing in this and this is only right now a focus for us to release a really good managed UI with a component library. This will enable you to integrate with Ory faster with just a couple of lines of code. At the end of the day we want to support many personas, basic functionality users and more advanced functionality users. This, however, takes time 🙂
h
Or maybe Preact is more your thing? 🙃
did that, had a lot of pain trying to make some non-compatible libraries to work, so no, not my thing 😄
but looking at your code from the screens — we did kind of the same approach, created some hooks and components 🤝
At the end of the day we want to support many personas, basic functionality users and more advanced functionality users. This, however, takes time 🙂
Absolutely! Looking forward to see the result! I am sure I missed a few edge cases. Also we don't have 2FA for now, so minus that flow 🙈
p
It would be great if we could get your feedback and experiences on this sometime, since this really helps improve. Maybe we could schedule a call sometime?
h
Sure, absolutely. I could share how I approached creating React components and what difficulties I faced in order to make it reusable and cover different usecases. I could show our code if @thankful-dog-96817 approves 🙈
p
You can use this link to book a meeting with me https://meetings-eu1.hubspot.com/alano If you don't find a suitable time here, just DM me with your preferred time 🙂
👍 1
t
yeah feel free to show code in screen share as long as there's no (prod) user data visible. also please don't record the screen share and/or take screenshots 🙏
👍 2
Open in Slack
PreviousNext
Powered by