Serviceworker cannot be loaded from external URL with restrictive Firefox settings

[acourter27]

I'm using docker. When I run this:

sudo docker run -v gokapi-data:/app/data -v gokapi-config:/app/config -p 53842:53842 f0rc3/gokapi:latest

it gives me the setup & and I can walk through it. However, when it asks me to pick the storage location, Cloud isn't an option because I didn't build it with that?

I was able to run this instead to build it with the cloud part set up:

sudo docker run -d --restart always -it -v gokapi-data:/app/data -v gokapi-config:/app/config -p 53842:53842
-e GOKAPI_AWS_BUCKET={hiddenBucketName}
-e GOKAPI_AWS_REGION=us-west-2
-e GOKAPI_AWS_KEY={hiddenKey}
-e GOKAPI_AWS_KEY_SECRET={hiddenSecretKey}
f0rc3/gokapi:latest

That boots everything up and lets me upload files. The files go into my S3 bucket. But, I can't download them. I set the CORS value to:

[
{
"AllowedHeaders": [
""
],
"AllowedMethods": [
"GET",
"PUT",
"POST",
"DELETE",
"HEAD"
],
"AllowedOrigins": [
"https://{domain}",
"https://{domain}/"
],
"ExposeHeaders": []
}
]

But when I try to download, the button just turns dark grey and nothing happens.

[Forceu]

Thanks a lot for the feedback! Do you get any error messages in the console? In Chrome you can open the console with Control+Shift+C (you might need to select the tab "Console").

[acourter27]

Here's a screengrab of what I saw in console: https://share.aaroncourter.net/12ugq5Gq (https://p172.p4.n0.cdn.getcloudapp.com/items/12ugq5Gq/19d14ded-2495-4b6c-ab48-0eb52c05568b.jpg?v=62751ae823353df15eb96e3beec21119)

I'm running Firefox with many security settings locked down.

So I tried downloading the file from Safari with general settings and it downloaded fine. So hopefully most people who get the file URL would be able to download it.

The setup process was a little cumbersome though; is there a different original docker script to run that would enable the cloud storage, so that a separate script doesn't have to be run afterwards?

Note I did confirm that the files are encrypted, by downloading them manually & correcting the filename. Without encryption the file then opens. With encryption it doesn't.

[Forceu]

Thanks for the log! Are you accessing Gokapi through http or https?

[acourter27]

Https using nginx reverse proxy and lets-encrypt.

[acourter27]

Just a note for clarity; I've been using this app for a while; it worked with my Firefox settings prior to adding the encryption. It works with local encryption, no zero encryption.

[Forceu]

Might be a bug related to Firefox, something similar was noted in the original Firefox Send bug tracker as well: mozilla/send#1222

Did you set "Delete cookies and site data when Firefox is closed" in your Firefox settings? And if yes, does it work if you untick it? I will definitely investigate into this issue, and at least show a proper warning for that case.

[acourter27]

I don't have that setting on currently; I'm using containers but since the cookies stay active within the container I assumed that'd be fine. I can try loading a different Firefox profile without the containers and see if that works.

Any insights on how to get the cloud storage set up via the web config rather than with env variables?

[acourter27]

When I tested with a brand new Firefox profile it opened right up, so it's just something in the security settings.

[acourter27]

I read through the notes on that mozilla/send#1222 ticket. Then I looked at my custom cookie settings; I was blocking all 3rd party cookies. When I turned off "Enhanced Tracking Protection" in Firefox for my URL, it worked.

[acourter27]

The 3rd party tracker it's trying to load (that causes everything to fail) is https://bulling-it.de . Do you know why?

[Forceu]

Yes, that site hosts the serviceworker provided by https://github.com/jimmywarting/StreamSaver.js - I thought it would only be required to load when Gokapi is accesses through http, but it seems like it is always required.
I can rewrite the script however to have it included in gokapi if it is served through https and otherwise use the one from the external domain (I didn't really like the idea from the beginning). In the end it might be possible to write the serviceworker into the WASM module, I will look into this as well.

[acourter27]

Probably just solidifies what you already know, but I checked the config.json quick and saw that SSL was set to false. I did that during setup because I knew I was using my own & didn't care about the self-signed. I still set the URL to https.

Just in case, I went back and reconfigured with SSL set to true, and left the other settings the same, but the issue is still there.

I saw the PR for the AWS piece; excited to try that when it's ready.

Thanks for everything you do on this; it's a great tool.

[Forceu]

Should be fixed with bfaf95f - please try with the docker image latest-dev, it should work now, provided you are accessing Gokapi with SSL.

The SSL option in the configuration should only be used if you are not using a reverse proxy that provides the SSL. In that case Gokapi would generate a certificate or use the one provided.

[acourter27]

Ah okay when I do the new build I'll leave the SSL as false. I'll test the latest-dev today.

[acourter27]

I tested 1.5.1. When I left SSL false it still used the bulling-it.de and failed.

So I re-did it and set SSL to true, then tweaked my nginx config to have the proxy_pass be https instead of http. That worked.

The cloud configuration is working during setup, and the bulling-it.de 3rd party cookie is no longer being called.

If anyone else ends up diving down this path, my final docker script is:
sudo docker run -d --restart always -it -v gokapi-data:/app/data -v gokapi-config:/app/config -p 53842:53842 f0rc3/gokapi:latest

Because you're disconnected (-d), it doesn't display the message about going to the setup page, but you still can. If you're on the local machine, you can go to http://localhost:53842/setup. If you're on a different machine, you can use http://{machineIP}:53842/setup.

During setup I set the ServerURL to the URL I set up in my Reverse Proxy. The RedirectURL is {ServerURL}/login, so that it kicks you to the login page automatically.

Thanks for the quick turnaround @Forceu ; I look forward to testing any new changes you throw out there.

[Forceu]

That's weird, I tested it with SSL off and the only setting that affects it is the external URL that has been entered during the setup. Can you please check that you entered an URL with https as a prefix?

[acourter27]

You're right, I was aligning the SSL box with http in the ServerURL, when I didn't need to.

Now UseSsl is false, but my ServerUrl has https, and everything is working.

So it does seem to work regardless of the SSL flag, as long as the ServerUrl is accurate.

[Forceu]

Great to hear, thanks for the feedback! :)