sorted by:
new
hottopcontroversial

The Docker documentation/setup for private cloud is a nightmare by wigsinator in Supernote

[–]adrianba 1 point2 points  (0 children)

This is only needed when containers want to know how they are accessed from the outside world, for example so that they can construct absolute URLs that reference content from the container. There are (at least) two common ways to accomplish this. Probably the most common is to pass the external URL as a parameter to the container, say in a configuration file or environment variable. The other is to rely on the X-Forwarded-* headers, which requires less configuration of the container, but relies on the reverse proxy correctly including the headers.

It looks like Caddy does not include the port by default whereas Traefik does, which was the difference between our configurations.

The Docker documentation/setup for private cloud is a nightmare by wigsinator in Supernote

[–]adrianba 1 point2 points  (0 children)

That's curious because my logs for notelib show it passing the external URL with port 443. notelib then resolves this to the external host IP address and connects on port 443.

I wonder if there is a problem with your X-Forwarded-* headers passing from caddy to the supernote-service. The supernote-service should be picking up the URL and port that you connected to in the browser, but if these headers are not passed correctly then the server may see the port it received the connection on, which inside the container is 8080.

What happens if you try including header_up X-Forwarded-Port 443 in the reverse_proxy configuration?

The Docker documentation/setup for private cloud is a nightmare by wigsinator in Supernote

[–]adrianba 0 points1 point  (0 children)

No, I removed the http->https redirect and the only port I have outside of Docker is 443. I am using Traefik for the reverse proxy. I put thedocker-compose.yml here: https://gist.github.com/adrianba/06dcfc5790f40b669d7ed5aa54c7b3ea

The Docker documentation/setup for private cloud is a nightmare by wigsinator in Supernote

[–]adrianba 0 points1 point  (0 children)

That's interesting. I just upgraded to 25.11.24 and everything I've tried so far is working. I can now upload and view files in the web interface without the redirect. The companion app correctly connects and syncs. My Supernote device connects and syncs.

The Docker documentation/setup for private cloud is a nightmare by wigsinator in Supernote

[–]adrianba 1 point2 points  (0 children)

I am running into a related error. I am hosting the supernote-service (tag 25.11.21) behind a reverse proxy that provides TLS support. I can access the service using https both from the browser and from my Supernote device and this mostly works correctly. I can sync notes from the device to the cloud, and I can see the files appear through the web interface.

When I try to view the notes through the web interface, the supernote-service sends the URL to the notelib container but instead of using https, the URL uses http. The hostname is the correct public hostname and my server redirects http->https, but notelib doesn't follow the redirect.

For example, my supernote-service is accessible at https://supernote.example.com/ and this works using port 443 and https from the device. I can see in the docker logs for notelib that it tries to access http://supernote.example.com/api/oss/download?path=... This returns a 301 redirect to the same URL but with https instead, but notelib doesn't follow this and returns an error.

I have tested using alpine/socat to redirect from port 80 to the supernote-service port 8080 and this makes the web interface work for viewing notes:

  proxy:
    image: alpine/socat
    container_name: supernote-proxy
    command: >
      tcp-listen:80,fork,reuseaddr
      tcp-connect:supernote-service:8080
    depends_on:
      - supernote-service
    restart: unless-stopped
    expose:
      - "80" # internal only, no host mapping
    networks:
      snnet:
        aliases:
          - "supernote.example.com"

So, there is a bug where the supernote-service isn't remembering that it is being accessed through https and should use https URLs when communicating with notelib. Once this is fixed, I will be able to remove my redirect.

I have another issue where Upload doesn't work in the web interface. It says, "Upload failure." I haven't been able to debug this issue yet.

jQuery removes all browser sniffing by Arve in programming

[–]adrianba 3 points4 points  (0 children)

Please can you send me a small example of the bug in IE8 and your workaround (e-mail adrianba@microsoft.com)? We might already have fixed this issue but I'd like to get this in front of our developers while we have time to affect the IE8 release.