Folders shared publicly empty when connected with SSO

[fflorent]

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

• Hardware: not relevant here
• YunoHost version: 4.3.6.2
• I have access to my server: Through SSH + through the webadmin
• Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: no

Steps to reproduce

1. Disconnect from Yunohost SSO
2. Connect to Nextcloud directly: https://domain.tld/nextcloud/login
3. Create a folder
4. Create a file in this folder (whatever it is)
5. Generate a public link for the folder (not the file)
6. Open a new tab and go to the copied public link : You should get the folder content
7. Now, login to Yunohost SSO
8. Go back to the tab with the public link to the shared folder
9. Refresh the tab: now, you should get an empty list of files

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):

[fflorent]

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.

[clicit]

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.

[fflorent]

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]

[clicit]

Please anyone an idea? Should we report this to Nextcloud directly? Or @fflorent did you do that already?

[dalgwen]

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.

[clicit]

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>

[dalgwen]

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.

[dalgwen]

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.

[dalgwen]

Based on what @clicit said, it should mean that :

• if we prevent SSOwat from setting the basic auth header for the /public.php/webdav URL
• Then we won't have the 401 on the PROPFIND request (assuming that it is the real underlying issue)

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 ?

[alexAubin]

(I confirm that the custom permission with --auth_header="false" should be the right way to address the issue)