Multi User support

[arielmoraes]

Does listmonk support multi users (each one with its own Dashboard)?

If not, is it feasible to fork it and do the required changes?

[knadh]

It doesn't right now, but it has been on the to-do since the beginning. Some context here https://github.com/knadh/listmonk/issues/125.

The requirements are:

• A lightweight authentication lib.
• Support for native credentials (e-mail / password).
• Support for oAuth.
• Granular permissions per user that control API calls and the corresponding UI interactions.

I wrote some pseudocode here a while ago, but never got a chance to focus on this. If you would like to take this up as a project, please feel free to propose a spec. Thanks!

[arielmoraes]

I see, but is that for multi users accessing a shared set of resources or each own user with separate data?

[knadh]

There could be lists that are user owned (this is tricky to do), but multi-user here is not intended to be multi-tenancy, but permission'd access to the same instance.

[jooola]

What about using tools such as ory/kratos or keratin/authn-server, so a powerful user management is shipped in no time and listmonk only has to build the bridge ?

I am not suggesting something like an external auth service, but really a full featured user management system embed into listmonk.

And if one wants to extend this, building multi tenancy would simply mean, spinning another listmonk but still having user management in a single place ?

[charlesmudy]

+1 to this ... infact, it might solve #499 ... its almost unusable now since every email is unique. Quite limiting.

[knadh]

What about using tools such as ory/kratos or keratin/authn-server, so a powerful user management is shipped in no time and listmonk only has to build the bridge ?

These are full fledged, standalone auth servers, programs bigger than listmonk even. Embedding them into listmonk may not be ideal. I'll take a closer look at them though. The auth system will have oAuth support to plugin external providers.

But, multi-user scopes and views vs. multi-tenancy are two different beasts. Multi-tenancy is not on the roadmap.

+1 to this ... infact, it might solve #499 ... its almost unusable now since every email is unique. Quite limiting.

This is unrelated. Subscribers (and by extension, their primary ID, e-mails) being globally unique first-class citizens won't change.

[RKVodde]

Multi User Support is a much needed feature which boosts the usage of a wonderful platform like "listmonk" in an organizational setting.

[bryceprutsos]

I agree that multi-user support would be a great enhancement. However, like the developer said it's tricky because of which user has access to what. Just pointing out that if multi-user support is a thing LDAP or SSO (SAML, CAS, OpenID) should be supported.

[NicoHood]

For me it would be great to have a minimal multi user mode: Just have multiple logins, all with the same access. The reason why this is important, because you can withdraw permissions of the user (aka delete or block a user), when someone leaves the team. We also then do not need to share passwords (this is so bad) and can use multiple accounts and do password reset via email oink. As a first step, this would help to get feedback and set the start for multiple logins.

[knadh]

+1 @NicoHood. There should be a simple native permission based multi-user system. Once that's in place, plugging in OAuth, LDAP should be straight forward.

[RKVodde]

Any progress on the multi user support.

[knadh]

@RKVodde nothing yet, unfortunately. I was looking at this again last week and came across this new lib: https://github.com/go-pkgz/auth

Haven't had a chance to look at it up close yet.

[RKVodde]

I am not into go-lang but this is what I found, might help. https://github.com/volatiletech/authboss

[c-nv-s]

@RKVodde nothing yet, unfortunately. I was looking at this again last week and came across this new lib: https://github.com/go-pkgz/auth

Haven't had a chance to look at it up close yet.

I used this library before for a custom OAuth setup and it was fairly straightforward which is nice. I actually switched to it after failing to get authboss working which was actually a painful experience.

[rpmcoding]

Sounds good!

[titansmc]

Hi, I am interested on it but found no multi-user support. Is it something being worked on? Before we start evaluating alternatives. Cheers.

[knadh]

It's on the to-do, but haven't started working on it yet. Unable to give a timeline, unfortunately.

[pwnoobz]

I'm also interested in this. I just want to stay subbed on the topic.

[jmaisonneuve01]

Hi I'm gonna start working on this function so if anybody got something already running message me plz!

[knadh]

@jmaisonneuve01 please share a plan/proposal/spec of what and how you're planning to implement.

[jmaisonneuve01]

@jmaisonneuve01 please share a plan/proposal/spec of what and how you're planning to implement.

Still gathering and analyzing your code for the moment ill keep you updated

[samuk]

Any news on this one @jmaisonneuve01

[titansmc]

https://github.com/coreos/go-oidc

Any chance the OIDC could be used ?

[floridarangers]

For what it's worth until this feature is available. I use caddy and forward_auth as a work around (nginx supports something like this as well). It's not perfect but it allows me to give multiple people access to the server without having this feature in place.

[knadh]

I've finally started working on this. Ref: https://github.com/knadh/listmonk/pull/1701#issuecomment-2032551568

[knadh]

Update:

• User management on the UI and backend is done.
• WIP: Frontend authentication, user permissions, permissions per list.

[chrislbrown84]

Great news - thanks for sorting this @knadh

[bryceprutsos]

Great news @knadh I will be more than happy to test.

[shanrahul]

@knadh when will be the feature the available ?

[knadh]

• User management, native password based login and OIDC login are done.
• WIP: Permissions

[jflattery]

Looking good! Is the plan to implement this generically so that other OIDC providers (for example authentik) can be used?

[chrislbrown84]

Is there a timeline for the user permissions feature to be complete, i can see this application being widely adopted as soon as it's in there!

[knadh]

The next release, v4.0.0 will have this. It should be ready in a month or slightly more than that.

[knadh]

[carpepraedam]

@knadh Will this support Active Directory as an authentication source, or generic OIDC providers such as Keycloak.

Either of these would increase adoption from organizations operating within a corporate network.

[knadh]

OIDC support is already added. You can plug in any OIDC provider.

[shanrahul]

Will this support LDAP Authentication ?

[knadh]

There is no built-in support for LDAP that's planned. You can use something like KeyCloak or any proxy to achieve LDAP support.

[knadh]

WIP: Per-list read/write permissions attached to roles.

[tudor-cel-stan]

Amazing work! Can't wait for the feature. When this is launched, maybe you could add the ability to connect SMTP configurations to lists, so that sending a campaign to a specific list would use that specific SMTP config.

This would actually enable us to manage multiple clients/domains from a single ListMonk install. Thank you for building this tool!

[crebuh]

First of all great work @knadh 👏🏻👏🏻

to understand this feature correctly, it will not support different accounts for sending newsletters to different domains?

I guess this would be another feature or as @tudor-cel-stan mentioned, similar to having own smtp settings for different lists?

[knadh]

Thanks @crebuh

it will not support different accounts for sending newsletters to different domains?

If you're referring to picking SMTP servers per campaign, that's not a part of the multi-user project.

[crebuh]

ok but multiple accounts for different companies/products?

[tudor-cel-stan]

@crebuh I was looking into quicker to implement ways to make Listmonk useable for multiple clients (different domains and SMTP servers) on the same Listmonk install.

I think the quickest way to do that before starting to develop multitenancy (multiple organisations with different settings) which seems like a much larger project, is to be able to attach certain settings (like SMTP settings and sending address) to a mailing list.

For my client use cases, coupled with list permissions per user, the ability to change smtp and sending address settings on a per list basis would be ideal (I would be immediately switching my customers to Listmonk from Sendy to profit from your advanced Go templating).

[knadh]

Ah, there are no plans for building multi-tenancy into listmonk. That is outside the scope of the project. Also, one database (and app) that shares data for many orgs is not ideal, not in terms of maintenance, performance, or security when has not been built from the get-go to be that way.

If you want multi-tenancy for different clients, it's best to provision different instances of listmonk (it's light on CPU and RAM) with their own databases (can be one database server, but different databases init).

[crebuh]

@knadh Thanks for the clarification. i was thinking of a similar approach to add own instances of listmonk to all the different projects. normally this should be fine depending on the size of the project of course. and sharing the database is also the way to go.

[mustafa519]

That work looks amazing, but I am not sure if it helps to manage multiple projects/domains in the same listmonk instance. Does project/domain support count as a multi-tenancy implementation too?

I was just imagining project based subscriber separation to use the same instance for all my projects. Otherwise, having the same subscriber makes it harder to manage. Especially, there are many separated lists across projects.

I just mentioned the problem here that I am struggling right now #1959

Listmonk also can shine for the transactional mails like we can put the notification mails into the queue which listmonk is already supporting it.

However, I agree that it can double the DB entries since there will have to another relational table to build the relation between the domain and the subscriber, though. Still, I really need a decent solution to share the same listmonk instance across my projects.

[lmmendes]

@knadh Do you have any idea when this feature will be released?

[ssoronid]

@crebuh ... For my client use cases, coupled with list permissions per user, the ability to change smtp and sending address settings on a per list basis would be ideal (I would be immediately switching my customers to Listmonk from Sendy to profit from your advanced Go templating).

For your use case, it would be beneficial to develop a system that manages subscribers effectively while maintaining data integrity and flexibility.

One approach would be to structure the database so that subscriber data is shared across the same database but associated with different lists through a "tenant" or "client" column. This would prevent conflicts when upserting subscribers who might be shared across multiple lists.

Here's how this could work:

• Tie each subscriber to a specific tenant or client using a unique identifier (e.g., a "tenant_id" column).
• When an upsert occurs (i.e., inserting or updating a subscriber), the system would use this tenant identifier to update the correct subscriber record for the appropriate list.
• This way, even if the same email address is subscribed to multiple lists, the system would update the appropriate data for each tenant or client, ensuring accurate and isolated subscriber management.

For SMTP configuration, you could store these settings directly in the tenant table. If a tenant has custom SMTP settings, they would be used; otherwise, the system could fall back to a default global configuration. This approach would offer the flexibility needed to tailor email sending per list while keeping the setup manageable.

Additionally, as the system evolves, you could consider implementing Row-Level Security (RLS) based on the tenant_id column. This would ensure that each tenant only accesses and modifies their own data, adding an extra layer of security to your database.