@rithviknishad @nihal467 @Ashesh3 The issue being session expired page navigates to "/" and then since the session has expired it loads the session expired page again anyway which again navigates to "/", If the token is invalid i don't understand the need for checking the IsAuthenthicated and returning a navigate.

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1905578260

```js export default function SessionExpired() { const { signOut, user } = useAuthContext(); const isAuthenticated = Boolean(user); const navigate = useNavigate(); const { t } = useTranslation(); useEffect(() => { Notification.closeAllNotifications(); }, []); if (isAuthenticated) { navigate("/"); } ``` The bug seems to be due to the navigate("/") and i cannot understand why we need it? If the session has expired do we not wish to log the user out on the same page and show session expired with a return to login?

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1900417872

@rithviknishad The tests should work now.

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1890354031

Done! used the `devdistrictadmin` login instead.

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1888494639

Yep that too works.

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1888489999

Okay, found it! The staffdev login isn't available in the [dummy data](https://github.com/coronasafe/care/blob/master/data/dummy/users.json) that's loaded to the backend. Also there is just a devstaff2 username in the dummy data, no devstaff / devstaff1? The password on there is encrypted so do we proceed by adding a devstaff to the dummy data? or is the login info for devstaff2 noted somewhere?

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1888483982

I don't understand why the tests are failing with a POST 401 on github actions  The same tests pass on local 

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1887885806

> @Om-Thorat > > Didn't this one line change ([#6911 (comment)](https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1868988181)) alone solve the original issue? Was there some other issues? I did change the line to that but there had to be the reserved URLs change because of that rest much isn't changed.

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1869986212

@rithviknishad This new function works with both the redirect param and the direct urls , When an invalid redirect param is provided with a valid base url, The app chooses to discard the param and simply navigate to the valid base url Instead. The session expired redirects to the redirect param if available. It seems like there should be a test for the redirect param as well?

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1869402860

Sorry for the oversight before added a check to ensure that the redirect param redirects to a site that has the same origin as the current site, Not using this could have let malformed urls to be able to redirect to any sites they please ,potentially malicious.

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1869346102

> You could do the following: > > 1. If a redirect query param is present, use that. (Same as original implementation). > > 2. If redirect query param is not present, simply call the `signIn` method from `useAuth` when the login button is clicked without doing a navigate. (Since it's very likely that the we need to land in the current route itself, just that we need to cause a re-render the AuthProvider component. as required clicking on the button signs out and redirects to the page which then loads a login screen since the user is signed out, In the other case that a query param isn't present the url will just be `/session-expired` which should redirect to ` /`?

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1869003456

> So that means, the only code change required to fix this would be: The new redirector function doesn't check for a redirect param anymore so, There'll be that to fix as well

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1868998334

> Now that you've removed the support for `redirect` param completely, the "Session Expired" workflow wouldn't work this way right, since that still relies on the `redirect` param on the login page route? Hmm, How do we plan on dealing with that? Should we just redirect them to the same page and bring up the login screen?

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1868980508

not sure why run failed since it passed on local, looking into it. 

https://github.com/coronasafe/care_fe/pull/6911#issuecomment-1868975268

Great! I'll get to it

https://github.com/coronasafe/care_fe/issues/6900#issuecomment-1868945881

@rithviknishad This is a code design decision seems like the component expects an extra ?redirect= param at the end of string to redirect to, This isn't needed since the login page is shown on the same url that the user intends to go to. One way would be to redirect to the login page with a redirect param or another easier way might be to just use current url and just redirect to that after login.

https://github.com/coronasafe/care_fe/issues/6900#issuecomment-1868934714

@rithviknishad Can you assign this to me? ```tsx const getRedirectURL = () => { return new URLSearchParams(window.location.search).get("redirect"); }; ``` The problem is probably the getRedirectURL function which always returns null

https://github.com/coronasafe/care_fe/issues/6900#issuecomment-1868929531