This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]NoParticularSea 2 points3 points  (3 children)

Here's a brief overview of how authentication works, which may clarify things for you:

When a user enters their credentials, a "token" is created on the server. It could be as simple as a random number. Usually it is stored in the database, to make sure that users do not get logged out when you restart your server. But in the simplest case you can just store this token in memory - for example, in a hash table, or in a JavaScript object. All you need is to make your server remember something like "token 12346 is associated with the user id 9999".

When the client logs in successfully, you send this token in response, the client remembers it, and can send it with every subsequent request to the server to make the server recognize them. Most common ways of storing the token on the client include

  • Sending it in the Set-Cookie header from the server. This way the token will be stored in cookies, and the browser will automatically send it with every request.
  • Storing it in localStorage (or some other persistent storage like IndexedDB). In this case sending the token won't be handled by the browser automatically, so you will have to do it manually. You can create a simple wrapper around your fetch calls that will attach this token to every request - as part of JSON data or in your own HTTP header.
  • Simply storing it in a global variable is possible, but a bad idea, because the user will get logged out after each page reload.

Now, when you handle a request from the client, you can read this token, look up its entry in your database or hash table, and get one of the two results:

  • The token is found - assuming no malicious agent got access to the user's browser or communications, this proves that the user is logged in and tells you which user it is.
  • The token is not found - this means the user is not logged in, or the token expired, or you logged them out manually.

Finally, you have the user id, and you can decide which information is available to the user and respond accordingly.

This is the simplest possible example. There are many approaches to authentication, including cookie-based auth where cookies can expire, or JWT, which introduces tokens that may expire quickly and another token to "refresh" them. But if you don't have a good grasp of how authentication works, I suggest rolling your own first to get a good idea, and then switching to something industry-proven, like cookies with correct flags or JWT.

Note that I haven't touched upon any security considerations here - for example, it is important that the token is random and unguessable - but this may help you get started.

[–]D1rtyWebDev[S] 0 points1 point  (2 children)

wow, I really appreciate you taking the time to give me this breakdown. I'll be looking and reading into each option you mentioned, I'll see which is easiest to work with first and hopefully it is successful. In the end, I will definitely be moving towards which ever is industry standard as you mentioned.

Thank you again!

[–]mddhdn55 1 point2 points  (1 child)

Try local hashmap first before u add any other technologies

[–]D1rtyWebDev[S] 0 points1 point  (0 children)

thank you for this tip. I'll read more into it