I’m a product manager here at Auth0, working with the team that manages rules, hooks, and other forms of custom code in Auth0. We’re looking to talk to people in our community to find out what you love and don’t love about Rules & Hooks, and all the ways you’re using them to create authentication experiences for your users.
We’d love to hear about your implementations, frustrations, victories, and dreams. If you’d like to talk with the Auth0 team about Rules & Hooks, please give us some feedback in the comments below.
If you’d like to speak one-on-one, you can use this link to reserve some time on my calendar. We’re looking forward to hearing from you!
We would really like the ability to return back custom response codes from our pre-registration hook. No matter whether our APIs return a 409, 404, 400, or 500, the pre-registration hook will only bubble up a 500. This makes it impossible for us to notify our users of custom issues they are having with their sign up process. I.E. 409, a user with this information already exists in our CRM system.
We would also very much like the ability to use custom logging, without calling an external API, available in the pre-registration hooks. Right now, the only way to catch hard to debug errors, is to sit and watch the real-time task viewer and hope the issue occurs. Events with, ‘ESOCKETTIMEOUT did you forget to call the callback?’ are not helpful to us, especially when that only occurs 1 out of 500 requests, and the rest of the downstream microservices do not report any issues. We have seen many instances of users successfully signing up, appearing in our CRM system, appearing in our POS software at the stores, and yet, Auth0 returns that error and no user is created there.
I find it frustrating that the version of the node-auth0 provided within the Rule environment is behind the latest release provided by NPM. I would find this less frustrating (and understandable, don’t want to be changing versions and breaking things) if I were able to ‘require’ the most recent release manually. However according to the documentation the latest release isn’t even available to manually require.
It seems error messages are becoming a bit of theme here.
With our rules, when a user isn’t authorized, we redirect them to an external error page. We do that because we don’t want each of our applications to have to handle errors themselves. That means, however, that those users will still be logged in to an Auth0 SSO session. For a lot of errors, that’s fine. If you’re not allowed to access Application A, you shouldn’t be entirely kicked out of your SSO session. However, with some errors (like “please verify your email first”), that results in users entering an endless loop: we can’t allow them to login, but we don’t have a way to log them out either.
It would be great if either (or both ):
We could force an SSO session to end from within a rule
We could throw error pages from within rules, instead of redirecting users to the application with an error and error_description.
):