a request to verify password to externaldap.js logic can come from
* cloudron app (via ldapserver.js)
* dashboard (via oidc.js) or proxy auth (proxyauth.js) or CLI (accesscontrol.js)
the only supported source is the 'cloudron' provider at this point
directory server cannot know the source of the requesting client.
there are 3 sources - external app, cloudron app, cloudron dashboard.
the 2fa is requested by client by passing `+totpToken=xxx` . totpToken
is ignored if the user has no 2fa setup. If present, it is validated.
this allows existing users to login (including the owner itself)
The alternative is to have some system where we have unique superadmin users across cloudrons which don’t get trampled upon by a sync. This is a bit unrealistic. For the future, we could also design this such that ldap auth is asked for in the initial step i.e at superadmin creation time.
If LDAP connection is lost/down, user can always use 'cloudron-support —owner-login'
we discussed a bit on what this does and it's confusing as it stands:
* Use case of this is lost in the realms of time
* Possible guess by is that it was to move users of different Cloudron to a central cloudron
* Currently, the design is a bit flawed because the make user local button doesn’t pin the user. The state is lost in next synchronization.
* Maybe, one should use export/import user for this use case
* Let’s disable this button for now, feature is not complete.
initially, the idea was to make the server enforce it. this is more secure. however,
we have 3 kinds of clients - an external cloudron dashboard which needs totp,
an external cloudron app, which doesn't have totp and external apps that don't have totp either.
given that the directory server is IP restricted, this is a reasonable compromise until
we move wholesale to oidc.
a directoryserver setting like "enforce totp" also does not work since this policy will be
applied to all clients.
