Jump to content

[Help] creating a login session


maximlus
 Share

Recommended Posts

Hi @maximlus, welcome to the forums

Logins need two things:

* A way to track logged-in status

* A way to set logged-in status

You can track logged-in status on either the client or on the server, but you almost always want to track _something_ on the client. The complication comes from identifying _who_ that client is, and that you can not trust clients.

A common flow for a single-page application (your game probably is this) would be something like:

* Hit your webpage holding your game

* Navigate to log-in screen

* Enter log in details (e.g. id/email, password)

* Send those to your server. Check the details, if correct, generate a token, store it, send it to client.

* Client stores this token (local storage is fine) and uses it to make subsequent requests or to actually enter the game.

* Next visit, when client boots up (after hitting the url), check local storage for a token, maybe send it to your server to check it is still valid, become logged in.

This flow means you have to store 3 things:

* id/email and password details (server)

* valid tokens (server)

* logged-in status (client)

Valid token status dictates logged-in status i.e. you should probably check the token is valid before assuming that it is.

Tokens normally have two things:

* An expiry

* Are revocable

An expiry means they will expire, you don't necessarily need to store this on the client, i.e. when the expiry date is hit then delete from server storage, when a client tries to use it, that operation will fail and you'll direct the user to a place where they can enter their details to generate a new one.

This system also means that if you think anything is compromised (or problematic) then you can revoke a token. You could go a step further and associate a token with a user explicitly which gives you more control if you want to boot out a user, i.e. you revoke their token so they stop immediately, and you stop them from being able to generate a new one.

It is normal to do this link between tokens are users, check out JWTs. If your game requires accessing authenticated endpoints (getting levels, scores, anything really) then using a token to do the auth stuff is quite nice i.e. your services _could_ inspect the token and respond appropriately for that user (or user type) i.e. to get the _next_ level, you wouldn't have to ask for it from the client (remember, don't trust clients), you could hold current level on the server and your endpoint could inspect the token, inspect the current level (and completion status maybe) and return the next level.

 

There are lots of services out there that can handle these flows (and more complicated ones, such as 2FA) for you. It's worth looking up how they work and if they would work for you. Unless you want to code this all up and have to deal with holding emails or other personally identifying information (or even user tracking).

Link to comment
Share on other sites

Thank you for this reply @mattstyles

I have been looking up some guides and a lot don't explain what there code is doing. Plus I really want to do this from the ground up. to have some work that I can show off to employers. 

A system like what you described sounds like the best option. 

Thanks again. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...