Login as multiple auth-enabled collections

[sixers]

Is it possible to login as multiple auth-enabled collections simultaneously?

Let's say I have Users collection and Admins collection, and I want to be be logged in as both User (in the frontend part) and Admin (in the admin panel) at the same time. Is it doable?

Right now, both Auth collections overwrite each other's payload-token cookie. Would it be enough to simply use different cookie names? Is it configurable?

[jmikrut]

Hey @sixers!

Unfortunately there are many complexities below the surface of doing something like this.

For example, if you were logged in as 2 different users, how would Payload know which user you were intending to be using for any given request? Payload operations access the currently authenticated user from req.user - and while it would be easy enough to change this pattern to use req.users or similar instead, we would still need to know which user to rely on.

Making auth cookie names dynamic would certainly be one piece of the puzzle, but there are many more complex issues and use cases that would need to be thought through fully here.

We can keep it on the radar for sure though. What do you think?

[sixers]

Thanks! Ok, that makes sense. In that case, I'll combine the two collections. I wanted to keep them separate, because they have completely different fields, but it's not a big deal.

[tago-SE]

Couldn’t you store the fields as a relationship to a RootUser collection? That way, you could conditionally determine which fields to display or even which collection contains the actual user object.

You’d have something like:
• RootUserCollection (acts as the entry point)
• AdminCollection
• UserCollection

The RootUser would just need a UserType property to identify the correct subtype. Maybe it’s even possible to keep the RootUser collection hidden while still using it for lookups.

If you have a custom auth strategy it would just need to be able to resolve which user it is and load it from the correct collection.

[Tronix117]

@jmikrut imho, there is not many complexities, a custom strategy could easily handle that, by returning null if the user is on a specific path like if req.url contains /admin.

However, right now, only headers are given to the custom strategies, and I can't really get why not the whole request, it will make things so much easier, as well as having a lot more sense than only having headers.

The solution I used was to add a middleware to set an extra request header : requestHeaders.set('x-request-path', request.nextUrl.pathname), this way I can use that in the authenticate method, however I do not really like this solution.

[Yawarzy]

@jmikrut Hi! Is there any update on this topic? In our application, we have an admins collection which handles the authentication to the /admin panel. Then we have another collection with auth enabled, which is used on the frontend. But if a user logs into the frontend via the mentinoed collection, then afterwards if the user logs into the /admin panel with their admin account, they won't be able to access the protected routes of the frontend, and vice-versa because the cookie will be overridden.