Why are we separating admin and app users?

[leon-wbr]

First of all, seems like a great plugin with quite straightforward code!

There is just one thing I'm wondering: Why is there a split into frontend / admin users?

I've set up my app to use the same collection for all users, with an access control on admin and roles determining whether a user is an admin or not. It seems to me that the key difference in this plugin is the password provider.

My favorite implementation would stick closer to Payload Auth, allowing me to use withAuthCollection (equivalent of withAppAccountCollection + withAppUsersCollection) on any collection, adding endpoints on that collection instead of globally. Implementation of the client would stay the same, and options.name could become options.collection.

Definitely tempted to fork and try implementing that. But perhaps I'm missing something.

[sourabpramanik]

Don't worry it is in progress #74

[leon-wbr]

That's so cool.

Would you mind publishing the WIP branch?

[sourabpramanik]

Here #82

[leon-wbr]

Cheers, man. Seems amazing.

I've left a few comments with my thoughts, if that's somehow bothering, let me know. I do think that this plugin can solve a big gap in the Payload CMS ecosystem. I'll try to integrate it and give some feedback as soon as your new changes are ready.

It seems great as is, just think that the useAdmin option isn't conforming to Payload standards.

Perhaps not in this update, but later on, I'd also suggest mounting the endpoints on collections instead of globally, as Payload is doing with its auth. This makes sense, because it allows different user types and separate auth configurations.

[sourabpramanik]

I'll try to integrate it and give some feedback as soon as your new changes are ready.

You can install and build the plugin using bun, go inside the example Payload project, and run pnpm install, then run docker compose up -d to create the db container, and finally run pnpm dev