Open fflorent opened 2 years ago
PS: I am not sure whether this is an issue to be reported to Nextcloud or this is related to the Yunohost ecosystem. I would be glad to help if I can, but I need help for the diagnosis.
Same problem here, any ideas? @fflorent did you find a solution?
From the next.cloud.sportdata.org-access.log : [..] "PROPFIND /nextcloud/public.php/webdav/ HTTP/2.0" 401 234 [..]
One difference in my case: I get a login mask when I want to access via the public link.
No, the issue still here :(
7 oct. 2022 09:37:32 clicit @.***>:
Same problem here, any ideas? @fflorent[https://github.com/fflorent] did you find a solution?
From the next.cloud.sportdata.org-access.log : [..] "PROPFIND /nextcloud/public.php/webdav/ HTTP/2.0" 401 234 [..]
— Reply to this email directly, view it on GitHub[https://github.com/YunoHost-Apps/nextcloud_ynh/issues/478#issuecomment-1271225725], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAC2X6OLNFIJPHXDJ25ZPYLWB7HLRANCNFSM5P2BEEHQ]. You are receiving this because you were mentioned.[Image de pistage][https://github.com/notifications/beacon/AAC2X6ORGSUWJM7RGANZHTLWB7HLRA5CNFSM5P2BEEH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOJPCV27I.gif]
Please anyone an idea? Should we report this to Nextcloud directly? Or @fflorent did you do that already?
Exact same issue here. Seems to big to be an issue with Nextcloud. Especially because it is several months old. So I think it should be linked to something in yunohost.
In my case the problem seems to come up with the SSO... Logging-in via the Yunohost Portal sets the cookie "SSOwAuthUser". When I then try to access the public share URL, the SSO credentials are used for the Basic Auth on PROPFIND /public.php/webdav/ ..but Nextcloud expects the share ID here and therefore throws back a 401.
When I delete the cookie, it works. When I access the public share without being logged in, or another browser, or an inkognito tab .. it works.
When I use Postman for the PROPFIND /public.php/webdav/ using the share ID as username (Basic Auth), it works. Same with Postman but using the SSO username: 401 is returned
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\NotAuthenticated</s:exception>
<s:message>Username or password was incorrect</s:message>
</d:error>
Thanks @clicit By the way, I would like to understand the SSO magic at work here in regular case (not in our public link case). Can someone explain to me how Nextcloud did it ? I don't understand how Nextcloud know what user is authenticated. I checked the SAML plugin in Nextcloud, but it is not even installed.
I would like to understand the SSO magic
Nevermind, I finally found my answer myself. https://github.com/YunoHost-Apps/nextcloud_ynh/issues/202#issuecomment-509634352 SSOwat in the reverse proxy (as a nginx module) adds basic auth header in the HTTP request (login and password). Nextcloud uses it to authenticate.
Based on what @clicit said, it should mean that :
So, I'm new to yunohost and so have no skill in app packaging, but from what I could see, the SSOwat configuration is defined as a "permission" within the install script
For example, something like this line define a open access with no header to the .well-known URL (for calldav/cardav resolution) :
ynh_permission_create --permission="api" --label="api" --url="re:$domain\/.well-known\/.*" --allowed="visitors" "all_users" --auth_header="false" --show_tile="false" --protected="true"
Maybe, if we add something like :
ynh_permission_create --permission="public" --label="webdavpublic" --url="re:$domain\/public.php\/.*" --allowed="visitors" "all_users" --auth_header="false" --show_tile="false" --protected="true"
Then it will be reflected in the /etc/ssowat/conf.json file with a new entry preventing header for public webdav access ?
I don't know how to test this without having to reinstall the entire nextcloud application. Does someone know how to execute this kind of script command line as it is in the yunohost installation context for the Nextcloud application ?
(I confirm that the custom permission with --auth_header="false"
should be the right way to address the issue)
Describe the bug
While being connected to Yunohost's SSO, consulting a folder via it's public link doesn't list files in it.
Context
Steps to reproduce
Expected behavior
You should get the list of files even when connected to the Yunohost SSO.
Logs
If you open the Browser DevTools network logs, you get an error with a PROPFIND request (401 Unauthorized):