feathers

feathers copied to clipboard

Steps to reproduce

Method using Oauth

1. Setup feathersjs/authentication-client with storage in window.localStorage.
2. Head to the relavent oauth url ex. http://localhost:3030/oauth/github
3. After the page logs in, head to the same relavent oauth url again in step 2. Observe that the access_token hash is not removed from the url.

Here is an example repo. Its not a complicated setup to replicate.

Expected behavior

It should clear the hash after logging in through oauth url even when logged in.

Actual behavior

The hash remains in the url.

Module versions (especially the part that's not working): Defaults based on feathers app create. Feathers Client uses 4.3.0 in the demo, however the issue is present with tested the latest version.

Operating System: Windows 10 Browser Version: Google Chrome Version 83.0.4103.116

Notes: When using Routify, the following error is printed (uncaught promise exception).

index.js:13 Uncaught (in promise) DOMException: Failed to execute 'querySelector' on 'Document': '#access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6ImFjY2VzcyJ9.eyJpYXQiOjE1OTQ4NDg0MTMsImV4cCI6MTU5NDkzNDgxMywiYXVkIjoiaHR0cHM6Ly9ib3Quc3VyZWRyb2lkLmNvbSIsImlzcyI6IlN1cmVEcm9pZCIsInN1YiI6IjYiLCJqdGkiOiJkMmE5MDRhNS01YThjLTRlZjEtOTU0NS1lZjExMjMyMTVjMzAifQ.RM7guCmu-04X_mCIHLUOrPcFKdWYBLZfpOANUJJ5dBE' is not a valid selector.
    at handleHash (http://localhost:8080/build/bundle.js:1196:29)
    at handleScroll (http://localhost:8080/build/bundle.js:1189:7)
    at onLastComponentLoaded (http://localhost:8080/build/bundle.js:2845:7)

By default the hash is always being removed but it might clash with whatever routing library you are using. You might be able to work around this by customizing the redirect or the authentication client, specifically the getFromLocation method.

Of course, however in the example I provided, it doesn't use any routing library. I'm not sure if the error I found in Routify is related to the error in example, however I included it in the notes since I felt like it may help give a clue to where the error is occurring.

I tested this with the latest .pre.34 which has a number of authentication client improvements and I think this should be solved now.