jedie
December 12, 2020, 11:10am
1
1 Like
You forgot a couple of parameters actually. I am still failing to log in, but the messages are a bit more helpful. Can I push to your testing branch?
jedie
December 12, 2020, 12:58pm
3
I’m done: It worked The “testing” branch already merged.
1 Like
Oh great! I see that you removed the groups permissions, that’s what I was blocking on.
jedie
December 12, 2020, 1:01pm
5
I don’t know if everything is really working. But for now, i can login as superuser that is created on install.
Think a new user, will not work, because of missing setup a new user correctly.
jedie
December 12, 2020, 1:14pm
6
Maybe https://github.com/YunoHost-Apps/pyinventory_ynh/pull/12 will also setup new users as “normal PyInventory” users…
Why not using the Groups and permissions ? (more info here too )
1 Like
jedie
December 12, 2020, 1:41pm
8
Thanks for the link.
Yes, i should see if i can map the Yunohost “admin” user to the Django superuser… But for now, i’m fine with current solution made in https://github.com/YunoHost-Apps/pyinventory_ynh/pull/12 :
first user is superuser
all other users are normal users in PyInventory
But i will add it to the TODO -> https://github.com/YunoHost-Apps/pyinventory_ynh/issues/13
1 Like
ljf
December 12, 2020, 8:50pm
9
See this part of settings_local.py file
# Tous accés # paramétrer SSO en protect_uris # OU # Pas d'accès # hook # paramétrer SSO en protect_uris import ldap from django_auth_ldap.config import LDAPSearch, PosixGroupType AUTHENTICATION_BACKENDS = ( 'django_auth_ldap.backend.LDAPBackend', 'django.contrib.auth.backends.ModelBackend', ) AUTH_LDAP_SERVER_URI = "ldap://localhost:389" AUTH_LDAP_USER_SEARCH = LDAPSearch("uid=YNH_APP_ARG_ADMIN,ou=users,dc=yunohost,dc=org", ldap.SCOPE_SUBTREE, "(uid=%(user)s)") AUTH_LDAP_USER_ATTR_MAP = { "username": "uid", "first_name": "givenName",
jedie
December 13, 2020, 3:26pm
10
Hm. If i see it correct: all sftpusers
users will be a superusers, isn’t it?
ljf
December 13, 2020, 5:49pm
11
Yes, but this package is a bit old, the correct way today is to create several permissions and to refer it. Something like that:
ynh_permission_create --permission "main" --url /
ynh_permission_create --permission "staff" --url /admin/
ynh_permission_create --permission "admin" --url /admin/
And in ldap conf:
AUTH_LDAP_USER_FLAGS_BY_GROUP = {
"is_active": "cn=main.APP,ou=permissions,dc=yunohost,dc=org",
"is_staff": "cn=staff.APP,ou=permissions,dc=yunohost,dc=org",
"is_superuser": "cn=admin.APP,ou=permissions,dc=yunohost,dc=org"
}
J’ai pas testé donc je suis pas sûr à 100%, mais c’est l’idée.
3 Likes
Thanks for your work. I was actually going to start tackling to package benevalibre .
For now, if I understand well, you don’t fetch the user via nginx, but via another login—plugged into the LDAP, right?
1 Like
ljf
December 18, 2020, 12:15am
13
There are 2 ways to connect with a yunohost account:
through LDAP request
with the REMOTE_USER HTTP header (given by ssowat)
Here i show the LDAP method, with a django module plugin, cause the question was django-auth-ldap.
Here you can find documentation for the second method https://docs.djangoproject.com/fr/3.1/howto/auth-remote-user/ .This second method allows to autoconnect a user already connected to the YunoHost User Portal (SSOwat).
It works for django, for other apps, you need to find if the app support it (natively or with a module).
1 Like
jedie
December 18, 2020, 9:38am
14
ljf:
REMOTE_USER HTTP header
think i will look at this. Because then the user can be quickly logged in, if i understand this right…
Maybe a combination is nice
jedie
December 20, 2020, 4:12pm
15
ljf:
REMOTE_USER HTTP header
Can i just trust this header? How to verify it?
ljf
December 20, 2020, 4:42pm
16
Yes you can just trust this header if sso is not configured with a skipped_uris (so if it’s protected or unportected it’s ok). The header “Remote-User” is added by SSOwat with the login of the user logged.
ngx.req.set_header(k, cache:get(user.."-"..v))
end
end
-- Removes the authentication headers. Call me when:
-- - app is public and user is not authenticated
-- - app requests that no authentication headers be sent
-- Prevents user from pretending to be someone else on public apps
function clear_headers()
-- NB: Basic Auth header is cleared in validate_or_clear_basic_auth_header_provided_by_client
for k, v in pairs(conf["additional_headers"]) do
ngx.req.clear_header(k)
end
end
function refresh_user_cache(user)
-- We definitely don't want to pass credentials on a non-encrypted
-- connection.
if ngx.var.scheme ~= "https" then
return redirect("https://"..ngx.var.host..ngx.var.uri..uri_args_string())
In this second link, we see it’s possible to get Name and email too.
https://github.com/YunoHost/yunohost/blob/dev/src/yunohost/app.py#L1395
Searching in code this info, i see the basic auth is also supported. But i don’t know how to use it exactly. It seems the login:password popup is prefilled with the basic auth mechanism of nginx (or a reverse proxy app?)…
jedie
December 20, 2020, 6:57pm
17
Hm. Is there any django app that used this already? I didn’t find something like this…
I’m experimenting here: https://github.com/YunoHost-Apps/pyinventory_ynh/pull/29
I don’t known whats the best practice here, because of the warning in Django docu:
ljf
December 20, 2020, 10:22pm
18
It seems, this warning doesn’t apply for Remote-User header. And i made some test with nextcloud app, and it was not possible to login by adding itself the remote user header
jedie
December 22, 2020, 8:32am
19
I debug a little bit and looked into the sent headers. I add this in nginx:
proxy_set_header REMOTE_USER $remote_user;
I get this:
'HTTP_REMOTE_USER': 'foo,foo'
This is nothing that will work in default RemoteUserMiddleware
implementation…
jedie
December 22, 2020, 9:37am
20
Ah! Strange:
With proxy_set_header X-Remote-User $remote_user;
i get this:
'HTTP_AUTHORIZATION': 'Basic XXXXXXXXXXXXXXXX=',
'HTTP_AUTH_USER': 'foo',
'HTTP_REMOTE_USER': 'foo',
'HTTP_X_REMOTE_USER': 'foo',
I get the same values with: proxy_set_header X-Auth-User $remote_user;
With proxy_set_header REMOTE_USER $remote_user;
this:
'HTTP_AUTHORIZATION': 'Basic XXXXXXXXXXXXXXXX=',
'HTTP_AUTH_USER': 'foo',
'HTTP_REMOTE_USER': 'foo,foo',
And with proxy_set_header OWN_HEADER $remote_user;
this:
'HTTP_AUTHORIZATION': 'Basic XXXXXXXXXXXXXXXX=',
'HTTP_AUTH_USER': 'foo',
'HTTP_OWN_HEADER': 'foo',
'HTTP_REMOTE_USER': 'foo',
And at least proxy_set_header X-WEBAUTH-USER $remote_user;
:
'HTTP_AUTHORIZATION': 'Basic XXXXXXXXXXXXXXXX=',
'HTTP_AUTH_USER': 'foo',
'HTTP_REMOTE_USER': 'foo',
'HTTP_X_WEBAUTH_USER': 'foo',
So, what’s the best choice here?!? Maybe X-Remote-User
?