In other applications, when an SSO request is made with an existing uid (usually an email address), it is common to allow logging in as the existing user without creating a new user.
However, Seatable has a separate internal uid called “@auth.local” for email, so when I try to log in with an existing uid (firstname.lastname@example.org), it attempts to create a new “@auth.local” and returns an error if the contact_email is duplicated.
Is there any way to resolve this? In summary, if email@example.com is an existing user, I would like to be able to log in without creating a new user.
I think you find answers to all your question in the section on authentication in the SeaTable Manual.
Thank you for letting me know. Unfortunately, I couldn’t find the answer to what you were curious about.
(1) I registered on Seatable with the email firstname.lastname@example.org. (2) Then I set up Okta SSO on Seatable. (3) When I try to log in to Seatable with email@example.com through Okta, I get an error message saying “duplicated entry - contact email.” (4) I think it’s because Seatable is using “firstname.lastname@example.org” as the UID. (5) It seems appropriate to prevent the creation of a new username (= EmailUser = email = …) if the contact email already exists.
SeaTable registers the user as a local user, the user authenticates against the local user database.
Obviously, this may cause conflicts with already existing users.
I assume your “SAML_ATTRIBUTE_MAP” includes the contact email. So when a user tries to login via SAML, SeaTable will want to write the contact email to its database (see here).
Absolutely, because there is already a user with this contact email address. If the login was successful, SeaTable would have to create a new user with an contact email address that already exists.
No. The error message “duplicated entry - contact email” is correct.
I couldn’t agree more.
If you want to migrate a “local user” to external authentication, the Manual describes how to do it in a subsection of the one linked above.
Thank you. Is there a way to hide internal login on the login page? Can we configure it to only display SSO login?
P.S. It’s just my personal opinion, but I would love it if Seatable’s SSO method was similar to GitLab’s SAML method. GitLab doesn’t provision users if they already exist, and SSO works seamlessly. Plus, everything happens automatically.
I also like Seatable. I hope more people get to use it.
Unfortunately, there no convenient configuration option to hide the local login.
But you can modify the html template so as to not display the local login. You find the template file
login.html in the Docker container at
This said, you should not modify this file directly because the modification wouldn’t survive a docker-compose down/up. There is a way to make the modification persistent, but I just realized that it is not yet documented in the SeaTable Manual. We will add it in the coming days. Sorry! It works the same way it works in Seafile: Seahub customization - Seafile Admin Manual
Thank you Ralf! I’ll try!
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.