[Feature]: Extend CI to provide an image for subpath deployment

[max-baz]

Problem / Motivation

I can see the recent addition of NEXT_PUBLIC_BASE_PATH, and I think it's a great idea. I can imagine it would only be more and more popular approach to use this, to deploy this project alongside Stalwart on the same domain. The requirement to build a custom image is understandable, but still adds friction.

Proposed Solution

Extend the CI to publish a container image of Bulwark with NEXT_PUBLIC_BASE_PATH=/webmail, tagged as e.g. ghcr.io/bulwarkmail/webmail:v1.7.1-subpath

People who want a custom path will still need to build their own image, but the vast majority will probably just use this image.

Alternatives Considered

No response

Feature Area

Deployment / Configuration

Mockups / Examples

No response

Additional Context

No response

[rathlinus]

I did that with my nginx config, what proxy are you using

[rathlinus]

but i could also do that

[max-baz]

I didn't realize one could avoid using this parameter, I thought without it the server would generate wrong urls, e.g. for the assets?

Is this how you are running Bulwark so, on the same domain as Stalwart, using an image without this env var, and yet just doing the routing on the nginx level? If so could you share the relevant bits? (I'll adapt to my proxy, I use traefik). Do you maintain a set of urls to forward to Stalwart, and forward everything else to Bulwark, or the opposite?

[rathlinus]

# mail.rbm.systems: Bulwark Webmail + Stalwart on same domain.
# Default route is the webmail; specific paths are carved out for Stalwart.
server {
    listen 443 ssl http2;
    server_name mail.rbm.systems;

    ssl_certificate     /etc/letsencrypt/live/rbm.systems/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/rbm.systems/privkey.pem;

    client_max_body_size 50m;

    # --- Stalwart ----------------------------------------------------------

    # JMAP API (used by the webmail's server-side proxy)
    location /jmap {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host              $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        "upgrade";
        proxy_read_timeout 600s;
    }

    # Stalwart's HTTP auth endpoint
    location /auth { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; }

    # JMAP / autoconfig / autodiscover well-knowns
    location /.well-known/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; }

    # OAuth discovery — Stalwart emits http://host:8080 URLs; rewrite to https://host
    location = /.well-known/oauth-authorization-server {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header Accept-Encoding "";
        sub_filter_once off;
        sub_filter_types application/json;
        sub_filter 'http://mail.rbm.systems:8080' 'https://$host';
    }
    location = /.well-known/openid-configuration {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header Accept-Encoding "";
        sub_filter_once off;
        sub_filter_types application/json;
        sub_filter 'http://mail.rbm.systems:8080' 'https://$host';
    }

    # /login — BOTH apps use this path. Send to Stalwart only when it looks
    # like an OAuth authorize request (?response_type=code); otherwise the
    # webmail's own login page wins.
    location = /login {
        error_page 418 = @stalwart_oauth_authorize;
        if ($arg_response_type = code) { return 418; }
        proxy_pass http://127.0.0.1:3001;  # webmail
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    location @stalwart_oauth_authorize {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
    }

    # Stalwart's OAuth login form POSTs to /api/auth (exact match only).
    # The webmail's /api/auth/<sub> routes still fall through to the catch-all.
    location = /api/auth { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; }
    location = /logo     { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; }

    # --- Bulwark Webmail (catch-all) --------------------------------------
    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Host              $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        "upgrade";
        proxy_read_timeout 600s;
    }
}

[rathlinus]

This is how i have done it. you then have your webmail on the main mail domain

[max-baz]

Nice, many many thanks, I will explore this - I like you approach, but I also like your alternative NEXT_PUBLIC_BASE_PATH approach as well, as it potentially requires less maintenance if e.g. more paths need to be sent to Stalwart in the next version.

It would also be great if the fallback value of FAVICON_URL (when it is not set) respected NEXT_PUBLIC_BASE_PATH, as well as potentially other resource urls (like LOGIN_LOGO_LIGHT_URL?)

[max-baz]

Another observation in relation to NEXT_PUBLIC_BASE_PATH (let me know if you prefer me to put these into a separate issue?):

When using SSO, lets say I go to mydomain.com/webmail/en, I can see it sets redirect_after_login session key to /webmail/en and sends me to SSO, and after login I'm sent back to mydomain.com/webmail/en/auth/callback (correct) and then I'm redirected to mydomain.com/webmail/en/webmail/en (404).

This looks like it fixes the issue, but maybe you have a cleaner way of achieving the same:

diff --git a/app/(main)/[locale]/auth/callback/page.tsx b/app/(main)/[locale]/auth/callback/page.tsx
index a084597..36d84a0 100644
--- a/app/(main)/[locale]/auth/callback/page.tsx
+++ b/app/(main)/[locale]/auth/callback/page.tsx
@@ -153,6 +153,9 @@ function OAuthCallbackInner() {
                 redirectTo = saved;
               }
             } catch { /* sessionStorage may be unavailable */ }
+            if (ssoPrefix && (redirectTo === ssoPrefix || redirectTo.startsWith(`${ssoPrefix}/`))) {
+              redirectTo = redirectTo.slice(ssoPrefix.length) || '/';
+            }
             router.push(redirectTo);
           } else {
             setError("token_exchange_failed");