Support for storing JWT token in a cookie? about passport-jwt HOT 20 CLOSED

+1 for storing in cookie

from passport-jwt.

A significant amount of the churn/changes to this passport strategy are cenetered around all the different ways various client code wants to store/retrieve the JWT. I'm thinking of making some breaking changes to the API.

Instead of accepting a bunch of options that specify how the jwt should be retrieved from the request I'm thinking of accepting a parameter which is a function that takes a request and returns the JWT. This way user of this library have the ultimate flexibility in retrieving the JWT in any way they want.

Adding options to support every possible method of retrieving the JWT from the request is getting messy, delegating this functionality to a user defined function makes the default cases just a little tougher (forces the user to define the function) but ultimately gives the client code more control.

Thoughts?

from passport-jwt.

I see where you are going, and its a reasonable approach. It does make the strategy less convenient to use when you have to start specifying the code to pull it yourself. I see only 4 places you can submit the token: the URL, a cookie, a header, or the body? You already support 3 of them.

From what I have seen, the primary strategy recommended for submitting a token is the "Authentication: Bearer " header. You might consider supporting what you think are the best practice approaches directly, and then provide the ability to provide an optional user-defined function if it's not in those places. This would allow you to support the most common options, but still provide the flexibility for all the edge cases.

from passport-jwt.

+1 for storing in cookie

from passport-jwt.

Take my +1 too :)
I see that currently there is a pull request "Add passTokenToRequest option" from rschick that enables you to extract token from any place you want - and from cookies too. Probably it would be nice to pull these changes to main branch while we all will be waiting the release of 2.0 version

from passport-jwt.

how is that not a single token-based strategy i found implemented this yet? +1!

from passport-jwt.

Well actually it is quite easy to implement though. See my code here

from passport-jwt.

@themikenicholson +1 on the suggestion to abstract the token retrieval to an injected function.

Re: your concern about default cases, how about just making those included utility functions?

Thanks!

from passport-jwt.

oh yeah I really need that too :) and it doesn't look too hard to implement. I understand the needs of clarifying your API @themikenicholson. Do you know when you're gonna release 2.0?

from passport-jwt.

It's a WIP. I'll get the branch up on the next day or two so people can help start shaking out any issues.

from passport-jwt.

Hi Mike,

This is a important feature for me and for all people who wants to build a SPA (See this https://stormpath.com/blog/build-secure-user-interfaces-using-jwts/).

I just made an pull request with a basic implementation of this feature:
#39

Sorry, but I don't took the time to wrote some Mocha tests :(

from passport-jwt.

@themikenicholson agree on passing function instead of trying to support all the different ways a token can be passed. As @emilong suggested, including your current implementations that cover default cases as util functions makes sense.

thanks 👍

from passport-jwt.

+1 to support a simpler approach for v1.x (something like #39). Of course we can always fork but this would help many folks I guess.

from passport-jwt.

@themikenicholson Any updates on 2.0?

from passport-jwt.

@jbach and others: The apiv2 branch is up. This branch uses a function to extract the JWT from the request allowing the user to pass the request any way they want If you want to try it out and provide feedback you can change the dependency in your package.json to match the following:

  "dependencies": {
    "passport-jwt": "git+https://github.com/themikenicholson/passport-jwt.git#apiv2"
  },

Looking forward to feedback and suggestions on the new api before I release it.

from passport-jwt.

looks good to me. I would add a flag in the configurations to enable or not this feature. Also the name of the cookie should be configurable

from passport-jwt.

LGTM too! Only one little issue is in the README referring to "fromQueryParamter [sic]" rather than "fromUrlQueryParameter". Thanks :)

from passport-jwt.

@albertolobrano I don't intend to add a flag to switch between the new API and the old API, this would just become the new API for the strategy. This is intended to break backwards compatibility and I will rev the version to 2.0.0 as indication of that.

Cookie names would be configurable as the user can provide their own extractor function, the example simply shows how you could do that.

from passport-jwt.

V2.0.0 is now released, this issue should be resolved.

from passport-jwt.

@mikenicholson
v2.0.0 can extract jwt token from cookie using custom Extractor.
But seems this question is can passport-jwt store token in cookie, just like express cookie-session middleware.

from passport-jwt.