Unable to log into web interface since upgrade about seafile-containerized HOT 25 CLOSED

I had the same issue, also with a different browser.

The fix from Larrikinau worked but only with a small modification, I had to remove the trailing slash.
So my working modification in seahub_settings.py is:
CSRF_TRUSTED_ORIGINS = ['https://myseafiledomain.com']

from seafile-containerized.

I have a friend who is an expert and told me how to fix it. Unfortunately I can't provide any context as to how this fixed the problem, only that it did.

With the docker down, I had to edit the file seahub_settings.py

At the end of that file, I had to add the following line:

CSRF_TRUSTED_ORIGINS = ["https://myseafiledomain.com/"]

The myseafiledomain.com is replaced with my actual domain that I use to access seafile.

Started the docker, and boom, it fixed it.

No idea why as it's beyond my knowledge, and my friend is working at the moment and doesn't have the time to explain. Will try and find out more later.

from seafile-containerized.

I've dedicated some time to further investigate the issue. The bootstrap.py script included in this project relies on the environment variables HTTPS and SEAFILE_SERVER_HOSTNAME to construct the FILE_SERVER_ROOT configuration. However, this setup script does not configure the SERVICE_URL.

The SERVICE_URL is actually configured by the setup-seafile-mysql.py script, which is bundled with Seafile. In this script, the http protocol is hard coded. Thus people using the official Docker deployment are reporting the same issue haiwen/seafile#2707. This discrepancy was inconsequential in older versions because Django did not enforce matching protocols. However, it now leads to these issues.

I've implemented a workaround to address this issue for new deployments. The protocol is now set correctly in the SERVICE_URL.

If you encounter login problems after upgrading, please follow these steps to resolve the issue:

1. Update SERVICE_URL in seahub_settings.py:
   Ensure the SERVICE_URL protocol is set correctly to reflect https or http as required by your deployment. While this value might be overlooked by Seafile, maintaining coherence in your configuration is beneficial.

2. Temporarily Adjust CSRF Settings:
   Add the following line to your seahub_settings.py: CSRF_TRUSTED_ORIGINS = ['https://myseafiledomain.com']
   Replace https://myseafiledomain.com with your actual Seafile domain. Restart seahub to apply these changes.

3. Log in and Adjust Settings via Web UI:
   After successful login, go to the System Admin section of the web interface. Set the SERVICE_URL as above.

4. Revert CSRF Settings:
   Once the SERVICE_URL is correctly configured and functioning, remove the CSRF_TRUSTED_ORIGINS line from your seahub_settings.py. Restart the seahub service once more for the changes to take full effect.

from seafile-containerized.

I've just seen your comment here haiwen/seafile#2707 (comment)

Try to replace

proxy_set_header X-Forwarded-Proto $scheme;

with

proxy_set_header X-Forwarded-Proto https;

In your nginx config it seems like it is listening to port 80. So if you are using https, there must be another reverse proxy in front of it listening to port 443, which then proxies to this nginx.

If you require further assistance, please detail your network setup, specifically in regard to which proxies are traversed when accessing your Seafile setup.

from seafile-containerized.

Hi, thanks for the issue report.

Please try to clear your browser cache or try another browser.

Is there anything in the logs?

from seafile-containerized.

Glad you solved it!

For some reason, it works for me without that config on two different setups.

from seafile-containerized.

Thanks for reporting 👍

After reading the Django Documenation, it seems to me like your request is seen by Django as coming from a different server. The check also includes the correct protocol (HTTP or HTTPS).

Can you check if the SERVICE_URL shown in the System Admin settings of Seafile matches your URL, including HTTPS?

It could also be that the Origin header is set incorrectly somewhere in your reverse proxy setup.

from seafile-containerized.

HI there :D

I'm having the same issue with a fresh deployment.

Here's the relevant part of my docker-compose file

    environment:
      - HTTPS=true
      - SEAFILE_SERVER_HOSTNAME=sea.watn3y.de 

After inspecting seahub_settings.py I can see that the protocol is not set to https everywhere.

SERVICE_URL = "http://sea.watn3y.de/"
...
FILE_SERVER_ROOT = "https://sea.watn3y.de/seafhttp"

Did I misunderstand the docs or is HTTPS=true not doing what it should?

from seafile-containerized.

The environment variable HTTPS is only used for the intital deployment to construct the SERVICE_URL. Seafile then takes this value and writes it into the database. This value in the database takes precedence over the config file. You can only change it from the admin settings in the web UI or by overwriting the value in the database directly.

For the sake of coherence make sure that both values match and contain https.

from seafile-containerized.

I had this same issue yesterday, and I tried to fix it "literally adding the 's' to HTTPS in my SERVICE_URL" but I didn't realize at the time that my drive was completely 100% full. It gave me a warning about how it was truncating the file, and I foolishly saved my seahub_settings.py. Next time I opened it (after clearing some space) it was completely blank. I don't have a backup of that particular file and it seems to have nuked my system for now-- it couldn't have been more than 10-12 lines long-- can someone send me a template for what data was in this file, or should I try to re-run the setup-seafile-mysql.py script? Every example from the official seafile docker repo seems to contain much more information than I ever had in this file, so I feel like it's a different organizational system.

If all else fails I'll do a fresh install in a VM and try to figure out what I'm missing, but if anyone has a quick solution I'd appreciate it...

from seafile-containerized.

You could create a second deployment, specifying a different project name with the parameter p. Then copy the file from there.

from seafile-containerized.

thanks, i'll give that a shot--

from seafile-containerized.

wow, i can't believe the extent of the havoc wreaked by the loss of this one file... I recreated it under a different name as you suggested, and I'm, able to use most of it, but then my db image was complaining about not being able to authenticate with the generated mysql user + pass. I've been migrating this system along for a long time, so I'm not sure if I have some older settings that are conflicting, but now when I alter seahub_settings.py to reflect what I think the proper mysql creds are (root/password) I can access the login screen of seafile, but it gives either the CSRF error or a generic "Page Unavailable" if I have the CSRF_TRUSTED_ORIGINS parameter filled in. I believe this is a database access error, but I'm having trouble figuring out which module I should focus my troubleshooting on. I don't remember ever having to enter this mariadb login information manually into seahub_settings.py before, but I don't understand why it generates with unusable login creds from my docker-compose.yml...

from seafile-containerized.

When setting up Seafile for the first time, it executes a bootstrapping script for application and database configuration. During this process, Seafile utilizes the provided root credentials of the database to establish the necessary databases. It then creates a seafile user account, assigns it an auto-generated password, and records these details in the seahub_settings.py file.

Now there's a mismatch in these credentials. Use the root user to access the database. Update the seafile user's password to match the new value found in the seahub_settings.py.

Additionally, check for errors by executing docker logs on the seahub container.

Be aware that a full volume might have caused other file corruptions. To prevent such issues in the future, consider setting up a backup system.

from seafile-containerized.

I've dedicated some time to further investigate the issue. The bootstrap.py script included in this project relies on the environment variables HTTPS and SEAFILE_SERVER_HOSTNAME to construct the FILE_SERVER_ROOT configuration. However, this setup script does not configure the SERVICE_URL.

The SERVICE_URL is actually configured by the setup-seafile-mysql.py script, which is bundled with Seafile. In this script, the http protocol is hard coded. Thus people using the official Docker deployment are reporting the same issue haiwen/seafile#2707. This discrepancy was inconsequential in older versions because Django did not enforce matching protocols. However, it now leads to these issues.

I've implemented a workaround to address this issue for new deployments. The protocol is now set correctly in the SERVICE_URL.

If you encounter login problems after upgrading, please follow these steps to resolve the issue:

1. Update SERVICE_URL in seahub_settings.py:
   Ensure the SERVICE_URL protocol is set correctly to reflect https or http as required by your deployment. While this value might be overlooked by Seafile, maintaining coherence in your configuration is beneficial.
2. Temporarily Adjust CSRF Settings:
   Add the following line to your seahub_settings.py: CSRF_TRUSTED_ORIGINS = ['https://myseafiledomain.com']
   Replace https://myseafiledomain.com with your actual Seafile domain. Restart seahub to apply these changes.
3. Log in and Adjust Settings via Web UI:
   After successful login, go to the System Admin section of the web interface. Set the SERVICE_URL as above.
4. Revert CSRF Settings:
   Once the SERVICE_URL is correctly configured and functioning, remove the CSRF_TRUSTED_ORIGINS line from your seahub_settings.py. Restart the seahub service once more for the changes to take full effect.

These instructions seem pretty clear to me - but it's possible I am doing something wrong.

In Unraid, stopping Seafile, downloading seahub_settings.py file, making sure SERVICE URL is "https"(cloudflare reverse proxy/tunnel), removing the CSRF_TRUSTED_ORIGINS part, saving seahub_settings.py, uploadinb back to Unraid, setting file owner/permissions back to file and starting Seafile container.. Still get CSRF errors after triple checking in Settings that Service URL is "https" as well.

Not sure, but I can't seem to find any way around having the CSRF_TRUSTED_ORIGINS thing at moment on Seahub Instance that has already been installed, not a new install.

Any other ideas mate?

from seafile-containerized.

I've dedicated some time to further investigate the issue. The bootstrap.py script included in this project relies on the environment variables HTTPS and SEAFILE_SERVER_HOSTNAME to construct the FILE_SERVER_ROOT configuration. However, this setup script does not configure the SERVICE_URL.
The SERVICE_URL is actually configured by the setup-seafile-mysql.py script, which is bundled with Seafile. In this script, the http protocol is hard coded. Thus people using the official Docker deployment are reporting the same issue haiwen/seafile#2707. This discrepancy was inconsequential in older versions because Django did not enforce matching protocols. However, it now leads to these issues.
I've implemented a workaround to address this issue for new deployments. The protocol is now set correctly in the SERVICE_URL.
If you encounter login problems after upgrading, please follow these steps to resolve the issue:

1. Update SERVICE_URL in seahub_settings.py:
   Ensure the SERVICE_URL protocol is set correctly to reflect https or http as required by your deployment. While this value might be overlooked by Seafile, maintaining coherence in your configuration is beneficial.
2. Temporarily Adjust CSRF Settings:
   Add the following line to your seahub_settings.py: CSRF_TRUSTED_ORIGINS = ['https://myseafiledomain.com']
   Replace https://myseafiledomain.com with your actual Seafile domain. Restart seahub to apply these changes.
3. Log in and Adjust Settings via Web UI:
   After successful login, go to the System Admin section of the web interface. Set the SERVICE_URL as above.
4. Revert CSRF Settings:
   Once the SERVICE_URL is correctly configured and functioning, remove the CSRF_TRUSTED_ORIGINS line from your seahub_settings.py. Restart the seahub service once more for the changes to take full effect.

These instructions seem pretty clear to me - but it's possible I am doing something wrong.

In Unraid, stopping Seafile, downloading seahub_settings.py file, making sure SERVICE URL is "https"(cloudflare reverse proxy/tunnel), removing the CSRF_TRUSTED_ORIGINS part, saving seahub_settings.py, uploadinb back to Unraid, setting file owner/permissions back to file and starting Seafile container.. Still get CSRF errors after triple checking in Settings that Service URL is "https" as well.

Not sure, but I can't seem to find any way around having the CSRF_TRUSTED_ORIGINS thing at moment on Seahub Instance that has already been installed, not a new install.

Any other ideas mate?

Still unable to get this to work without the trusted origins modifcation to settings py file. No idea what I am doing wrong or if something relative to that the container is running in docker on Unraid. Not sure; but would like to fix this correctly. :-(

from seafile-containerized.

At a closer look, you also have /location seafhttp in your nginx config. Are you using nginx instead of the seafile-caddy provided here? I can't really make sense of your config at the moment.

from seafile-containerized.

I've just seen your comment here haiwen/seafile#2707 (comment)

Try to replace

proxy_set_header X-Forwarded-Proto $scheme;

with

proxy_set_header X-Forwarded-Proto https;

In your nginx config it seems like it is listening to port 80. So if you are using https, there must be another reverse proxy in front of it listening to port 443, which then proxies to this nginx.

If you require further assistance, please detail your network setup, specifically in regard to which proxies are traversed when accessing your Seafile setup.

This worked; changing "proxy_set_header X-Forwarded-Proto https;" in the nginx config for Seafile.

FWIW - I have Seafile running in a container on Unraid. I have a Cloudflare Tunnel/proxy instance handling reverse proxy running on same Unraid Server pointing to Seafile outside>in.

In the future will I ever need to do this again; will the "https" change forever stick?

ALSO -- THANK YOU!! :-) Now this is configured right/safe and I feel much better. Thanks.

from seafile-containerized.

I still haven't been able to solve my main issue (I seem to have corrected the mariadb passwords where necessary, but my seafile server container is also constantly trying to "update" to version 1.x.x and throwing an error about not finding python 2.6...)

But my main issue now is that if I set up a new instance with "-p" I can't get rid of the CSRF error no matter what-- I'm thinking now that this is likely because I'm using Traefik as a reverse proxy? I don't really need to be any more, so I can get rid of that, but it is kind of nice to have if I decide to host anything else in the future...

from seafile-containerized.

I still haven't been able to solve my main issue (I seem to have corrected the mariadb passwords where necessary, but my seafile server container is also constantly trying to "update" to version 1.x.x and throwing an error about not finding python 2.6...)

How and what exactly is trying to update to version 1.x.x? The current Seafile version is 11. Can you please provide some logs?

But my main issue now is that if I set up a new instance with "-p" I can't get rid of the CSRF error no matter what-- I'm thinking now that this is likely because I'm using Traefik as a reverse proxy? I don't really need to be any more, so I can get rid of that, but it is kind of nice to have if I decide to host anything else in the future...

I've worked a couple of times with Traefik and always had problems with it. It has a ton of bugs and awful documentation. I'd recommend you use one of these reverse proxies https://github.com/ggogel/seafile-containerized/wiki/Reverse-Proxy#reverse-proxy

from seafile-containerized.

sorry for the slow responses. I don't really believe that this has anything to do with the issue with traefik (if that indeed is the issue). I kinda hate traefik too, but once I got it set up ages ago it did work well, although these days I don't have any need for a reverse proxy at the moment, so the first thing I'll do is try ditching it.
Again, this issue doesn't happen if I start a new instance using "-p" but my logs in the original instance for seafile-server are as follows:

I can't figure out where it's getting the info that my server is that low of a version.

as far as seahub it's looking like this:

and mariadb

from seafile-containerized.

It is reading the version in this method:

Connecting to the container using docker exec:

cat /shared/seafile/seafile-data/current_version
11.0.3

Probably, the file got deleted during the upgrade, and then it couldn't be recreated because the disk was full.

I would suggest you create this file and set the version to whatever you had before your instance failed.

Just be aware that more and more problems like this could start coming up due to the full disk issue. So it might be easier to start from scratch and upload your files again.

from seafile-containerized.

thanks for that-- i'll see if that gets me any further. The drive is no longer full by any means-- I've been trying to recreate the whole thing from scratch using -p and now i'm just constantly getting issues with not being able to log in with the user/pass in the docker-compose file- and this is after "system purge -a" So there are a lot of issues I'm currently up against for one reason or another. I don't need to keep the files on this system, it's designed to be a temporary client file transfer anyway, so I don't even care if I have to start from scratch, but I also have some other work to do with changing subdomain forwarding. I already removed traefik from the equation, so i'm just testing with a local ip address, but I haven't taken the time to go into the mariadb container and attempt to reset the admin password manually after the "error creating seafile admin" it's reporting in the logs.

from seafile-containerized.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from seafile-containerized.

I faced this issue today with a fresh install. Apparently, in the generated seahub_settings.py the SERVICE_URL contains a trailing slash which causes the CSRF error:

https://seafile.example.com/ vs. https://seafile.example.com

I guess this is the relevant line in the original repo:

https://github.com/haiwen/seafile-docker/blob/efff562342036212bee746aa203b152ee0bf9420/scripts/scripts_11.0/setup-seafile-mysql.py#L1048

Following the steps above, I was able to override the CSRF check, fix the config and put the check back in place. Thanks!

from seafile-containerized.