search

ausecocloud / ecocloud

Issue tracker
6 stars 0 forks source link

Log in workflow improvements #89

Open sarahrichmond opened 5 years ago

sarahrichmond commented 5 years ago

Note from user below:

"Hi ecocloud. When I attempted to login using both AAF and Google I got sent to the "You are not signed in" page. I then clicked the sign in link in the message Please sign in to continue option and was successfully logged in.

As I'm signed in is it possible to remove this page from the sign-in flow, or provide a better message for users who are actually signed in.

Thanks, Terry."

manhinli commented 5 years ago

May need to look at how the Keycloak JS client is working - and how this impacts on the initialisation of the client code. Might be a race condition of some sort.

manhinli commented 5 years ago

We have yet to reliably replicate the issue though it has definitely been observed before, mainly in Firefox?

I'd like to ask what browsers (name, version, operating system) the user is using because it may be a browser-specific issue.

My current (not completely substantiated) guess is around history.replaceState() and its buggy behaviour with the page URL in Firefox, namely Bugzilla #1422334. This is used by the Keycloak JS client to wipe the login token information that was included as part of the return redirect URL. If this gets confused with some other value then we might be obtaining invalid tokens, thus requiring the user to click "login" again to fetch a new token.

manhinli commented 5 years ago

Have encountered it once since last update; not able to replicate it reliably. Have heard of reports of it happening not only in Firefox, but Chrome too, so might not be browser-bug related but maybe network/race conditions?

manhinli commented 5 years ago

Found one reliable way to recreate it - logging in with old/missing state.

The Keycloak server then (after sign in) redirects the user to the application but does not supply all three of the following:

... which is required to initialise the session state in the Javascript adapter. Because of this, it thinks it's not actually authenticated.

There's a second part - callbackStorage has to store some information tied to a sign in on the client itself (by local storage in this case) - this is done in Keycloak.createLoginUrl(), implicitly when logging in with the .login() method. If this is missing, then authentication fails.

As to how we can actually capture this and respond accordingly - the Keycloak JS library is terrible and doesn't surface this to the public API - all we get is a boolean reflecting whether we're authenticated or not. We could try and interrogate local storage for this, but it'll be hard to determine when to do this (as it only should exist between creating login URL -> going to auth URL -> returning to app -> app reading and subsequently deleting the entry in local storage).

How did I even figure this out? The main website currently has a link to "sign in" which points to the following URL:

https://auth.ecocloud.org.au/auth/realms/ecocloud/protocol/openid-connect/auth?client_id=workspaceapp&redirect_uri=https%3A%2F%2Fapp.ecocloud.org.au%2F&state=a382c902-07d2-453c-8328-75728c84581f&response_mode=fragment&response_type=code&scope=openid&nonce=93ee9dbe-3396-4e6f-bfe0-9f1d4d641af7

I suppose some people might bookmark this and constantly get the situation we're facing at the moment.

I'm not sure if my discovery answers everything because I normally log in via the app normally and sometimes get this as well, but I haven't been able to reliably replicate that...