i'd recommend reaching out to support@workos.com. they would be able to say precisely where emails are getting hung up. i've shared this comment with them and they're eager to help.
say more about your concern. there aren’t any strict one-app limitations. if this is regarding the root level callback uri, you can organize those routes as needed
FWIW, this is all server side. Getting signout via client component took some sorting out. This should be clearer in docs. (Also passing user props to client, etc).
whoa. that's wild. can you ensure that the callback url is the same in the WorkOS/Redirects, and in your .env file? it sounds to me like it's trying to callback to the wrong url.
Hey Awesome Vide. Auth is one of the stages of a product. Can you create a video, lets say once the user is logged in and I want to save the user to a database and then perform actions on the users. For example, lets say a shooping app with users saving/wishlisting their items, how do I link the authenticated user stored in a dabatase and perform this action Would love to see such videos
consider to add side effect fn after successful callback in handleAuth (currently the opt only exposing redirectPathname). you never know what developer actually want after successfully handling "auth callback"
also, idk is it just my app is configured wrong or bug. in the latest release (v0.5.3) i experienced redirect loop after signing in with oauth via authkit.
Haven't watched the video yet but it's definitely something I'm going to get into if my little demo app needs to get real. Which by the way could work and look wonders with WorkOS's Radix Themes as well.
AuthKit is a fully hosted service. That said, the underlying system (WorkOS User Management) can be integrated with NextAuth. workos.com/docs/user-management/authkit
@@fagnersales532 1) Fully Customizable theme 2) No more clock skew error bullshit in development like clerk 3) easy to integrate db alongside auth flow
I don’t like the idea of collocating auth checks on the pages themselves. It would be very easy to forget to protect a page. It happens all the time to the best of us. Particularly at the API level where it’s harder to detect that you accidentally made it public. I would lock everything down with middleware and then only white list the pages you want to be public.
RSCs for React Native should help make this more possible. At the moment, it might make the most sense to use a native library for auth and utilize the underlying WorkOS User Management system: workos.com/docs/user-management/authkit
while we don't maintain i library for flutter, you can use the underlying WorkOS User Management features with flutter-based auth libraries. workos.com/docs/user-management/authkit
