Skip to content
This repository has been archived by the owner on Aug 29, 2018. It is now read-only.

Re-using the same JWT with Primus / websockets #4

Closed
leebenson opened this issue Dec 2, 2016 · 4 comments
Closed

Re-using the same JWT with Primus / websockets #4

leebenson opened this issue Dec 2, 2016 · 4 comments

Comments

@leebenson
Copy link

leebenson commented Dec 2, 2016

I've bumped Feathers.js to v1.0.0-beta-2 locally, and have managed to implement a working 'local' strategy for pulling user data from a 'users' table, using feathers-knex.

I get the token back locally, and can use .verifyJWT() and .service('users').get(payload.userId) to retrieve the user. A call to .getJWT() locally confirms it's being stored properly in localStorage.

So far, so good.

The problem I'm having is re-using that JWT token on subsequent requests.

Calling app.authenticate() yields another JWT, but without userId being attached to the payload. It looks like it's ignoring the locally stored JWT and requesting a blank new one.

Calling app.authenticate({strategy: 'jwt', token: '...'}) yields the following error:

NotAuthenticated: No auth token

(I've tried 'token', 'jwt' and various other formats to pass in that token manually in the request... but I assume since the server is using the default ExtractJwt.fromHeader, this probably has no effect).

I'm wondering whether this has something to do with the fact I'm using Primus with websockets in my authentication request, which is screwing with the format of the request? Do I have to do something special to get the token from localStorage and bolt it on to the request somehow?

In your feathers-passport-jwt package (I can't tell whether it's deprecated or not; I'm not using it locally), it mentions this implementation:

socket = io('', {
// Assuming you've already saved a token to localStorage.
query: 'token=' + localStorage.getItem('featherstoken'),
transports: ['websocket'], // optional, see below
forceNew:true, // optional, see below
});

However, I note from your feathers-authentication migration doc this line:

The JWT is only parsed from the header and body by default now. It is no longer pulled from the query string unless you explicitly tell feathers-authentication-jwt to do so.

... so I'm not sure exactly what to do.

Could you provide an example please for re-using the JWT using Primus?

@leebenson leebenson changed the title Example call to app.authenticate({strategy: 'jwt'})... Re-using the same JWT with Primus / websockets Dec 2, 2016
@leebenson
Copy link
Author

And btw, when I say 'subsequent requests', I mean when a user refreshes the page and they're just left with a localStorage['accessToken'] to re-attempt the request next time.

I also pass this same token on subsequent requests to my web server (separate from the API server running feathers) so it can do the handshake, and send down a HTML dump/mobx store state pertaining to the user identified by 'userId' in the JWT.

So, I need to know how to re-use that JWT in a generic way -- my web server uses REST, whereas a browser user connects via Primus, for example.

@ekryski
Copy link
Member

ekryski commented Dec 6, 2016

Calling app.authenticate() yields another JWT, but without userId being attached to the payload.

Hmm, you're sure the userId isn't getting put inside the new auth token? If so, can you come up with a minimal example to reproduce that one? If you turn on DEBUG=feathers-authentication* npm start you should see a ton of logs and see what is getting encoded inside the the JWT payload.

Calling app.authenticate({strategy: 'jwt', token: '...'}) yields the following error:

That's expected. @leebenson it should be accessToken instead of token. Try that.

That other feathers-passport-jwt package is a very old one that is not a core feathers module. I've asked @marshallswain if he can deprecate it. Sorry for the confusion there.

@ekryski
Copy link
Member

ekryski commented Dec 14, 2016

@leebenson any luck here? Did it work when using

app.authenticate({ strategy: 'jwt', accessToken: accessToken })

Still having issues?

@leebenson
Copy link
Author

Yes, accessToken worked for auth, thanks.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants