feature request - support public shared folders

[veselov]

Hello!

It would be nice if the access to shared public folders was supported as well.
In our case, we expose those to certain entities, for either upload or download.
However, some of the handled binaries can be quite large, and we see upload failures in the browser.

[cdujeu]

hello @veselov can you be more specific for describing the failures?
Do you see usecases working via "standard" access whereas failing when going through public links ?
Can you give a proper scenario for reproducing the issue ?

[veselov]

There are no failures.
I'm talking about public folders - access points that are created for distributing off of a particular sub-folder of a cell. Creating those issue a separate URL, and a password (no username).

Now, if all I have is such a link, and a password, I can't ask the client to authenticate against it, and then exchange files back and forth. The current authentication methods don't support that kind of authentication, not that I can see. If nothing else, the username is required, but that's not available for these links.

[cdujeu]

Hi @veselov sorry for not coming on this - are you still waiting some hints on that topic ?

[veselov]

AFAIU, public folders aren't supported, hence this is a feature request.
Are there any questions about my earlier explanation?

[cdujeu]

yes it was clear.
In fact you could use it, but it's just that the way to retrieve the proper login password to connect is a bit hacky. Are you familiar with the developer console in the browser ? ;-)

[veselov]

Interesting.
I see that the browser makes the following request:

POST https://<hostname>/a/frontend/session

{"AuthInfo":{"login":"d09***","password":"bZ***","type":"credentials"}}

replied to with a JWT token.

I see that request is followed up by a GET to https://<hostname>/a/frontend/state?, which includes a cookie that is probably somehow encoded token; the response is 200, is an XML document with <pydio_registry> root.

I can also see that the login doesn't change between consecutive attempts to log in (but not sure how is it derived from the URL).

However, when I try to configure the cec client with these creds, I get an error:

[vps@phoenix]~/tmp$ cec config add
✔ Client Auth (direct login/password, less secure)
Server Address (provide a valid URL): https://<hostname>/
✔ No
User Login: d09***
User Password: ************
2025/02/24 12:48:24 ... Authenticated request failed, cause: Get "https://<hostname>/a/frontend/state": [POST /frontend/session][401] frontSessionUnauthorized {"Detail":"Unauthorized: Login failed","Title":"Login failed"}
2025/02/24 12:48:24 ✗ could not save configuration: could not connect to distant server with provided parameters. Discarding change

So yes, I'd appreciate some hints on this.

[erpadmin]

I'd like to see public links supported by the cells client to enable activity similar to
$ cec ls https://example.com/public/cb59e42e9664
$ cec scp https://example.com/public/cb59e42e9664 ~/downloads/

The users prefer not to have to create shared/external users so they can use the cli. An issue that contributes to this is that the public links don't not directly link to the files or folders in a way that users can fallback to using wget (I remind them they won't want to do this on multi gig files anyway). They don't always want to use the http interface.

I realize there are probably auth and other framework hurdles involved here, but any achievable workflow streamlining will go a long way for the product IMO.

[erpadmin]

@veselov did you make progress? It looks like you are deriving the credentials associated with the public link but I wonder if that would even work if there is no user on the backend that is associated.

I personally create a shared user and then created a PAT that expires and share something to the user. That works with the token option.

[veselov]

@erpadmin No, sorry, hence this thread. @cdujeu 's earlier response suggested that it's possible to derive the credentials, but I don't know how the public URL is converted to a username, nor how to use the same credentials browser ends up using in command-line cec.

but I wonder if that would even work if there is no user on the backend that is associated.

It somehow must work as the browser is able to log in, and I don't have such user on the backend side; it looks like the backend creates a "fake" username for each public URL.

[erpadmin]

@veselov I was having a chat with our soon to be sentient AI tonight and it looks like there is an angle to achieve this using the webdav endpoint. I've only performed a couple of trivial tests, but it looks promsing.

$ curl -s -X PROPFIND "https://example.com/public/fd303c1e81fb/dav/" | xmllint --xpath '//*[local-name()="href"]/text()' -
/public/fd303c1e81fb/dav/
/public/fd303c1e81fb/dav/justafile.txt


$ curl -s https://example.com/public/fd303c1e81fb/dav/justafile.txt
This is this contents of justafile.txt

[erpadmin]

I should clarify that if curl is working, this simplifies things quite a bit.

UPDATE: From what I can tell this approach would be basically HTTP upload,download with no multipart functionality. Not particularly useful for large files.

[cdujeu]

Hey @erpadmin
Yes, the DAV enablement on public link was indeed thought with that in mind => direct curl/wget on a public link file.
It works well for no-password case
But we still have a missing bit for "exposing" the credentials in the password-protected link case...

[erpadmin]

Back the original issue of the cli credentials. After removing the hidden: true attribute on the user record, a session can be established.

PUT /a/frontend/session
Body

{
  "AuthInfo": {
     "login": "515ac33fe9484c6e",
     "password": "515ac33fe9484c6e#$!Az1",
     "type": "credentials"
 },
}

Response

{
	"JWT": "N31IJJAVPOrLb1hVr_IN39FYqLutIzsqxcNa8yuzzEI.AGg8oKFZRUpYqfGtvZHlekKPCrJae6VhvBBnzbJ1jyQ",
	"ExpireTime": 1757452509,
	"Token": {
		"AccessToken": "N31IJJAVPOrLb1hVr_IN39FYqLutIzsqxcNa8yuzzEI.AGg8oKFZRUpYqfGtvZHlekKPCrJae6VhvBBnzbJ1jyQ",
		"IDToken": "eyJhbGciOiJSUzI1NiIsImtpZCI6InB1YmxpYzpoeWRyYS5vcGVuaWQuaWQtdG9rZW4iLCJ0eXAiOiJKV1QifQ.eyJhdF9oYXNoIjoiU3JqM2tpVXVRSFhid09SX3doUENBUSIsImF1ZCI6WyJjZWxscy1mcm9udGVuZCJdLCJhdXRoU291cmNlIjoiUHlkaW8gQ2VsbHMiLCJhdXRoX3RpbWUiOjE3NTc0NTE5MDksImVtYWlsIjoiIiwiZXhwIjoxNzU3NDU1NTA5LCJpYXQiOjE3NTc0NTE5MDksImlzcyI6Imh0dHBzOi8vY2VsbHMucHlwcm90by54eXovb2lkYy8iLCJqdGkiOiJhMzgwMzk4Zi03NDVkLTQzMzAtYjM1YS1lYWQ1NTA3NWE5ZWYiLCJuYW1lIjoiNTE1YWMzM2ZlOTQ4NGM2ZSIsInJhdCI6MTc1NzQ1MTkwOSwic2lkIjoiZWFlOTRiNWYtNDhjOC00N2JkLThiNWQtMjJmMzM0NzIwOWE5Iiwic3ViIjoiNTE1YWMzM2YtZTk0OC00YzZlLWFkNzQtMGQ3MjdjNGY5MTE1In0.nEIGfj5It53yw9GJIyK65D7_flcqGMgxlstuJgt8Wa6IO7R2pimVrqxaZFrm14O53plFDxF9dGxpHpaGiYbGxlbpxa-_7_P1cDsFLCjH0O44kzgctGc-24tYOmD3UW1sLhd03ZXKgyTPkqqngLhh6mUYqMryraVkWKWckm3vMiqsGel2BCufFS7B4hhPlPUZWCR7i_h_4TvRus9AYdeaxTfLlZTnYSxyj3AKK8Y9pLk07aQqtzGsSz8kzezZWhPyGLicngMIkHC9BIhzt5_j5c3a_U95b8dNnwhRjToSSPv-vIHR9HbC3nY0_l7BnLmL_gNEGbyQkAyhlqMR_gJ903-2-5fSDMyjSUTfmIK0-l-LG0dMxKTA-dlpSPC3bn4y1b8Bd0oxPyGjM1TzyIF2jL0-q2CReko9Uke0xzENSVJRHPVSvP6LBYCgaTl7J05OYxXCLB_7EotPmb2h4_Z-bu0z65b89v-ib2QFmzuiMDak9cQc1JasWJNDIikRRO3MEmfx-MH2A8102kVqI-7jrjLFyX-6X_-nzu2gfMYnTsVMpwRmOO55ikbFUUs7Vgg5MYgN3KlP_8UmBC0hukkuEA9qgir99HwgaWg_XMIwdF5nkfRU9K4KoRtsE8qzSmvf2CZyTENHPak__4iqgjDAZP6hWEmJLbwxGbjdguGBpj0",
		"ExpiresAt": "1757452509"
	}
}

From what I can tell the pydio.min.js handles providing the authinfo to the browser but I wasn't able to figure out how to replicate the behavior in code.