jack-brinkman
commented
2 years ago Here are my 2 cents, as per Javier's request :)
1. Logged in status is not picked by event system
I've encountered this issue before. oidc-client-ts stores the authenticated user details in sessionStorage rather than localStorage, meaning that if the tab is closed & reopened, the user details are lost (despite the fact that the user is still authenticated from CAS' perspective). This can be fixed with a simple switch to localStorage for the user store (see this issue). It's slightly discouraged but not necessarily a huge issue.
2. Filters are lost during authentication
Another issue with oidc-client-ts - but it's also a simple fix. The signInRedirect function provided by the library can optionally take a custom redirect URL (provided that it follows the CAS rules, i.e. same domain - see here). The 'auth' object provided to the site configuration object can be updated to take a custom redirect_uri.
3. Filters not honoured in Download tab I'm not sure whether this issue is related to authentication - I've also experienced it intermittently, however, irrespective of whether I'm logged in or not. I suspect this is an issue with the download view query.
The way the app handles auth works, but it's not the best. Ideally, all of this logic would be appropriately integrated & handled within a React application itself using a library such as react-oidc-context; however, since the GBIF React Components are technically a library, and that (from my understanding), GBIF isn't committed to OpenID Connect as their authentication mechanism, I understand passing auth functions into a context. Potentially, auth could be refactored to use its own context with a defined set of functions/values?
qifeng-bai
There are some inconsistencies in Auth and event integration
1. Logged in status is not picked by event system Every time you navigate to events system it shows the Sign up Login buttons even if the user is already authenticated. Biocache and ALA website correctly display the Profile button instead.
Clicking on Login will change to the authenticated controls without login prompt.
2. Filters are lost during authentication
Steps to reproduce:
a. Apply some filters, like this
https://events-test.ala.org.au/?datasetKey=dr2009&eventHierarchy=1992f631-98d6-4aa1-a5dd-cd9c3c61a8cd&view=EVENTS
b. Click on Login and follow prompt to enter credentials
Expected User is redirected to the original view where they clicked login and the same filters are still in place
Actual User goes back to the right view but filters are lost.
It seems event system is not passing the filter parameters when going to Auth system, see below for an example of what auth receives for the scenario above.
https://auth.ala.org.au/cas/login?service=https%3A%2F%2Fauth.ala.org.au%2Fcas%2Foauth2.0%2FcallbackAuthorize%3Fclient_id%3Devents-test-oidc-auth-prod%26redirect_uri%3Dhttps%253A%252F%252Fevents-test.ala.org.au%252F%253Fview%253DDOWNLOAD%26response_type%3Dcode%26response_mode%3Dquery%26state%3D7132363cd08f48f095566be374628a87%26client_name%3DCasOAuthClient