Firefox Plugin - NetworkError on Sign in

[nickrallison]

When I try to connect to my instance of hoarder on a Tailscale IP and a non standard port, it works on a webpage but doesn't seem to work in a browser extension:

Web page:

Browser extension:

[MohamedBassem]

Can you try prefixing the address with http://?

[vercas]

I'm also getting a NetworkError, and my server URL looks like https://foo.bar.baz

[MohamedBassem]

Hmmm, I wonder if it has something to do with the fact that your SSL certificates are not valid (according to the first screenshot). Is it possible to try disabling SSL and trying again with the http:// prefix? Just as a test.

[vercas]

I think the problem in my case was just that I forgot to update the container before trying the extension.
It works now, and I've changed nothing else.

[MohamedBassem]

Perfect!

[vercas]

I wouldn't close this just yet. I'm not the person who opened the ticket (@nickrallison). Their issue may turn out to be different.

[MohamedBassem]

Ops, sorry.

[nickrallison]

I've updated the docker compose stack to the most recently release and changed the url to: http://100.98.101.100:23000/ and am still encountering the original issue

[MohamedBassem]

Please try removing the trailing slash from the address, this is a bug I fixed but still not released. Sorry, one last try I promise :)

If you can also capture the error logs from the browser’s console I’d be grateful!

[nickrallison]

Removing the slash didn't work and the browser console was empty for about a minute after submitting the authentication.

I printed "Here" right before submitting the log in

The logs from each container also seem empty, the only one with anything interesting was the worker log which only contained job info as far as I can tell

[MohamedBassem]

Ok, I'm out of ideas for remote debugging :D In chrome, typically, you can open the devtools tab for the "plugin" itself and inspect the network requests the plugin itself is doing.

For example, here's how I debugged the trailing slash bug:

Screen.Recording.2024-03-27.at.10.06.01.PM.mov

I'd expect that if you open the "extension"'s dev tools (not the page's dev tools), you'd find the error in the console logs and you can actually inspect the network request in the network tab. But I don't know how to do this in firefox.

I don't want to waste your time too much. If you're willing to try to repo on chrome and share the error, that would be great. Another option is to share the tailscale node with me temporarily (I can send you my tailscale email), but I'd understand if you don't want to (tbh, I personally wouldn't share my tailscale node with anyone :)). Otherwise, I'm out of ideas on how to help :)

[nickrallison]

Even more strange, Chrome works right out of the box, firefox still fails. Is it perhaps something strange with my firefox config? I have some strict rules and protections in place: https://github.com/arkenfox/user.js/

[MohamedBassem]

Oh interesting. Unfortunately, without logs from the plugin's devtool console (or its network tab), it's very hard to figure out why the plugin's requests are failing.

[nickrallison]

I think I got the relevant logs:

[MohamedBassem]

Ok, now we're talking. Are you sure you're on the latest app version? I disabled the CORS policy in v0.10.0 (e6f6873). You being on < 0.10.0 would also explain why it's working on chrome and not in firefox (chrome plugin was explicitly allowlisted. To support firefox, I dropped CORS completely).

If you're using HOARDER_VERSION=release, doing a docker compose up is not enough to ensure you're on the latest version. You'll need to also do docker compose up --pull always. Or instead, pin the version explicitly with HOARDER_VERSION=0.10.1.

[nickrallison]

No dice, I pinned it in my .env file: HOARDER_VERSION=0.10.1

but I'm still getting the same error in the console after a compose down and a compose up. Is there a way in the shell of the container to explicitly check the current version to see if it matches the env var?

[MohamedBassem]

Note to self: I should probably add some version number somewhere in the UI itself.

For now, I think one thing that changed in 0.10.0 is that in the worker logs (docker logs hoarder-workers-1), it used to say:

Starting openai worker ...

now it says:

Starting inference worker ...

If you're on >= 0.10.0, you should see the latter.

Also, can you share the output of:

curl --head https://unraid.vpn:23000/api/trpc/apiKeys.exchange

This should show the CORS headers of you server.

[dyslexicjedi]

Same issue as @nickrallison on latest version 0.10.1

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource ... CORS request did not succeed.

[MohamedBassem]

Can you share the result of:

curl --head <address>/api/trpc/apiKeys.exchange

where <address> is your full server address?

[dyslexicjedi]

One thing I did notice was that I said http://ip:port but in the inspect of the extension, I'm seeing https://ip:port. I'm not sure how the http got changed to https in the request.

[rob@turing ~]$ curl --head http://10.0.10.118:3000/api/trpc/apiKeys.exchange
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Url
Date: Fri, 29 Mar 2024 18:02:36 GMT
Connection: keep-alive
Keep-Alive: timeout=5

[rob@turing ~]$ curl -k --head https://10.0.10.118:3000/api/trpc/apiKeys.exchange
curl: (35) OpenSSL/3.2.1: error:0A0000C6:SSL routines::packet length too long

[MohamedBassem]

Access-Control-Allow-Origin: *

CORS headers look correct and confirm that you're on at least 10.0.0. The https thing is interesting. I wonder if you have a Force HTTPS everywhere kind of extension that might be causing this?

[dyslexicjedi]

Yup, on latest. No Https everywhere, just Ublock origin, privacy badger, bitwarden, you.

HOARDER_VERSION=release

rob@hoarder:~$ docker compose pull
WARN[0000] /home/rob/docker-compose.yml: `version` is obsolete 
[+] Pulling 5/5
 ✔ meilisearch Pulled                                                                                                                                         0.5s 
 ✔ web Pulled                                                                                                                                                 0.4s 
 ✔ redis Pulled                                                                                                                                               0.5s 
 ✔ chrome Pulled                                                                                                                                              0.5s 
 ✔ workers Pulled                                                                                                                                             0.4s 
rob@hoarder:~$ docker compose up -d
WARN[0000] /home/rob/docker-compose.yml: `version` is obsolete 
[+] Running 5/5
 ✔ Container rob-meilisearch-1  Started                                                                                                                       0.0s 
 ✔ Container rob-web-1          Started                                                                                                                       0.0s 
 ✔ Container rob-redis-1        Started                                                                                                                       0.0s 
 ✔ Container rob-workers-1      Started                                                                                                                       0.0s 
 ✔ Container rob-chrome-1       Started                                                                                                                       0.0s 

[MohamedBassem]

Yeah, I mean the headers you shared confirm that you're on the latest release. So the culprit is probably something else.

And your https thing is a nice observation. Do you have a force https everywhere kind of extension?

[dyslexicjedi]

I've disabled all other extensions and restarted firefox. No change still the same error and still converts from http to https. Could it be some policy inside firefox?

[MohamedBassem]

It seems that firefox indeed has such a thing:

https://support.mozilla.org/en-US/kb/https-only-prefs

EDIT: And allows you to add some exceptions which can be useful in this case.

[dyslexicjedi]

I checked the setting, but it's currently disabled.

Content-Security-Policy has an alert about upgrading insecure request. Still looking into that "feature"

Edit: Is this set in the extension or site?
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests

[dyslexicjedi]

I'm going to throw a valid cert on that machine and see if it works. That way we can figure out if that really is the problem or not.

[dyslexicjedi]

I tried it through a reverse proxy with a valid https certificate, same CORS error and dialog error message. I could put a cert directly on the box if you think that would help but I don't think it would make much difference.

rob@hoarder:~$ curl --head https://hoarder.dyslexicjedi.com/api/trpc/apiKeys.exchange
HTTP/1.1 204 No Content
Server: nginx/1.18.0 (Ubuntu)
Date: Fri, 29 Mar 2024 18:46:47 GMT
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Url

[MohamedBassem]

Is your instance by any chance publicly accessible? Would love to test on my firefox installation.

[nickrallison]

@dyslexicjedi Do you happen to use the Arkenfox presets for firefox?

[dyslexicjedi]

@MohamedBassem No sorry, it's only internal

@nickrallison No, it's Firefox packaged with Arch Linux. No real customization other than a few addons.

[nickrallison]

I got a temporary instance publicly hosted here: https://hoarder.allisontech.ca/

Strangely it doesn't have the same problem. I suspect it is something to do with my HTTPS I added.

Could I add you to my tailnet perhaps @MohamedBassem? It still has the same issue, do you have an email that works?

[dyslexicjedi]

I'm still getting CORS issues against your public instance.

[MohamedBassem]

Yeah, it sounds like some weird https issue. I expect that the plugin won't work with an invalid or self-signed cert. On the other hand, @dyslexicjedi tried with a valid cert and faced the same problem :)

Anyways, sent you an email (got yours from your github profile) with my tailscale email :)

[MohamedBassem]

@dyslexicjedi Any chance it's a different CORS issue? For example, are you by any chance adding a trailing slash to the URL? :) This causes a CORS issue but a different one. A one that I already fixed in the extension version 1.1.1 :)

I'm not getting any CORS issues in the public instance on firefox.

[dyslexicjedi]

So I was messing around with my nginx reverse proxy and CORS..... and I got it to work.

My config:

server {
  listen 0.0.0.0:443 ssl;
  server_name hoarder.dyslexicjedi.com;

  include ssl.conf;

  location / {
    if ($request_method = 'OPTIONS') {
      add_header 'Access-Control-Allow-Origin' '*';
      add_header 'Access-Control-Allow-Credentials' 'true';
      add_header 'Access-Control-Allow-Headers' 'Authorization,Accept,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Con>
      add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE,PATCH';
      add_header 'Access-Control-Max-Age' 1728000;
      add_header 'Content-Type' 'text/plain charset=UTF-8';
      add_header 'Content-Length' 0;
      return 204;
    }
    proxy_pass http://10.0.10.118:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  }
}

[MohamedBassem]

I managed to repro the issue on @nickrallison's private instance (over tailscale). Basically CORS is failing because SSL is failing with SSL_ERROR_RX_RECORD_TOO_LONG. This error means we're trying to talk SSL over an HTTP only port.

You can repro this error by opening the https://100.98.101.100:23000/signin in a tab. (Notice that https is the protocol which is talking directly to hoarder's port). So it's definitely an SSL/HTTPs issue and using a valid certificate should solve this issue.

Now, the question remains. Why tf is firefox forcing an upgrade to https :)

[MohamedBassem]

So I was messing around with my nginx reverse proxy and CORS..... and I got it to work.

@dyslexicjedi You're kinda sending the same headers that the server is already sending :D Did you try the combo of "valid cert + no trailing slash) without this hack?

[dyslexicjedi]

Yes, valid cert with no trailing slash was still failing. Only the nginx hack fixed it, but then again based on what you said previously. Firefox is communicating over a valid SSL cert to nginx and nginx is communicating over standard http to hoarder. so it's possible that nginx is solving the firefox SSL upgrade problem somehow. (not sure that made sense, but it kinda does in my head.)

[MohamedBassem]

Ok, I have a minimal repro that's irrelevant to Hoarder server.

• Start a local python server with python3 -m http.server 8000
• Get your local lan IP
• In the extension, use http://<local_lan_ip>:8000 as the server address
• Use any username and password.
• You'll get the same CORS error we've been debugging, and the python server will receive some SSL garbage.

Notice, that if you use localhost or 127.0.0.1, firefox won't upgrade the request to https.

It seems that firefox addons upgrades ANY http request to https regardless of the website. I don't know why this is happening to be honest. The next suspect would be maybe something in the plugin code itself? I'll check.

[nickrallison]

I got it working, it was not the fix i would like but I forwarded my domain to a second local Nginx instance on a VM so not publicly. After adding https it works like it's meant to. Thanks for all the support, I'm content with a band-aid fix for now

[nickrallison]

Perhaps another band aid would be a disclaimer to firefox users and the advice to host it publicly and disable sign ups once issue #52 gets resolved

[MohamedBassem]

You don't actually need to host it publicly. You just need to have a valid certificate. You can get valid certs for non public domains with DNS challenge in Lets Encrypt. Most of my homelab is non-public (only via tailscale) and has valid certs.

EDIT: #52 is a misunderstanding :) DISABLE_SIGNUPS works.
EDIT 2: I think the disclaimer would be: "If you're planning to use the firefox extension, your service needs to be served over https and have valid certs".

[alejoar]

I'm facing this same issue (confirmed looking at the extension console logs) and hosting through cosmos with a custom domain. The site is publicly accessible with https.

Any tips on how to fix it with this setup?

[MohamedBassem]

@alejoar if you're using cosmos, you might want to check the custom CORS header configuration. Check #51 for details on how we debug a previous instance with cosmos.

[alejoar]

@MohamedBassem amazing, that worked, thank you!

[lucius346346]

Is there any plan for fixing this? Setting up SSL for just that would be a hassle?

[MohamedBassem]

@lucius346346 to be honest, I'm not entirely sure if this something that can be "fixed" or if it's a firefox restriction that can't be bypassed. So far, I didn't find any reference online stating this requirement and I'm not entirely sure what needs to be fixed.

[axsddlr]

having same issue on both chrome, edge, waterfox and firefox. ios app works fine

[kamtschatka]

So I found the solution here: https://discourse.mozilla.org/t/mv3-default-csp-override-upgrade-insecure-requests/110443
There is a default Content Security Policy applied in Firefox: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/content_security_policy
I have created a PR: #178

I tried it out locally and could confirm that it works (using the published extension and modifying it)

I also tried the local build but that did not work, as the build seems to output invalid manifest versions for Firefox. @MohamedBassem maybe we can talk in Discord to get this fixed? the dev build does not seem to work and the "build" target seems to not include the js file in the index.html?

[MohamedBassem]

@kamtschatka this is a great find! I didn't know that firefox adds upgrade-insecure-requests to CSP, and it's not even documented in their docs!

Regarding the local build, pnpm run dev doesn't seem to work with firefox, but pnpm run build does work. You need to follow this link to install the extenion.

[MohamedBassem]

I've just released v1.2.1 to the mozilla store with @kamtschatka. If anyone was facing this problem, please give it a shot and let us know how it goes.
Once again, thanks a ton @kamtschatka for tracking and fixing this long standing problem!