Optional authenticated user

I’m building an SPA that allows you to like and dislike properties. Part of the requirement is that it is usable without needing an account, but an account can be created using Facebook Auth later in the user flow of the app.

In order to account for the like/dislike state for the user, I’m creating a new user anytime a unique user uses the app. I store this user in a table with a random hash as their uid. I also store this uid in their localStorage incase they refresh the page. If they decide to use FB Auth then their email would be used inserted into the users table which links them to the uid.

That’s all working nicely, but what I’d like to do is take advantage of the auth session methods so I can reference the current user in controllers without having to pass the users uid with every request.

Is this possible or am I just dreamin’?

1 Like

Hi @JamesThomson

It’s really interesting stuff you have there :slight_smile:

What kind of auth provider are you using? (Session / JWT etc)

Hi @McSneaky. I’m planning to use JWT

I digged into JWT auth some time ago.

I have not tested it at all, but idea I had back then is to make “fake” JWTs :slight_smile:

By fake I mean create JWT yourself using underlying ‘jsonwebtoken’ module directly so it is valid and signed by API, and add uid as payload in there. I can’t remember exactly if it had to be in user object or not.

// payload
  user: {
    uid: add_user_uid_in_here

Something like this SHOULD work :thinking: Take a look at @adonisjs/auth/src/Schemas/Jwt.js

Thanks, I’ll have a look into that. I’m pretty fresh to Adonis and BE. I’m a FE dev expanding my knowledge. How would something like that flow in terms of logic?

  1. Check if user exists based on uid
    a. If exists, use token stored in user table of db?
    b. Else, create a user and issue a new jwt. Store jwt in user table?
  2. Assuming the above went smoothly, I can now use auth methods?

I guess what I’m trying to do is create user accounts and make use of Adonis’ auth system, but without the need of a user password. The user account initially won’t have any sensitive information unless they decide to auth with FB. At that point we’ll store their name and email… but still I don’t have a need for a user password.

The thing that’s making me stumble is removing the need for a user password while still gaining access to the auth system. I’m assuming this is pretty unconventional which is why there’s no use case in the docs.

One thought I had was to just make a default password. e.g “password” which every user account would have until they decide to use FB. Is that a bad idea?

Why not treat your unregistered users as Guest users and have a dedicated model/database table for them. This is how I imagine it

  1. Have a dedicated Guest Model
  2. Create a new authenticator block inside config/auth.js file, that uses the Guest model for authentication.
  3. Have another authenticator block inside config/auth.js file, that uses the User model.
  4. Once a user login with their facebook account, you can delete the guest JWT token from the browser localstorage and instead use the authenticator to generate a new token but this using the authenticator that points to the User model.

Thanks for your reply @virk. Sounds like a viable option. Would I also need to have separate controllers? Also, how would I persist the liked/disliked properties to the user? Would I take the guest users uid and use it when creating an authenticated user?

All is in your hands,i think it is possible,depends how much you ready to spend for this