Auth0 Home Blog Docs

Application Login URI field payload validation error for https://localhost:3000/authorize

I’m going through the quick start tutorial for Auth0 and setting up the callback URLs in my application settings. However, the Application Login URI field populated with http://localhost:3000/authorize causes an error while saving:

Error! Payload validation error: ‘Object didn’t pass validation for format absolute-uri-or-empty: https://localhost:3000/authorize’ on property initiate_login_uri (Initiate login uri, must be https and cannot contain a fragment).

It’s seems to work if a domain name is included in the name, e.g https://localhost.com:3000/authorize .

Am I mis-understanding the purpose of this field?

Hmmm let me dig into that @squirrel187 and get back to you with the info!

Hey there @squirrel187!

I’ve been told that when it comes to testing it with localhost it should be working without domain too. No idea why it’s happening like that. Does the error also occur when you paste the callback URL exactly as it is in the quickstart?

Hi @konrad.sopala ,

The quickstart only covers configuring the callback URLs under ‘Allowed Callback URLs’ , in which case entering localhost (without the .com) works fine. No problems there.

I should mention it’s also not a problem for the ‘Allowed Logout URLs’. https://localhost:44344 works fine for that.

It appears to only be a problem for the ‘Application Login URI’, which isn’t specifically covered in the quickstart.

1 Like

Got it! Thanks a lot for reporting that! Will pass it right away to the responsible team!

1 Like

Just want to add I’m having the exact same issue. Any update on this yet?

Hey there @bcronje!

Let me reping the team and get back to you soon!

Same issue here . When will be this fixed ? , I cant test and evaluate without this

I submitted internal ticket regarding that. Will let you know once i have some info back!

Folks try logging out and logging back in, that helped me. I mean in the Auth0 portal .

Does it have something to do with the first problem described in the thread?

May be , Not sure , I also tried putting in my real domain name in callback which starts with https://
and then saved , logged out , logged back in and then tried putting in http://localhost:3000 in callback and it took it …
Are you guys using some kind of event tracking system such as logrocket or sentry which will allow you too see exactly what happened.

Also seems like local state is probably not syncing with remote state or may be using some kind of optimistic ui .

aaaah got it! Thanks fr providing that context.

The engineering team responsible for that feature for sure has some tools implemented for monitoring this kind of situation. I will give them all that info and see what they find out!

I’m having the same issue. Trying to enter http://localhost:4000 for Application Login URI, and got

**Error!**  Payload validation error: 'Object didn't pass validation for format 
absolute-uri-or-empty: http://localhost:4000/login' on property initiate_login_uri 
(Initiate login uri, must be https and cannot contain a fragment).

I understand the purpose of the validation but I’m obviously using localhost for dev purposes and it should be allowed.

1 Like

I have this same problem. Tried the suggestion of logging out and logging back into the auth0 dash and that didn’t work for me. @konrad.sopala any resolution?

Same issue for myself, trying to follow the SPA Quickstart guide.

Having the same issue here. Trying to set http://localhost:8080/login for the Application Login URI.

Error displayed:

**Error!**  Payload validation error: 'Object didn't pass validation for format absolute-uri-or-empty: http://localhost:8080/login' on property initiate_login_uri (Initiate login uri, must be https and cannot contain a fragment).

Let me dig into it deeper once again discussing it with our engineering team directly. Can one of you send me via private message the HAR file while performing this action so we can see what happens behind the scenes of the browser when you do that? Here’s the instruction how to record that:

I still encountered this issue, but i was able to get around it by replacing localhost with 127.0.0.1, but it still requires you use https. Hope this is helpful

1 Like

Thanks a lot for sharing that knowledge @tunedev, nevertheless I will reach out to our engineering team to see what they have to share on that front!