These are chat archives for waterlock/waterlock

17th
Feb 2015
Arthur Goldsmith
@arthur5005
Feb 17 2015 08:45

I share swelham's sentiment. Not only do I not like the end point, I don't like the concept of having to have a session at all in order to use JWTs, I was under the impression JWTs were a stateless way to do away with sessioning.

The controller logic for /user/jwt starts with this:
/**

  • jwt action
  • creates a new token if a session is authenticated
  • GET /user/jwt
    */
    module.exports = function(req, res){
    if(!req.session.authenticated){
    return res.forbidden('You are not authorized.');
    }
Perhaps an good addition to the engine would be allow for programmatic creation of JWTs.
Stuart Welham
@swelham
Feb 17 2015 08:55
@arthur5005 you're absolutely correct. Session shouldn't even come into it, especially where REST is concerned as this should be 100% stateless. It should only be possible to generate a JWT when the user's credentials have been supplied as part of the request.
David Rivera
@duhruh
Feb 17 2015 15:09
@swelham I agree the only issue I would bring up is how do you go about revoking tokens? Yea the client can deleted it from their cookie/local storage/whatever but that doesn't mean the token is revoked. I suppose you can have a smaller expiry date and regularly rotate your tokens but you don't want to make it too small because then you might have your client logged out in the middle of what their doing :/ its a fine line, so I stored the token so this case is a non issue. However I'm not too fond of this method either. If you can come up with a better solution or you guys feel my worries are void please let me know and we can scrap that token storage out.
Stuart Welham
@swelham
Feb 17 2015 15:15
We could still store the JWT against the user and maybe have some form of logout endpoint that will revoke the JWT attached to the request.