~tsileo/microblog.pub#50: 
Question about running app on path

Hello agai! I've been following the project and I noticed that thanks to this patch the app is able to be run on a non-root path! I would love to run this on a domainname.tld/twt/ path and so when I was poking around in the config.py, and I saw this

+# When running the app on a path, the ID maybe set by the config, but in this
+# case, a valid webfinger must be served on the root domain

How should I go about running a webfinger on the root domain? I googled around a bit, but I wasn't able to make heads or tails of where to start. Any help is appreciated!

Status
REPORTED
Submitter
~wychwitch
Assigned to
No-one
Submitted
a month ago
Updated
a month ago
Labels
No labels applied.

~doof a month ago

Take the JSON from:

https://domainname.tld/twt/.well-known/webfinger?resource=acct:username@domainname.tld

and arrange for it to be served from both of:

https://domainname.tld/.well-known/webfinger?resource=acct:username@domainname.tld
https://domainname.tld/.well-known/webfinger?resource=https://domainname.tld/twt

If you only have a single user on the domain, you can simply proxy the top-level /.well-known/webfinger resource to the same backend as /twt/, or even serve it statically. If you have multiple users, you'll need to act on the resource parameter and do something different for each user.

~wychwitch a month ago

Thank you so much!! This is exactly what I needed!

I might try my hand at updating the documentation later for anyone else (after all it sounds like this would be a solution for the folks in #33), assuming I remember to get around to it of course!

~wychwitch a month ago

WELL okay I have another issue when running this on the subdirectory, I can make another thread if needed!

Right now I have my nginx set up like the following:

server {
        root /home/user/www/;
        index index.php index.html index.htm;
        server_name do.main.tld;

        client_max_body_size 4G;


        location / {
                if ($request_uri ~ ^/(.*)\.html) {
                        return 302 /$1;
                }

                try_files $uri $uri.html $uri/ =404;

        }

        location /twt/ {
                proxy_set_header Host $http_host;
                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 $connection_upgrade;
                proxy_redirect off;
                proxy_buffering off;
                proxy_pass http://localhost:7000/;
        }

        location /.well-known/webfinger {
                proxy_set_header Host $http_host;
                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 $connection_upgrade;
                proxy_redirect off;
                proxy_buffering off;
                proxy_pass https://do.main.tld/twt/.well-known/webfinger;
        }

and I can access the main page when going to /twt/, unfortunately it has no css styles, and any sub-pages are a 404

I'm assuming I'm not proxy-passing correctly, is there something I'm missing? Thanks so much for all your help!!! I haven't done something like this in nginx before so I'm a little lost (usually my dockers are all on subdomains, not subdirectories!)

Alexey Shpakovsky a month ago · edit

I have a similar nginx config, and it works fine...

Some debugging thoughts below:

First, did you restart nginx after last config change? :)

Second, check that http://localhost:7000/static/css/main.css opens from inside the machine (you can use curl when logged into it) and check uvicorn.log file (inside microblog.pub/data dir) to confirm that nginx indeed forwards https://do.main.tld/twt/static/css/main.css requests to this URL.

Third, opening https://do.main.tld/twt/static/css/main.css directly in the browser might help with understanding what's going wrong.

And you also have a map $http_upgrade $connection_upgrade block somewhere in the nginx config, right?

It's the slash "/" symbol at the end of proxy_pass directive (after port number) which is important to make this work.

~wychwitch a month ago

First, did you restart nginx after last config change? :)

Yep!! Trust me I've done that enough times that I reset nginx compulsively now lmao

Second, check that http://localhost:7000/static/css/main.css opens from inside the machine (you can use curl when logged into it)

Yeah that printed the css file!

check uvicorn.log file (inside microblog.pub/data dir) to confirm that nginx indeed forwards https://do.main.tld/twt/static/css/main.css requests to this URL

I can see the connections, and it looks good!

INFO:     <IP_ADDRESS> - "GET /css/main.css HTTP/1.1" 200 OK
2022-11-06 20:08:23.357 | INFO     | app.main:__call__:169 | 9800c9402e0a2b90 - status_code=200 elapsed_time=0.01s

Third, opening https://do.main.tld/twt/static/css/main.css directly in the browser might help with understanding what's going wrong.

Yeah going to the url displays it in my browser! Weird!!

And you also have a map $http_upgrade $connection_upgrade block somewhere in the nginx config, right?

I didn't actually!! I added the following above the server block, but I don't notice any difference

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

:? I'm feeling stumped, I feel like it's something really small hahahaha

Alexey Shpakovsky a month ago · edit

hmm, if https://do.main.tld/twt/static/css/main.css works, then it's probably not an nginx problem.

But then... are you running latest version? :)

Look at HTML code of https://do.main.tld/twt/ (Ctrl+U in a browser or use curl), on line 7 it should say:

<link rel="stylesheet"
href="https://do.main.tld/twt/static/css/main.css?v={random}">

where {random} is a random string of letters and numbers, something like bf8f6c43990163ac1713297fb09be5ab

Also, in the microblog.pub source code, line 7 of app/templates/layout.html file should be:

<link rel="stylesheet" href="{{ BASE_URL }}/static/css/main.css?v={{
CSS_HASH }}">

If the HTML code doesn't mention you domain on line 7, and layout.html doesn't have BASE_URL on line 7 - then you're definitely running an older version of microblog.pub! This line was changed here:

https://git.sr.ht/~tsileo/microblog.pub/commit/1c076049cf38d77cfeb028e07665899a4b618648#app/templates/layout.html

~wychwitch a month ago

If the HTML code doesn't mention you domain on line 7, and layout.html doesn't have BASE_URL on line 7 - then you're definitely running an older version of microblog.pub! This line was changed here:

Oh my god it DIDN'T have the /twt/!! It was just domain.tld/static/css/...

Unfortunately after running build and relaunching, it still has do.main.tld/static/css/ not do.main.tld/twt/static/css/...

I checked and it does have the BASE_URL on line 7, am I missing something in my config? I could add /twt/ to the layout's html but I feel like that is more of a brute force fix...

~wychwitch a month ago*

Okay after looking into the code, i found this section in config.py

CONFIG = load_config()
DOMAIN = CONFIG.domain
_SCHEME = "https" if CONFIG.https else "http"
ID = f"{_SCHEME}://{DOMAIN}"
if CONFIG.id:
    ID = CONFIG.id
USERNAME = CONFIG.username

# removed extra lines...

BASE_URL = ID

Looking at this, it looks like if I set the ID to do.main.tld/twt/ it would set the base url here, but that seems wrong, wouldn't/shouldn't the config be called base_url instead? Also, wouldn't that make the full user address become @user@do.main.tld/twt/ since it's overwriting the f"{_SCHEME}://{DOMAIN}"??

right now my config is as follows:

domain = "do.main.tld"
username = "wych"
admin_password = "keyhash"
name = "wych(witch)"
summary = "My crows to the sunset :)"
https = true
icon_url = "https://do.main.tld/twt/static/nopic.png"
secret = "secret"
trusted_hosts = ["*"]

~doof a month ago

Try setting:

id = "https://do.main.tld/twt"

in config, and adding:

--root-path=/twt

to the Uvicorn command line in misc/supervisord.conf (or the docker/ynh equivalent if using that).

~wychwitch a month ago*

Setting both of those brought the css back!!!! However, there are still some issues where the base url isn't set correctly.

It looks like some things to do with admin pages are linked on the site as do.main.tld/admin/* as opposed to do.main.tld/twt/admin/*. This includes both the admin login link at the bottom of the page (.tld/admin/login) and when trying to make a new post (.tld/admin/actions/new)

However all other links seem to work, from /admin/stream and even changing the url manually to .tld/twt/admin/login brought me to the right login page, though posting doesn't work at all. Maybe this is an oversight with the new update??

Edit: Deleting is another 404 with a missing /twt/ uri, and hitting manage followers too!

~doof a month ago

So, the app has 2 ways of generating URLs:

  1. Using BASE_URL. CSS URLs use this. As you noted earlier, it's set from ID in config.py.

  2. Using url_for(...). The admin login link uses this. It's implemented by FastAPI. When I was testing, I had to set both the Host/X-Forwarded-Proto HTTP headers and the --root-path Uvicorn flag for these to be generated correctly.

It sounds like (1) is now working for you, and (2) is partially working except for the path. My suspicion is still with the Uvicorn flag. Are you sure it's being set? Does it show up in the running Uvicorn process' command line in ps xww?

I didn't fully chase down the codepath involved in (2), so it's possible there are other factors at play.

~wychwitch a month ago

I ran ps xww and got this result:

3611073 pts/0    T      0:00 nano misc/supervisord.conf
3612865 ?        Ss     0:03 /opt/venv/.venv/bin/python /opt/venv/.venv/bin/supervisord -n -c misc/docker-supervisord.conf
3612956 ?        Sl     0:20 /opt/venv/.venv/bin/python /opt/venv/.venv/bin/inv process-incoming-activities
3612957 ?        Sl     0:20 /opt/venv/.venv/bin/python /opt/venv/.venv/bin/inv process-outgoing-activities
3612958 ?        Sl     0:20 /opt/venv/.venv/bin/python /opt/venv/.venv/bin/uvicorn app.main:app --no-server-header --host 0.0.0.0

Which is weird, because I checked the supervisord.conf and it still has the --root-path=/twt argument as follows:

ommand=%(ENV_VENV_DIR)s/bin/uvicorn app.main:app --no-server-header --root-path=/twt
numprocs=1
autorestart=true
redirect_stderr=true
stdout_logfile=uvicorn.log
stdout_logfile_maxbytes=50MB

I also have the headers set, I showed them above but here's just the /twt/ block:

location  /twt/ {
                proxy_set_header Host $http_host;
                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 $connection_upgrade;
                proxy_redirect off;
                proxy_buffering off;
                proxy_pass http://127.0.0.1:7000/;
        }

?? I made sure to run make build and restart the docker-compose, I'm not sure why it doesn't seem to work :?

~doof a month ago

It looks like your environment is using docker-supervisord.conf instead of supervisord.conf. Try adding it there? :)

~wychwitch a month ago

/places face into hands

I saw you mention that before but it still didn't click!! That did it!!! I had to bring it down completely first b y using docker-compose down as opposed to just restart, but once it came back up all the links work now!! Thank you so much!!

I'm at @wych@wychwit.ch if you (or anyone else) would like to see if my webfinger is configured correctly lmao

Again, thank you so much!! I never would've figured that out alone hahaha

Now I just need to change the colors to fit my aesthetic more ^^ but that's a project for another day

Register here or Log in to comment, or comment via email.