-
Notifications
You must be signed in to change notification settings - Fork 353
Conversation
That's a problem because it crashes the component, but what it should do when given a bad token is just drop you to login.
8863b8c to
d7e2e12
Compare
rimashah25
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue has been fixed. The dashboard page no longer is seen if the user is unauthorized.
|
This is definitely still broken. Going to any page when unauthenticated will not bring you to the login screen. Not sure if login redirects are still broken as it's not properly moving. |
... that's the correct behavior, though, no? |
|
when not authenticated, woops edited. |
|
I can't reproduce that. I just opened it to http://localhost:4200/core/cdns in a new private browsing context and got redirected to login. What doesn't work is actually redirecting afterwards. Since the core module isn't loaded until after authentication, there is no routing available under |
|
I think you are correct, the issue I was seeing occurs when you leave TP open and let the cookie expire naturally. It will then redirect the user to |
Fixes #7317: Login redirect is broken because it can't handle query string parameters. This PR fixes it so unauthenticated users are directed back where they were trying to go after logging in.
Which Traffic Control components are affected by this PR?
What is the best way to verify this PR?
Assuming you have Traffic Ops running locally on port
6443, runng servein the TPv2 directory, then open the URL http://localhost:4200/core/servers?search=test in a new private browsing context (or just any context where you aren't already authenticated). It should send you back to the login page, then after logging in that should take you to the servers table with the search field set to the string "text".If this is a bugfix, which Traffic Control versions contained the bug?
PR submission checklist