Transparent WebPush Draft 4 Gateway

[quqkuk]

I've added a Transparent Proxy as a Gateway that relays requests transparently (as in without touching anything besides the scheme and host parts of the URL) to the host in the configuration that also takes WebPush Draft 4 "aesgcm" messages and transforms them by putting everything in the payload/body. Currently, there's no documentation, I still have to work on that, but I also want some feedback

[p1gp1g]

Wow, thank you !

@karmanyaahm

[quqkuk]

I've been running the last commit on my server for the last day using the following traefik labels:

traefik.enable: 'true'
traefik.http.routers.up-proxy.entryPoints: https
traefik.http.routers.up-proxy.rule: Host(`fqdn`) && Method(`POST`) && PathPrefix(`/{first:/?}index.php/apps/uppush/{second:/?}push/`)
traefik.http.routers.up-proxy.middlewares: up-proxy-path-normaliser
traefik.http.middlewares.up-proxy-path-normaliser.ReplacePathRegex.regex: '^//?index\.php/apps/uppush//?push/(.*)'
traefik.http.middlewares.up-proxy-path-normaliser.ReplacePathRegex.replacement: '/index.php/apps/uppush/push/$1'
traefik.http.services.up-proxy.loadbalancer.server.port: '5000'

And there's been no error to report, all Headers are proxied without being touched. If a packet comes in that has Content-Encoding: aesgcm among the Headers, then the Encryption and Crypto-Key headers are added to the body before the payload, together with the string aesgcm\r\n that acts as a file signature of sorts

[karmanyaahm]

Hi! On a technical basis, I love this PR, but there are some questions regarding whether we should do this that can be discussed. I'll post the rest of my reply over in Telegram-FOSS/Telegram-FOSS#577

[karmanyaahm]

reviewing soon btw, sorry for the delay

[karmanyaahm]

So I don't know how I forgot such a big thing...but apparently I wrote an aesgcm gateway back in May called the 'generic' gateway. I must've just merged it in as an experiment at the time.

Before I realized that existed, I was going to suggest to turn this PR into an explicit gateway (where the endpoint is passed in to the URL) as opposed to a transparent gateway. An explicit, discoverable gateway would avoid any confusion about the transparent processing which might cause aesgcm to be an implicit feature bump to the spec. Instead, it'll be a clearly separate and pluggable component with the rest of the UP architecture. It would also allow us to host a fallback public gateway, that can be configured as a backup in the app, if a gateway is not discovered on the user's push server.

I'm really sorry I should've caught this earlier before you worked on this PR so much. I would love to merge your versionHandler refactor though, and since no one uses the generic aesgcm gateway right now, I can change the format the one you suggested:

bodyFragments := []string{
            "aesgcm\r\nEncryption: ",
            req.Header.Get("Encryption"),
            "\r\nCrypto-Key: ",
            req.Header.Get("Crypto-Key"),
            "\r\n",
        }

And I'll also add a discovery endpoint to the generic gateway so it can be discovered by the Telegram clients.