# Classic Universal Login (/login) page returns 200 when given junk parameters **URL:** \ **Category:** Get Help\ **Tags:** login\ **Created:** [October 14, 2021, 9:25pm UTC](https://community.auth0.com/t/classic-universal-login-login-page-returns-200-when-given-junk-parameters/71357 "2021-10-14T21:25:11Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![cmcgowan](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/cmcgowan/32/31039_2.png) [@cmcgowan](https://community.auth0.com/u/cmcgowan)\ **Post date:** [October 14, 2021, 9:25pm UTC](https://community.auth0.com/t/classic-universal-login-login-page-returns-200-when-given-junk-parameters/71357/1 "2021-10-14T21:25:11Z")
A customer of ours raised an issue about being unable to login. After investigating, we found some strange behavior from Auth0 that we were not expecting. Would appreciate any insight you could give us on this situation and how to handle it. **Scenario:** We use a customized Classic Universal Login loaded at `https://MY_CUSTOM_DOMAIN.com/login`. I attempt to navigate to the login page but supply all junk data in the query parameters: `https://MY_CUSTOM_DOMAIN.com/login?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=X` **Expected Behavior** Either Auth0 shows an error page or else redirects me back to my default login URL as described here: [Configure Default Login Routes](https://auth0.com/docs/login/universal-login/configure-default-login-routes) **Actual Behavior** Auth0 loads the login page normally (200 response). Attempting to login from the page returns a 404 error from the `/usernamepassword/login` route. ---
**Author:** ![Ale](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/ale/32/50860_2.png) [@Ale](https://community.auth0.com/u/Ale)\ **Post date:** [October 14, 2021, 11:19pm UTC](https://community.auth0.com/t/classic-universal-login-login-page-returns-200-when-given-junk-parameters/71357/2 "2021-10-14T23:19:31Z")
Hey @cmcgowan, I’ve tried to reproduce the behaviour you are experiencing and described but had no success. After appending `/login?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=X` to my custom domain, I just get redirected to my default login route. You’ve mentioned that Auth0 loads the login page normally. I find that very confusing since using junk parameters won’t allow Auth0 to know which login page to actually serve. You really need to provide some of those parameters. When you say the login page was loaded, do you mean your Classic Universal Login page? From my point of view, that might not be possible with junk parameters. In addition to what I’ve said, the expected flow would be to call `/authorize` and not `/login`. This is documented on our [Authentication API documentation](https://auth0.com/docs/api/authentication#database-ad-ldap-passive-). Since all this don’t make much sense to me, I would suggest you [provide a HAR file](https://auth0.com/docs/troubleshoot/tools/generate-and-analyze-har-files) while reproducing the entire flow so I can take a deeper look at what’s going on there. Please, do not forget to remove any credentials, secrets or active/valid Access Tokens that might be found inside the HAR file. You can also DM me the HAR file if you are concerned about security/privacy. ---
**Author:** ![cmcgowan](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/cmcgowan/32/31039_2.png) [@cmcgowan](https://community.auth0.com/u/cmcgowan)\ **Post date:** [October 18, 2021, 11:13pm UTC](https://community.auth0.com/t/classic-universal-login-login-page-returns-200-when-given-junk-parameters/71357/3 "2021-10-18T23:13:37Z")
Hi @Ale, I will work on generating a HAR file and provide it soon. In the meantime, I can try to clarify some of the points you raised and provide some additional details. One potentially important bit I learned since posting – while we do have an Application Login URI set with our default login route, we **do not have** a tenant-wide route set in the Tenant Login URI field. To your question: Yes, I mean that the Classic Universal Login Page (which we have customized) is being loaded. I get a 200 response where the response body contains the same custom HTML that I can see when I got to the `Branding -> Universal Login -> Login` tab in the Tenant Dashboard. We are initiating our login flow using `/authorized` in the normal flow. Navigating directly to `/login` is definitely non-standard behavior. I only found out about this while reproducing an error raised by a user. The actual error scenario was more complicated, but the root issue is what I mentioned here. The real in-the-wild scenario that brought this to my attention: - We have a main production tenant, and also a second tenant used as a testing sandbox for clients integrating into our app - A user loaded the production app, which would make a call to `/authorize` then load the `/login` page - The user had intended to go to the sandbox application and could not login to the production app - Realizing their mistake, they manually changed the `MY_CUSTOM_DOMAIN` part of the URL to `MY_CUSTOM_DOMAIN_SANDBOX` without changing any of the parameters - The sandbox login page loaded but they still could not login or change their password, and the issue was escalated to me ---
**Author:** ![cmcgowan](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/cmcgowan/32/31039_2.png) [@cmcgowan](https://community.auth0.com/u/cmcgowan)\ **Post date:** [October 19, 2021, 5:03pm UTC](https://community.auth0.com/t/classic-universal-login-login-page-returns-200-when-given-junk-parameters/71357/4 "2021-10-19T17:03:43Z")
@Ale I have sent you a DM with the HAR file. It was generated starting from a blank incognito window and navigating directly to `https://MY_CUSTOM_DOMAIN.com/login?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=X` by pasting the URL. ---
**Author:** ![Ale](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/ale/32/50860_2.png) [@Ale](https://community.auth0.com/u/Ale)\ **Post date:** [October 26, 2021, 12:48am UTC](https://community.auth0.com/t/classic-universal-login-login-page-returns-200-when-given-junk-parameters/71357/5 "2021-10-26T00:48:48Z")
Thank you for the HAR file, @cmcgowan I understand now what you said with “the page loaded normally”. > [@cmcgowan](#): > > One potentially important bit I learned since posting – while we do have an Application Login URI set with our default login route, we **do not have** a tenant-wide route set in the Tenant Login URI field. This is basically the issue here. When using incorrect parameters, Auth0 does not know which application configuration/settings should be used. Since you don’t have any tenant-wide default route set up, there’s no possible redirection. The solution would be to implement a tenant-wide default login route then. Now, since we don’t show any error for this scenario, it’s true that the end result can be confusing for this specific scenario (users that don’t set up a tenant-wide default login route). I think this use case is not considered an error by design, but I personally can see room for improvement. I’d suggest sending your feedback to [https://auth0.com/feedback](https://auth0.com/feedback) to get this logged properly just in case Product agrees with you and decide to improve our solution based on your feedback. Thank you for bringing this to our attention. ---
**Author:** ![cmcgowan](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/cmcgowan/32/31039_2.png) [@cmcgowan](https://community.auth0.com/u/cmcgowan)\ **Post date:** [October 27, 2021, 5:10pm UTC](https://community.auth0.com/t/classic-universal-login-login-page-returns-200-when-given-junk-parameters/71357/6 "2021-10-27T17:10:21Z")
Thanks for the help @Ale . I think we have a good solution for now then, just by setting the tenant-wide route. I can make a Feedback post to get this considered for improvement as well. However, I do still have one quibble with your point “I think this use case is not considered an error by design”. If that is the truly case, then I think there is a disconnect between the app design and the documentation that would still constitute an issue rather than an improvement. Specifically, when reading the [Configure Default Login Routes](https://auth0.com/docs/login/universal-login/configure-default-login-routes) I saw this passage which contributed to my confusion and seems to run counter to your statement about the intended design: > Sometimes users bookmark the login page, and when they navigate to the bookmarked `/login` URL, the transaction record is no longer there and Auth0 cannot continue with the login flow. In that case, Auth0 will redirect to the default client URL if configured, or the tenant level URL if not. **If no default login URL is set, Auth0 will render an error page.** ---
**Author:** ![Ale](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/ale/32/50860_2.png) [@Ale](https://community.auth0.com/u/Ale)\ **Post date:** [October 28, 2021, 2:15am UTC](https://community.auth0.com/t/classic-universal-login-login-page-returns-200-when-given-junk-parameters/71357/7 "2021-10-28T02:15:49Z")
Hey, thank you for your response, @cmcgowan ! What you said made sense to me so I’ve been doing some testing and these are the outcomes when using **no** _Tenant Login URI_: 1. New Universal Login: 1.1 . Calling `/authorize?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=X` returns an error page as expected. 1.2 . Caling `/login?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=X` returns an error page as expected. 2. Classic Universal Login: 2.1 . Calling `/authorize?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=X` returns an error page as expected. 2.2 . Calling `/login?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=X` **shows a blank page**. There’s clearly a mismatch when comparing the New Universal Login experience to the Classic Universal Login experience. Also, it’s true that what we say in our documentation is not what happens when calling the `/login` endpoint under the Classic UL experience. I will report this to our Engineering team so they can hopefully add this to their backlog. Thank you again for reporting it!!! ---
**Author:** ![system](https://global.discourse-cdn.com/auth0/original/3X/b/5/b560f266932fcce5d57f09a6595bd50518cae3f3.jpeg) [@system](https://community.auth0.com/u/system)\ **Post date:** [November 12, 2021, 2:16am UTC](https://community.auth0.com/t/classic-universal-login-login-page-returns-200-when-given-junk-parameters/71357/8 "2021-11-12T02:16:25Z")
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.