-
-
Notifications
You must be signed in to change notification settings - Fork 790
Description
The authentication client is able to read an access token from the URL, this is typically used when login through OAuth2. If a token is not found in the local storage but is found in the URL then it is "consumed" (ie removed from it) and stored as usual in the local storage.
The problem is that if you try to log again by using a new token in the URL Feathers will not use it as the previous one is found in the local storage. It seems to me that if you provide a new token in the URL you expect Feathers to consume it instead of using the previous one. So I wonder if it might not be more logical to check first if a token is available in the URL before checking the local storage as done by the authentication getAccessToken method by default.
Typically we are using this capability to create kind of "magic" links to an application where a user can open a specific page without requiring to login first because the token is part of the URL. However, the token contains a permission to underlying services/objects so that the user can only open this specific page with it and not others. It was not working fine when the user tried to open in the same browser two magic links due to the problem discussed previously, we had to update the authentication getAccessToken method like this to make it work better:
getAccessToken = async function () {
let accessToken = await this.getFromLocation(window.location)
if (!accessToken) {
accessToken = await this.storage.getItem(this.options.storageKey)
} else {
// Ensure any previous token will not be used
await this.removeAccessToken()
}
return accessToken || null
}
Let me know what you think.