Patch URL helper to assume use_appname=False if the host is a FQDN

[kszys]

So - following the discussion in #911 - here is an idea for fixing the URL helper to automagically choose the value of the use_appname parameter.

Basically, I added one condition to check if there is a valid host being passed to the app. If the host (which I get from request.urlparts[1]) is a valid FQDN (i.e., a Fully Qualified Domain Name), the assumption is that appname should not be used in constructing the URL, and hence use_appname is set to False.

There is of course the related import and updated requirements.txt.

[mdipierro]

It seems to me we already have a mechanism to not inject appname if HTTP_X_PY4WEB_APPNAME is present. So all we need to do in nginx is

server {
    listen         80;
    server_name    app1.example.com;
    add_header X-PY4WEB-APPNAME app1
    location / {
       proxy_pass http://localhost:8001/app1/;
  }
}

server {
    listen         80;
    server_name    app1.example.com;
    add_header X-PY4WEB-APPNAME app2
    location / {
       proxy_pass http://localhost:8001/app2/;
  }
}

(details depend on the nginx version)
The presence of the header X-PY4WEB-APPNAME will make it so URL will not add the URL prefix.

[kszys]

Hmm... there is a problem with this solution. I just tested, to be sure, but:

add_header directive in nginx only adds a response header - not a request header. Hence, even with this setup, py4web URL helper still adds the appname to the constructed url. Of course (and I checked) the X-PY4WEB-APPNAME = app1 is in the response headers that the browser eventually receives, but this does not help in any way for the URL helper to make a good decision about adding the appname or not 🤷

However... if one would be to use proxy_set_header directive instead, this actually works: 🎉

server {
    listen 80;
    server_name app1.example.com;
    proxy_http_version 1.1;
    proxy_set_header X-PY4WEB-APPNAME app1;
    location / {
        proxy_pass http://127.0.0.1:8000/app1$request_uri;
    }
}

[kszys]

Investigating a bit further, I seem to be running into some issues, though... Will report as soon as I get to the bottom of.

It appears as if adding this proxy_set_header X-PY4WEB-APPNAME app1; messes up something in Ombott, and request.fullpath, request.url, and request.urlparts start showing some imaginary things...

[kszys]

Right... so the problem is indeed in Ombott implementation - concretly in request_pkg/props_mixin.py. This is the function that calculates the request.fullpath:

    def fullpath(self):
        """ Request path including :attr:`script_name` (if present). """
        appname = self._env_get(self.config.app_name_header, '/')
        return urljoin(self.script_name, self.path[len(appname):].lstrip('/'))

For our example data:

path = '/app1/config/test'
appname = 'app1'

The problem is that: path[len(appname):].lstrip('/') evaluates to 1/config/test. 😔

[mdipierro]

ouch! Good find. will you be creating an Ombott ticket?

…

On Thu, Sep 5, 2024, 08:36 Krzysztof Socha ***@***.***> wrote: Right... so the problem is indeed in Ombott implementation - concretly in request_pkg/props_mixin.py. This is the function that calculates the request.fullpath: def fullpath(self): """ Request path including :attr:`script_name` (if present). """ appname = self._env_get(self.config.app_name_header, '/') return urljoin(self.script_name, self.path[len(appname):].lstrip('/')) For our example data: path = '/app1/config/test' appname = 'app1' The problem is that: path[len(appname):].lstrip('/') evaluates to 1/config/test. 😔 — Reply to this email directly, view it on GitHub <#918 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLZTY2WWJOXYWVTI6KRN3ZVB3APAVCNFSM6AAAAABNU7GJCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZSGA2DSMRRGA> . You are receiving this because you commented.Message ID: ***@***.***>

[kszys]

Yes - already have - valq7711/ombott#18

[mdipierro]

We may need to change some of the URL generations in Auth to actually use URL if not using it already.

[kszys]

So... After some more testing and discussing in valq7711/ombott#18 - it seems that actually everything is already fine 😂

• Ombott is fine
• URL helper is fine
• Form, Grid, and Auth is actually fine too.

I actually managed to get the logical/expected behaviour with current master of Ombott and py4web. The thing is that Form, Grid, and Auth only use the elements from Ombott's request which are already correct if the correct request header is passed to it. Essentially the only issue is to ensure that the correct nginx (or other proxy) configuration is present. Something like (for nginx) - notice the leading slash in X-PY4WEB-APPNAME value:

server {
    listen 80;
    server_name myapp.example.com;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-PY4WEB-APPNAME /myapp;
    location / {
        proxy_pass http://127.0.0.1:8000/myapp$request_uri;
    }
}

Sorry for bothering everybody ;)

I now believe that the only changes required are to the py4web documentation to spell it out. I can propose the text Massimo, if you agree, but let me know where this should be placed. I think something like Deployment Recepies chapter would be a good idea.

[kszys]

I created a PR #921 for the documentation. I think this is sufficient to close this PR.