-
Does this generally work? The docs says it does but I can't get it to authenticate with my cloudron credentials. Tried the windows drive mounter, chromium, and firefox... no dice.
I saw this still-open GH issue referenced in another thread:
https://github.com/OpenMarshal/npm-WebDAV-Server/issues/85But my PW doesn't contain a colon... and is that still what surfer uses for webdav auth? I don't think I want any of my content protected by an auth library that, according to the repo, hasn't been updated in four years??
-
@drew said in webdav on surfer:
I can't get it to authenticate with my cloudron credentials
I think perhaps the docs are out of date and you now need to use an access token. @nebulon
-
G girish moved this topic from Support on
-
N nebulon marked this topic as a question on
-
N nebulon has marked this topic as solved on
-
Hrm... using the API key as the PW I'm still getting 401s. Updated to the latest version that just dropped, too. I tried using the API key as the password with my cloudron username, no username, the api key name, on a URL with the trailing slash in the docs, without, in a subdirectory, using the windows native client and firefox, and I still can't get it to authenticate.
Any idea where I should go from here? It's not a production site so "blow it away and try again" is fine as long as it stands a chance of working.
The credential values are definitely correct and I know the URL is hitting the right place because I can see the requests in the logs:
[etc. etc. etc. ] Sep 26 12:34:28OPTIONS /_webdav 401 0.850 ms - - Sep 26 12:34:28OPTIONS /_webdav 401 1.054 ms - - Sep 26 12:34:28OPTIONS /_webdav 401 1.400 ms - - Sep 26 12:34:29PROPFIND / 200 1.722 ms - 2077 Sep 26 12:36:00OPTIONS /_webdav 401 1.484 ms - - Sep 26 12:36:00OPTIONS /_webdav 401 2.019 ms - - Sep 26 12:36:01OPTIONS / 200 2.816 ms - 2077 Sep 26 12:36:01OPTIONS /_webdav 401 0.968 ms - - Sep 26 12:36:01PROPFIND / 200 1.397 ms - 2077 Sep 26 12:41:19GET /wp-login.php 404 2.514 ms - - Sep 26 12:41:32GET /_webdav/ 401 0.832 ms - - Sep 26 12:41:41GET /_webdav/ 401 1.130 ms - - Sep 26 12:42:13GET /favicon.ico 404 1.339 ms - - Sep 26 12:42:14GET /_webdav 401 0.924 ms - - Sep 26 12:42:20GET /_webdav 401 0.942 ms - - Sep 26 12:43:38GET /_webdav 401 0.911 ms - - Sep 26 12:43:44GET /_webdav/ 401 0.711 ms - - Sep 26 12:44:01GET /_webdav/ 401 1.219 ms - - Sep 26 12:45:07GET /_webdav/ 401 0.755 ms - - Sep 26 12:45:14GET /_webdav/ 401 0.723 ms - - Sep 26 12:45:22GET /_webdav 401 1.043 ms - - Sep 26 12:45:24GET /_webdav 401 0.770 ms - - Sep 26 12:46:30GET /_webdav/public/ 401 0.751 ms - - Sep 26 12:46:33GET /_webdav/public/ 401 0.780 ms - - Sep 26 12:46:41GET /_webdav/public/ 401 0.671 ms - - Sep 26 12:46:50GET /_webdav/public 401 2.330 ms - - Sep 26 12:46:54GET /_webdav/public 401 0.719 ms - - Sep 26 12:46:57GET /_webdav/public 401 0.771 ms - -``` -
Just tried also on a fresh installation and as far as I can tell nothing really changed there and it works at least from the gnome filemanager with the uri
davs://surfer.domain.com/_webdavand username (which is not relevant) and the api token for the password. -
@nebulon said in webdav on surfer:
Just tried also on a fresh installation and as far as I can tell nothing really changed there and it works at least from the gnome filemanager with the uri
davs://surfer.domain.com/_webdavand username (which is not relevant) and the api token for the password.It does work. But unlike other webdav mounts (i.e. my various Nextcloud accounts) it doesn't stay connect/ remember the password like it used to before you moved to Access Tokens only.
I find this rather frustrating as every time I want to do anything on my local machine, like save a file to my Surfer app, I first have to login via the web and copy the Access Token again.
-
@nebulon but it does cache it for Nextcloud username/ passwords and used to cache it for Surfer too before you changed it to acess token/ pw only.
The only thing that has changed in my set up is Surfer itself.
-
@jdaviescoates yeah, that is what is strange. for the client, the access token is no different from a password. there's no difference.
-
@girish said in webdav on surfer:
@jdaviescoates yeah, that is what is strange. for the client, the access token is no different from a password. there's no difference.
I worked it out!
When clicking Connect in Nautilus, it wasn't prompt/ asking if I wanted to save my password at all, I was just presented with this:
And the only thing possible to do when that screen is displayed it to either enter a password or cancel, it's not even possible to view another app or anything.
But it seems it should as per e.g. this image from this guide https://www.knthost.com/nextcloud/setup-gnome-nautilus-access-nextcloud-files-webdav
And because I must've chosen "Remember forever" when setting up Nextcloud mount (either that or just adding Nextcloud Accounts via Ubuntu Online Account settings does that anyway), when I tried testing it with an instance of Nextcloud instead of Surfer it doesn't even ask for a password at all. So I figured it must've remember the password somewhere...
So I searched for Passwords and found this Passwords and Keys app that I've never seen/ used before
And I saw there was a pw stored for library.uniteddiversity.coop
But of course that was the old password before Surfer updated to just use access tokens. So I edited the pw to be the new access token, and now it all works again! Phew.
And just to test, I decided to try and connect to a Surfer app that I've never tried to mount locally before, and lo and behold this time it did show this:
Although I note that Nautilus required me to add a Username before being able to hit the Connect button (the button remained greyed out until both a Username and Password were entered into the fields).
Anyways, all working again now (and now I now where to find/ how to change the "Remembered forever" passwords too, so bonus!)
