[Web] base-href is getting ignored, redirect to /dashboard

[dscso]

Hello and thanks for this great software btw. it looks very promising :). I love that it is purely client side!

I am trying to use Twake Mail in combination with Stalwart, and want it to be reachable on a subpath like so:
mail.example.com/webmail. Stalwart should be available on mail.example.com/

I serve the static files using Nginx, and I have compiled it with flutter build web --release --base-href "/webmail/" to make sure it works on the subpath.

Unfortunately, always after logging in it redirects me to mail.example.com/dashboard?type=normal, so it completely ignores the base-href "/webmail/" which is a bit annoying if you reload/bookmark, since you get a 404 then.

Do you have an Idea how to fix this issue?

I have attached my Nginx config for clarification.

server {
        listen 443 ssl;
        # I think you should also add some autodiscover.* stuff
	server_name mail.example.com;

        # ... ssl stuff

	location /webmail {
		try_files $uri $uri/ /webmail/index.html;
		root /var/www/mail.example.com;
	}
        # stalwart I want to be available at mail.example.com/
	location / {
	        proxy_pass http://192.168.1.23:8080;
                proxy_set_header X-Real-IP        $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $host;

                # WebSocket support
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
}

Kinda related:

#3167

[chibenwa]

Thanks for the great feedback!

Happy to see tmail used successfully with Stallwart.

@hoangdat any chance to get a quick hint at this? If it's a quick fix I think @dscso would be happy to test it ;-)

[dscso]

To give some more feedback:

Twake Mail works quite well. Mail sending, searching and receiving works just fine and is pretty responsive!

Regarding the rest: JAMP seems to interface quite nicely with Stalwart, but I didn't try advanced auth (only plain password).

I don't see Twake Mail using the websocket for some reason, although it is advertised by Stalwart. It might be a configuration mistake from my side, but it hinders real-time message reception.

The rest is nice, maybe some little things I've noticed:

1. Slow reaction: Clicking a folder (Inbox/Drafts/Sent) takes some time until the folder is loaded. I have checked, Stalwart takes around 50ms to respond. It feels a bit awkward, since it doesn't show a "loading..." or something like this. This makes Twake feel a bit unresponsive. I think adding a spinner could improve UX
2. UX: This is personal preference: but the arrangement of Trash, Draft, Inbox, ... is a bit weird. I think its more "logical" to start with "inbox" etc...
3. Minimalism: If no formatting is used, sending plain text mails would be cool

This are just some of my thoughts, maybe they help...

I have tried removing this line, but it doesn't fix the sub-path issue. I think you do some manual route management but I don't have any experience with Dart/Flutter.

tmail-flutter/lib/main.dart

Line 41 in aac478b

setPathUrlStrategy();

Regarding the routing: Maybe the mail.example.com/webmail/#/dashboad style routing would be simpler to implement (also on server side) mais mail.example.com/webmail/dashboard c'est plus chouette :D

Edit:
Aaah Mobile works as well...

[chibenwa]

I don't see Twake Mail using the websocket for some reason

Browser API do not allow setting the Authorization header that Stallwart needs.

We designed a custom extension for Twake Mail so that we could bypass it in our project stack: https://github.com/linagora/tmail-backend/blob/master/docs/modules/ROOT/pages/tmail-backend/jmap-extensions/ticketAuthentication.adoc

Stallwart would need to adopt it... I had similar concerns when integrating with Parula. Maybe we would need also to share this in the IETF. Cc @mdecimus ...

[chibenwa]

UX: This is personal preference: but the arrangement of Trash, Draft, Inbox, ... is a bit weird. I think its more "logical" to start with "inbox" etc...

Twake mail follows the sort order property setted up by the mail server.

Please report to stallwart.

[chibenwa]

Minimalism: If no formatting is used, sending plain text mails would be cool

I got the idea, but as soon as you reply to a mail <quote>efvev</quote> are needed. I fear use of textBody for those rare occasion would make the app more complicated.

Anyway twake mail target is a non technical audience that do not understand difference between text/plain and text/html

TL;DR I do not see us changing this.

(But thanks for sharing your thoughts!)

[chibenwa]

but I didn't try advanced auth (only plain password)

Can you please confirm Stallwart serve it's OpenID connect configuration on mail.example.com/.well-known/oidc-configuration ?

I just spoke with @hoangdat the mobile currently do ignore this location, it would be easy to fallback to it if webfinger call fails (CF https://openid.net/specs/openid-connect-discovery-1_0.html ) hence I suggested to add support for it...

[dscso]

me@host ~$ curl https://mail.example.com/.well-known/oidc-configuration
{"type":"about:blank","status":404,"title":"Not Found","detail":"The requested resource does not exist on this server."}%
me@host ~$

if that helps.

[chibenwa]

Sorry this is /.well-known/openid-configuration CF https://stalw.art/docs/auth/openid/endpoints#well-knownopenid-configuration

[dscso]

root@host:~# curl localhost:8080/.well-known/openid-configuration | jq
{
  "issuer": "https://mail.example.com",
  "authorization_endpoint": "https://mail.example.com/authorize/code",
  "token_endpoint": "https://mail.example.com/auth/token",
  "userinfo_endpoint": "https://mail.example.com/auth/userinfo",
  "jwks_uri": "https://mail.example.com/auth/jwks.json",
  "registration_endpoint": "https://mail.example.com/auth/register",
  "scopes_supported": [
    "openid",
    "offline_access"
  ],
  "response_types_supported": [
    "code",
    "id_token",
    "id_token token"
  ],
  "subject_types_supported": [
    "public"
  ],
  "grant_types_supported": [
    "authorization_code",
    "implicit",
    "urn:ietf:params:oauth:grant-type:device_code"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256",
    "RS384",
    "RS512",
    "ES256",
    "ES384",
    "PS256",
    "PS384",
    "PS512",
    "HS256",
    "HS384",
    "HS512"
  ],
  "claims_supported": [
    "sub",
    "name",
    "preferred_username",
    "email",
    "email_verified"
  ]
}
root@host:~#

[chibenwa]

Hello @dscso

Please be aware of #3529 wich might interest you.

Your feedback is appreciated as well ;-)

Regards,

Benoit