Auth0 Home Blog Docs

Lock 11 not sending RedirectUri as referer header to authorize endpoint - sometimes


RedirectUri has been verified to be correctly added and protected in the Lock context’s state.

But looking at the GET headers from your Lock to your /authorize endpoint, the referer is simply “/” - missing the path. So when you callback, the location header to forward to is similarly root - instead of the controller path encoded initially in the Lock state.

Seems to be good for weeks, then suddenly it starts happening, meaning I simply can’t authenticate. I’m equally unsure as to how it starts working again days later. Cookie state, IISExpress quirk with Lock - any suggestions? When it works, I see the controller path correctly being sent to you, and coming back.

Seems to happen more on localhost deploy, but we’ve suffered this for about a year with no time to investigate deeply. We’ve seen similar on a deployed IISExpress website.

Happens on the two browsers I’ve tried - Chrome and Edge. I’ve stepped through lock.js as much as I can, but I guess the protected state is decoded by the browser code.

Code showing setting of RedirectUri: (.NET Core 1.1)

var properties = new AuthenticationProperties()
    ExpiresUtc = options.SystemClock.UtcNow.Add(options.RemoteAuthenticationTimeout),
    IsPersistent = true,
    RedirectUri = returnUrl ?? "/"   // E.g. /MainMap

lockContext.State = Uri.EscapeDataString(options.StateDataFormat.Protect(properties));

Hey there @Simon! I would be happy to take a look at this with you. When it’s in it’s unworking state, would it be possible to snag a HAR file for us and direct message it over to me? Please be sure to select “Preserve log” to catch redirects and scrub the file of user passwords before passing it over, thanks!


Sent. Thank you James.