Encrypted libraries in seafile v11

Seafile Server
1

Hi,

I can’t seem to open encrypted libraries in seahub (seafile web interface).

1 - Create the library with a password (either using seafile desktop client or seahub).
2 - Use a browser (private browsing for example)
3 - Login to Seafile in browser (this is called seahub right ?)
4 - Try to open an encrypted library with the password you’ve set
5 - Seahub says “wrong password”

I have had the case with v11.0.1 and v11.0.2.
I have tried passwords with @ and $, and then only upper and lower case letters.
Same result everytime.

I’m not sure how I would be the first one to discover this :smiley: . Must be something on my setup ?

EDIT :
So I’ve tried another thing :

  • it still doesn’t work when I try from the browser
  • but it does work when I try from seafile desktop app using “open cloud file explorer”.
  • It then asks for the password, which I give, and it deems it correct.

After doing this, the real browser can open the encrypted library and doesn’t ask for password.

Moreover, deleting a library on seahub is refused, saying “permission denied”.

I’m beginning to wonder if it wouldn’t be something linked to LDAP accounts not having the same rights as classic seafile accounts. I’m currently using a ldap account.

2

We can’t reproduce the problem with newly installed Seafile v11, even with LDAP account. By the way, the feature should be independent of the LDAP feature.

3

Well then, I checked the logs and here is what I get when I try to enter an encrypted library on browser (which doesn’t work) :

tail -f seahub.log

2023-11-23 09:41:14,459 [INFO] xmlschema:1234 include_schema Resource ‘XMLSchema.xsd’ is already loaded
2023-11-23 17:31:39,738 [INFO] xmlschema:1234 include_schema Resource ‘XMLSchema.xsd’ is already loaded
2023-11-23 17:31:48,182 [INFO] xmlschema:1234 include_schema Resource ‘XMLSchema.xsd’ is already loaded
2023-11-23 17:32:11,311 [WARNING] django.request:241 log_response Forbidden: /api/v2.1/repos/83480555-77e3-4dd9-8196-5c8ab21f648d/set-password/

Is it normal behavior ?

And then, when I try to enter an encrypted library from “cloud explorer” in desktop app (which works) I get no log at all.

Moreover, this is what I get in seahub.log when I try to delete such a library in browser :

2023-11-23 17:40:18,697 [WARNING] django.request:241 log_response Forbidden: /api/v2.1/repos/4424c49a-f259-40a8-8b75-685ca4ce05d7/

4

2023-11-23 17:32:11,311 [WARNING] django.request:241 log_response Forbidden: /api/v2.1/repos/83480555-77e3-4dd9-8196-5c8ab21f648d/set-password/

This is the most related log. You can investigate why the API call is forbidden.

5

SERVICE_URL & SEAFILE_ROOT are correctly filled.
But when I try to change SERVICE_URL, this is what I get :

image
image712×25 916 Bytes

image

It’s the same thing for trying to enter an encrypted library :

image
image913×48 2.41 KB

image

From what I understand, to login in seahub I already had the problem and had to add my domain to seahub_settings.py with this command :

CSRF_TRUSTED_ORIGINS = [“https://hub.tata.casa”]

Is there something else I must do for the app to not block my requests ?

EDIT : this being a problem with csrf is quite unexpected, because some requests do work :

image
image1574×89 6.65 KB

6

So I tried to start all over on a different server, and, after adjusting config file, saw that it was working.
After comparing the two setups, I understood what was preventing my original server from working were my attempts to make the CSRF work in HAPROXY (the reverse proxy I used).
Erasing them and setting a simple config in HAPROXY did the trick.

Nonetheless, I did some simplification in my setup which I will share below :

The “fixes” are these one :

  • Added the startup of seaf_fuse to start.py
  • Changed bootstrap.py and setup-seafile-mysql.py in order to get https in the domain name of multiple fields in seahub_settings.py
  • Added CSRF_TRUSTED_ORIGINS = “your domain here” to seahub_settings.py in order to not have to modify it by hand after setup.

@daniel.pan something I see as an anomaly I wish to share to the team :
The current environment option in docker-compose

SEAFILE_SERVER_LETSENCRYPT=false # Whether to use https or not.

is wrong in its current use. I shall explain myself :

I use a seperated reverse proxy, which manages itself the different certificates for domain names.

  • That does mean I do not need letsencrypt on seafile
  • That doesn’t mean I will access to seafile unprotected (http).

I will access seafile protected (https), using my reverse proxy. (And I do believe this is the most common case…!)

The current official setup is made so that if you answer false on “SEAFILE_SERVER_LETSENCRYPT”, the 2 or 3 fields in seahub_settings.py will be prefixed with HTTP instead of HTTPS.

I’m no expert, but today’s web and intranets should be completely secured, there is no one who should default to http (without S) use.

In my custom docker image, I’ve set it to HTTPS prefix in seahub_settings.py by modifying bootstrap.py and setup.py.

A cleaner way to answer this problem would be to seperate https in two environment fields in the Dockerfile, one for let’s encrypt, and one for accessing to the services.

Thanks for reading.