Closed devillemereuil closed 3 weeks ago
Hello,
For the next time, can you please respect the template, It really help packager to answer the issues.
And can you please give me the Seafile package version and your Yunohost version.
I apologise, I edited the initial comment following the template more closely. I didn't add the logs, as I'm not sure which log would be relevant in this case, if any at all.
Hello,
I was able to reproduce the issue. I'll work on a fix. Until the fix is release you still can work around the issue this way:
domain.tld/seafile
.domain.tld/seafile
Hello,
I was able to reproduce the issue. I'll work on a fix. Until the fix is release you still can work around the issue this way:
- You need to set the app as "public" so the visitor group is allowed to access to
domain.tld/seafile
.- Than logout from the SSO
- Go on
domain.tld/seafile
- Put your credential (email and LDAP password for the user)
- this will import the user from LDAP in seafile and the accout should be created.
- After that you should be able to login from the SSO, at just needed at the first login.
In my situation, when I login from the SSO after doing what you said, then I need to relogin on domain.tld/seafile. Somehow it doesn't consider my previous Yunohost login. I need to remove the app from public visitor group for the SSO to work but Seafile answers with "Error, new user registration is not allowed, please contact administrator".
I explained it in the forum post
Initially, I couldn’t connect to my Seafile server using Yunohost SSO, receiving an error stating that “new user registration is not allowed.” To resolve this, I enabled guest access for Seafile, which allowed me to log in through both the web app and clients (Android/Linux).
However, I encountered another problem when trying to connect via WebDAV, which repeatedly said “user not recognized.” It was frustrating that my Yunohost SSO wasn’t working properly.
After researching, I found this link that mentions Seafile needs to create new users from LDAP. So, I changed the setting REMOTE_USER_CREATE_UNKNOWN_USER to true. This change allowed me to connect using Yunohost SSO and mount WebDAV successfully.
Once I removed the guest access, I was able to log in with my SSO account, but it was a new account instead of the old one. Now, both accounts coexist. While the WebDAV connection still works, I can’t connect via the Seafile clients anymore.
It seems from here that seafile needs a first connection as guest, to copy the account from ldap, and then re-enable Yunohost SSO. But it doesn’t work for me : SSO is ignored as long as the app is open to guests.
But I think the client connection issue might be related to the removal of the guest access, which likely disables connections from external sources that are not using Yunohost SSO. Do you know how I can make everything work together smoothly?
I have also been unable to successfully log in as an admin.
Hello,
Well on the explained work around the idea was to don't login on the SSO (or logout).
Anyway now a fix is available on testing and will be merged on master next week.
I'm sorry to report that after following close the steps above for a newly created user, the workaround didn't fix the issue for me. The account was created without trouble by Seafile (as it was in my report above I would assume?), but it is still not possible to connect through the SSO after creating the account through Seafile portal.
Closing as now it should be fixed on master now
I confirm this after installing the new version, thanks so much!
Summary
Since the upgrade to Seafile 11 in Yunohost, it seems that SSO connection is broken. It is possible to connect to Seafile after a user creation using Seafile's portal, but it's not possible for the newly created user to connect through Yunohost's SSO and click on the Seafile tab.
Context
Step to reproduce
Expected behaviour
Connection through SSO portal to Seafile should work for all users, old and new alike.
Breadcrumbs
It seems something is wrong with the communication between Seafile and LDAP. After the steps above, an admin in Seafile can see that in the Users admin page, an account is named
<somelongID>@auth.local
in the "LDAP" tab, but another account is namedlogin@my.domain
(as it should) in the "LDAP (import)" or "Users" tab. I believe the issue is linked to the fact that these accounts do not seem to share the same credentials. It could be linked to Seafile 11 new config for LDAP not correctly set in this package?