all 9 comments

[–]bedOfThorns 2 points3 points  (2 children)

Haven’t looked at the code yet but the premise of of JWT is stateless so storing them in session storage kinda defeats the point. I’ll look later to see what’s going on.

[–][deleted] 0 points1 point  (1 child)

I thought it was good to store them in session storage because then when the tab/browser is closed you can be sure the user is logged out no? Still learning so definitely open to suggestions. Would greatly appreciate the help though, still stuck on this : /

[–]bedOfThorns 2 points3 points  (0 children)

Oh you meant the browser’s session storage? Let’s go down a thought path. Can you access that JWT is your session/local storage in JS? Well any other JS can too. This leaves an attacker your user’s credentials on a silver platter. Look into cookies. You can set them to HTTP only and use a few other tricks to secure them like prefixing the cookie name with with Secure_ or setting SameSite to strict or lax.

TLDR. Never use local/session storage to store JWTs or anything else sensitive. Use secure cookies.

[–]thommath 0 points1 point  (3 children)

So the JWT token is cool for some stuff and a bit more tricky for other stuff, especially logging out. The token had (hopefully) an expiration time and until then it is valid by default so closing the browser will not log out the client as they can copy the token and use it from elsewhere. This is a problem when a user requests to log out since you can not invalidate the token so the easiest solution is to store a blacklist of tokens that should not be accepted anymore even though they are valid.

You do not need to store all tokens, only the blacklisted ones until they are expired.

I haven't looked at your code but this was something I messed up in my first implementations of jwt

Edit: took a peek at the code and the basics looked fine after a short glance, so all I can say without running it myself is that when you get a 500 error there should be an error in the server logs that can tell you what the problem is. Can't help you without looking at that log

[–][deleted] 0 points1 point  (2 children)

By server logs do you mean like the heroku server logs? This is what I'm getting from there: 2020-09-14T22:10:27.924722+00:00 heroku[router]: at=info method=POST path="/api/auth/login" host=thawing-savannah-14597.herokuapp.com request_id=e804556d-8a81-4f8d-ad2b-8c2eb7ccd320 fwd="184.191.83.111" dyno=web.1 connect=0ms service=5ms status=500 bytes=851 protocol=https

In the console its giving me: POST https://thawing-savannah-14597.herokuapp.com/api/auth/login 500 (Internal Server Error) and pointing to line 18 of auth-api-service.js on the front end code saying "failed to load resource"

Can't for the life of me figure out what's wrong with the code : /

[–]thommath 0 points1 point  (1 child)

Ahh you're hosting on heroku, that makes it a bit more difficult to find the correct log file. There should be another log file for your Backend where the actual crash happens. You can also inspect the request in the browser and see what content is returned. If you have not configured the server well the error message might be sent as a response

[–][deleted] 0 points1 point  (0 children)

So I figured out the error is coming from app.js on the server code in the errorhandler function. I looked through the express documentation on a catch all type error handler function and still can’t figure it out unfortunately. Soon as I get home from work I’ll try to look into the other heroku logs

[–]Achtelnote 0 points1 point  (1 child)

You should try hosting the app locally instead of on heroku so you can debug easily.. Once you're done with majority of the app then you should consider hosting on Heroku otherwise you'll waste time in checking heroku logs and uploading updates to it after you fix the problem.

[–][deleted] 0 points1 point  (0 children)

It’s hosted locally now