Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple accounts same username #44

Open
Oujiii opened this issue May 26, 2019 · 7 comments
Open

Multiple accounts same username #44

Oujiii opened this issue May 26, 2019 · 7 comments

Comments

@Oujiii
Copy link

Oujiii commented May 26, 2019

I installed it in my instance on seafile.example.com and when I accessed it directly, it asked for my credentails, so I just input [email protected] and it logged it fine.

What I noticed a few hours later is that if I access the Seafile server using the yunohost SSO, it creates a different user library, even though the user is the same.

So, my login on Yunohost is mail. If I go to example.com and login with mail and then click in Seafile, it will redirect to one library. If I go to seafile.example.com and login with [email protected] it creates another different library.

I think this issue is somewhat related to #5 and #42

I also noted that in none of the cases I was able to use the admin interface, even though I set up mail as the admin user.

Just ran a few tests and found out that:

  1. System admin wasn't available when running on a root of a subdomain
  2. If I try to acess example.com/seafile directly, it won't redirect me to a SSL connection by itself. I might have to manually configure this in nginx

That's about it for now.

@Oujiii
Copy link
Author

Oujiii commented May 27, 2019

Okay, I found what happens when you install in a subdomain.

For some reason, when you login using YNH SSO, it will create an user in the database that's [email protected] even if your LDAP user is [email protected]
This will happen regardless of the user you login, as long as you come from the YNH Portal.
If you try to manually login using your YNH SSO credentials by going directly to seafile.example.com it will import the LDAP user, creating a new user, different from user created from YNH Portal, that's why #42 was happening.

Haven't really find a way to circumvent this. Until it's fixed, if you install in a subdomain, your users will always be like that.

For the admin account thing, I simply went to /var/opt/yunohost/seafile/seafile-server-latest/ and ran the reset-admin.sh and then I input [email protected] and the same password from the LDAP.

If that doesn't help, run the reset-admin.sh and use [email protected] and his LDAP password, then go straight to seafile.example.com (you have to do this in a browser where you're not logged in the YNH portal), use [email protected] and his LDAP password, go to the Admin area and set the [email protected] as an admin.

Now if you wanna log on on any sync client, you have to use [email protected]

I hope that helps.

@Josue-T
Copy link

Josue-T commented May 27, 2019

I know this issue, but for now I didn't find a clean way to fix this. It's related to this #5

And yes when I implemented the sso authentication growed...

I tried to force to use a user instead of email it's just bad because in the seahub code where are everywhere a check that the username contains a @. So we need to keep an email a username.

Maybe the last solution is if seafile get a other domain for the email we dynamically force to use [email protected].

@Oujiii
Copy link
Author

Oujiii commented Jun 1, 2019

That's what I thought. Maybe you wanna add something about this in the README so more people are aware on how to handle the whole subdomain issue when installing?

@Josue-T
Copy link

Josue-T commented Jun 1, 2019

The problem is not specific to the subdomain. The problem could happen anytime when you have multiple domain on your instance...

@Josue-T
Copy link

Josue-T commented Jul 30, 2019

Well, thought about a solution improve this situation. I thought that we could maybe add a patch in seahub (which is written in python). But the problem is that the user validation (linked to LDAP) is in the ccnet part, which is written in c. So it's quite complicated to fix this.

Maybe you wanna add something about this in the README so more people are aware on how to handle the whole subdomain issue when installing?

I saw that I've already written something about that here.

@HugoPoi
Copy link

HugoPoi commented Aug 28, 2019

I started to investigate, the problem is in the SSO and LDAP check.

What currently happen

  • SSO give a builded email not real one to Seafile for authentication, it's builded like ${YUNOHOST_USERNAME}@${YUNOHOST_SEAFILE_HOSTNAME}
    + username = request.META["HTTP_REMOTE_USER"] + '@' + request.META["HTTP_HOST"]
  • When Seafile check the auth in LDAP, I don't know how but ${YUNOHOST_USERNAME}@${YUNOHOST_SEAFILE_HOSTNAME} is always valid which is wrong
    Edit: after reading some code, and test some, with SSO enable the username is considered trusted so LDAP is checked but no user is found in LDAP and created with default values.
    +class RemoteUserBackend(AuthBackend):
    + """
    + This backend is to be used in conjunction with the ``RemoteUserMiddleware``
    + found in the middleware module of this package, and is used when the server
    + is handling authentication outside of Django.
    + By default, the ``authenticate`` method creates ``User`` objects for
    + usernames that don't already exist in the database. Subclasses can disable
    + this behavior by setting the ``create_unknown_user`` attribute to
    + ``False``.
    + """
    +
    + # Create a User object if not already in the database?
    + create_unknown_user = True
    +
    + def authenticate(self, remote_user):
    + """
    + The username passed as ``remote_user`` is considered trusted. This
    + method simply returns the ``User`` object with the given username,
    + creating a new ``User`` object if ``create_unknown_user`` is ``True``.
    + Returns None if ``create_unknown_user`` is ``False`` and a ``User``
    + object with the given username is not found in the database.

What should be

  • SSO should give the email address of the yunhost account to Seafile (is it possible ?)
  • Seafile LDAP check shouldn't take ${YUNOHOST_USERNAME}@${YUNOHOST_SEAFILE_HOSTNAME} for a valid login if it isn't a valid email in LDAP

@Josue-T
Copy link

Josue-T commented Aug 30, 2019

Seafile LDAP check shouldn't take ${YUNOHOST_USERNAME}@${YUNOHOST_SEAFILE_HOSTNAME} for a valid login if it isn't a valid email in LDAP

This might be really complicated because the LDAP part of seafile is the ccnet and it's written in C.

SSO should give the email address of the yunhost account to Seafile (is it possible ?)

Seeing your patch #46 it's possible

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants