UI not working as expected

[Gabgobie]

Hi. First of all, thanks a lot for this. I was looking for exactly this kind of tool and was just about to create a barely working version myself if I didn't find anything.

Now to the issue: When trying to manage the repo, there are repos hidden on the second page, however when clicking the button to get to the second page, it will display a loading circle in the bottom right corner of the browser and then do nothing. I just had to purge all of the repos I didn't need to get to the ones I want to edit at all.

I'd be happy to help with troubleshooting. I tried with both Chromium based browsers and Firefox to ensure it wasn't some browser compatibility or settings related issue.

[lbr38]

Hello

First time I heard of this issue. Could you provide a screenshot to show me exactly where it is?

Also can you open you browser console (F12) and check if there are errors displayed when clicking on the button.

Thanks

[Gabgobie]

Hi,

apologies for taking so long. Taking a look at the console solves the mystery. It's refusing cookies as they are marked as secure but I haven't taken the time to setup https.

I'll report back after I setup https but for now I'd guess that this would fix it.

-> The UI breaks when not using HTTPS

Best,
Gab

[lbr38]

My local dev environment has no https and I have no problem with cookies.

How do you access repomanager? Do you use a reverse proxy with a FQDN like described in the wiki or do you browse through the IP address?

[Gabgobie]

I directly installed it on TrueNAS Scale. I pointed a local hostname at it (repo.home.arpa.) and it's on port 9080 since TrueNAS doesn't allow anything below 9000. I tried accessing it both by using the FQDN and the IPv4. Maybe it's getting confused because an FQDN is configured but I'm not using HTTPS?

My Browser (Firefox) is configured in German so apologies if the console message is now very helpful: Das Cookie "tables/source_repos/list/offset" wurde abgelehnt, weil ein Nicht-HTTPS-Cookie nicht als "secure" gesetzt werden kann. functions.js:320:52

Translated: The Cookie "tables/source_repos/list/offset" was refused because a non-https-cookie can't be set as "secure".

I also noticed that the container logs are showing "Getting settings. . ." every 5 seconds and "Running service with parameter 'scheduled-task-exec'. . ." once per minute. I assume that is expected behavior though.

[Starbix]

I also noticed the UI not working as expected when not accessing via HTTPS. I use nginx (ingress-nginx in k8s) as a reverse proxy. I'm using Firefox.
A self-signed certificate helped:)

[lbr38]

Ok I reproduced the problem. But I will not fix it as this is not a bug. Fixing it would mean removing a security parameter which is not recommended for production use.

I it can help you, here is the nginx reverse proxy I use to access my local repomanager dev instance through http with no problem with cookies and no need of SSL certificate:

upstream repomanager_dev_docker {
    server 127.0.0.1:8080; # my repomanager container is listening on port 8080
}
 
# Disable some logging
map $request_uri $loggable {
    /ajax/controller.php 0;
    default 1;
}

server {
    listen 80;
    server_name repomanager-dev.localhost;

    client_max_body_size 64M;

    # Path to log files
    access_log /var/log/nginx/repomanager-dev_access.log combined if=$loggable;
    error_log /var/log/nginx/repomanager-dev_error.log;
 
    # Security headers
    add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
    add_header Referrer-Policy "no-referrer" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Download-Options "noopen" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Permitted-Cross-Domain-Policies "none" always;
    add_header X-Robots-Tag "none" always;
    add_header X-XSS-Protection "1; mode=block" always;

    # Remove X-Powered-By, which is an information leak
    fastcgi_hide_header X-Powered-By;
 
    location / {
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_pass http://repomanager_dev_docker;
    }
}

[Gabgobie]

I fully agree with your decision. I think this is more of a documentation thing than anything else. Thanks for your proxy configuration but I intend to use it with HTTPS anyways. I just noticed this because I wanted to get it running asap in dev to take a look around.