Scenario: Hosted login pages, SPA application using Auth0.js, dotnet core serverside using Auth0ManagementApi
User logs in successfully and redirects back to our SPA
User sends info to our api, which then updates app_metadata for the user
Back in the SPA, we call renewAuth to get a fresh JWT
This, up until a few weeks ago, used to work. We’d get the fresh JWT with the updated app_metadata and life was good. Some time “recently” this broke, we are now getting login_required back from the renewAuth.
We’re not running against localhost - we’re using nameofproduct.test:8080
We’re not using social identity, so we’re not using any keys, developer or otherwise
Could this have been a v4 to v8 change?
How do we get renewAuth working again so we don’t have to send the user off to the login page to get a fresh JWT?
Hey there @danf, I would be happy to take a look at this with you. When you get a moment can you please record a HAR file of the broken workflow and direct message it over to me along with the tenant name? Please be sure to select “Preserve log” to catch redirects and scrub the file of user passwords before passing, thanks in advance!
I wanted to reach out and touchbase on this front @danf and see if you had a chance to capture your workflow when it’s demonstrating issues within a HAR file? Thanks!
I wanted to follow up @danf, when you get a chance can you go to Tenant settings>Advanced to activity timeout and require login after and share those values with us? We are currently looking into why you may be experiencing this challenge. Thanks in advance!
After further investigating the logs with our team, it appears that you are not only updating app_metadata, but also updating the users’ email addresses as well. When you update an email address it will result in the session no longer being valid and the user needing to log back in. When you get a chance can you give this a look @danf? Thanks!
We are? What in the heck?? I’ll give the server guys a good kicking if that is the case!
edit@James.Morrison if we are, we aren’t doing it deliberately. We’re constructing an Auth0.ManagementApi.Models.UserUpdateRequest and calling Auth0.ManagementApi.Clients.IUsersClient.UpdateAsync
var req = new UserUpdateRequest
{
Connection = _config.Connection,
EmailVerified = true,
AppMetadata = new { status = "active" }
};
var patchedUser = await _Client.Users.UpdateAsync(userId, req);
That’s about it. No updating the email address involved. Or none that I can see
Hi @danf, following up on this front you can see in the logs that there is a API call being made to reset the user’s email upon signup. Working with one of our team members we were able to capture a few screenshots that may aid you in your investigation that I will be direct messaging over to you as they contain sensitive information. Us having reviewed your rules you have in place it doesn’t appear to be the breaking point here, so this may be happening in your hooks if you have any created or within your application itself. As we don’t have direct access to ether of those, I would recommend reviewing those two possibilities. Please keep us posted with what you find, thanks!
For anyone googling this later, apparently setting email_verified via the API is considered a “change of email address” and thus the session is invalidated. Which I swear did not happen previously, but here we are
I was able to confirm you are correct @danf, this is a result of a recent change made. This concreted it so that a session is deleted any time where in the past it would have been previously updated.
I apologize for the confusion. To aid others who may experience the same problem in the future, I am going to move forward through documenting this with a FAQ. I will post it here in this thread once it’s complete.