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.

Sign up for GitHub

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

Jump to bottom

conflict with webdav access by gvfs #94

Closed
landryb opened this issue Oct 14, 2020 · 4 comments
Closed

conflict with webdav access by gvfs #94

landryb opened this issue Oct 14, 2020 · 4 comments
Assignees
@landryb
Labels
enhancement quality-control
Milestone
1.9

Comments

@landryb
Copy link

landryb commented Oct 14, 2020

At first i thought this was a comeback of the webdav problems fixed in #77, but after carefully checking, i came to the conclusion that gio/gvfs (used by gtk linux files browsers, thunar, nautilus, etc..) does something (wrong or not ? i'm not the one to judge, but the code has been this way for ages. There's a ticket in upstream gvfs at https://gitlab.gnome.org/GNOME/gvfs/-/issues/168) to the url sent when connecting to nextcloud webdav:

$gio mount davs://nextcloud_server/remote.php/webdav/
User:
Password:
gio: davs://nextcloud_server/remote.php/webdav: Erreur HTTP : Found

yes, the user specified the trailing /, but gvfs removes it in https://gitlab.gnome.org/GNOME/gvfs/-/blob/master/daemon/gvfsbackendhttp.c#L110 (really, dont ask me why)

So here's what happens serverside

"OPTIONS /remote.php/webdav HTTP/1.1" 401 426 "-" "gvfs/1.44.1" # nextcloud returns a 401, so client replies with an Authorization header
"OPTIONS /remote.php/webdav HTTP/1.1" 200 0 "-" "gvfs/1.44.1" # user is authenticated
"PROPFIND /remote.php/webdav HTTP/1.1" 302 438 "-" "gvfs/1.44.1" # user_cas returns a 302 found redirecting to logout

with cadaver or winscp, the trailing / is sent, and the server correctly behaves:

"OPTIONS /remote.php/webdav/ HTTP/1.1" 401 426 "-" "cadaver/0.23.3 neon/0.30.2" # nextcloud returns a 401, so client replies with an Authorization header
"OPTIONS /remote.php/webdav/ HTTP/1.1" 200 0 "-" "cadaver/0.23.3 neon/0.30.2" # user is authenticated
"PROPFIND /remote.php/webdav/ HTTP/1.1" 207 630 "-" "cadaver/0.23.3 neon/0.30.2" # everything is fine, webdav kicks in

with tcpdump and phpcas logging enabled, here's what is triggered with gvfs:

"PROPFIND","url":"/remote.php/webdav","message":"Logout hook triggered.","userAgent":"gvfs/1.44.1","version":"18.0.10.2"}

and here's the content sent to the webdav client along the 302 location redirecting to cas:

<html><head><title>CAS logout wanted!</title></head><body><h1>CAS logout wanted!</h1><p>You should already have been redirected to the CAS server. Click <a href="https://cas_server/logout?service=https%3A%2F%2Fnextcloud_server%2F">here</a> to continue.</p><hr><address>phpCAS 1.3.8 using server <a href="https://cas_server/">https://cas_server/</a> (CAS 3.0)</a></address></body></html>

i'm blaming it on user_cas module, because gvfs manages to connect fine to a nextcloud instance without user_cas module... seems some different codepath is taken whether the url has a trailing slash or not ?

so, can we envision doing something specific with a broken gvfs UA ? Strangely, this worked fine with nc 15.0.7 and user_cas 1.6.2, i'm pretty sure i had it working with nc 18.0.2 & user_cas 1.8.1 (when i tested/debugged #77), and now i cant get it to work with nc 18.0.10 & user_cas 1.8.1 or user_cas 1.8.6. Puzzling.
@landryb
Copy link
Author

landryb commented Oct 15, 2020

I've rechecked against another old dev instance running nc 15.0.7 + user_cas 1.6.2, and with that broken behaviour of dropping the trailing /, user_cas doesnt interfere in the webdav auth flow:

> PROPFIND /remote.php/webdav HTTP/1.1
> Authorization: Basic [username:******]
                                                                                                                           
> <?xml version="1.0" encoding="utf-8" ?>                                                                                                                                                                                                      
>  <D:propfind xmlns:D="DAV:">                                                                                                                                                                                                                 
>   <D:prop>                                                                                                                                                                                                                                   
> <D:resourcetype/>                                                                                                                                                                                                                            
> <D:getcontentlength/>                                                                                                                                                                                                                        
>   </D:prop>                                                                                                                                                                                                                                  
>  </D:propfind>    

< HTTP/1.1 207 Multi-Status                                                                                                                                                                                                                    
< <?xml version="1.0"?>                                                                                                                                                                                                                        
< <d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns" xmlns:nc="http://nextcloud.org/ns"><d:response><d:href>/remote.php/webdav/</d:href><d:propstat><d:prop><d:resourcetype><d:collection/></d:resourcetype></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat><d:propstat><d:prop><d:getcontentlength/></d:prop><d:status>HTTP/1.1 404 Not Found</d:status></d:propstat></d:response></d:multistatus>

at that point the gio mount has succeeded (i can see in nextcloud debug log that user_ldap module paged search was triggered to find the authenticated user), but the client still does another subsquent request that also triggers user_cas:

> OPTIONS /remote.php/ HTTP/1.1                                                                                        
< HTTP/1.1 302 Found
< Location: https://cas_server/cas/logout?url=https%3A%2F%2Fdrive.dev.craig.fr%2F

so something changed between user_cas 1.6.2 and 1.8.6 that triggers a new behaviour ? I dont feel like its the singlesignout feature addition, since i can replicate the problem after reverting to 1.8.1.. something changed between nc 18.0.2 & 18.0.10 ?

@felixrupp felixrupp self-assigned this Dec 23, 2020
@felixrupp felixrupp added this to the 1.9 milestone Dec 23, 2020
@felixrupp felixrupp added enhancement and removed bug labels Dec 23, 2020
@felixrupp
Copy link
Owner

Probably a duplicate of #57

landryb referenced this issue Dec 24, 2020
@felixrupp
issue-57-Filter_WebDAV_requests_possible_conflict_with_webdav_using_w…
0844725 
…indows_explorer: Add filter for DAV requests
@felixrupp
Copy link
Owner

Fixed in version 1.9. Please review the function and close the ticket afterwards. Thanks!

@felixrupp felixrupp assigned landryb and unassigned felixrupp Feb 14, 2021
@landryb
Copy link
Author

landryb commented Feb 15, 2021

i can happily confirm that i've been able to successfully use gio mount davs://nextcloud_server/remote.php/webdav/ (and then browse the folders in a gio-enabled file browser) against a nextcloud 18 instance using user_cas 1.9.0, while i'm not able to do so on a nextcloud 18 instance still using user_cas 1.8.6. So i think commits 0844725, 2918822 and 5917ddc tackled this annoying issue !

Many thanks !

@landryb landryb closed this as completed Feb 15, 2021
@landryb landryb mentioned this issue Feb 15, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@landryb landryb

Labels
enhancement quality-control
Projects
None yet
Milestone
1.9
Development

No branches or pull requests
2 participants
@felixrupp @landryb