Support authenticated-user-header parameter in listen command

[likuan61]

Environment

• MWS version: 0.1.14 and latest (as of 2025-06-29)
• TiddlyWiki core documentation lists authenticated-user-header as a valid parameter for --listen (WebServer tiddler).

Background

Hello, I'm Kuan. I'm building a multi-user internal knowledge base where users belong to different groups and need access to different sets of content. MWS's bag and recipe model is a perfect fit for this, so I'm very grateful for the work you've done so far.

Problem

When starting MWS with:
npx mws listen --listener host=0.0.0.0 port=8080 authenticated-user-header=X-Authenticated-User
the server exits with:

✖ Unrecognized key: "authenticated-user-header"

Expected behavior

MWS should accept the authenticated-user-header parameter, as the standard TiddlyWiki Node.js server does. This would allow integration with reverse proxies that handle authentication (e.g., Nginx + Authelia). For our use case, all users authenticate through the proxy, and we need MWS to recognize the authenticated username from the X-Authenticated-User header. This would enable MWS's ACLs to function correctly and allow us to record editors.

Request

If anyone has suggestions for a workaround or an alternative approach that could work with the current version, I would be very grateful. Thank you for your time and for building MWS!

[Arlen22]

This sounds like something I can easily add. TW5 server and MWS server aren't the same thing.

You do need to be aware that this would entirely bypass the login and I would recommend setting the host to 127.0.0.1 so it's only accessible locally, otherwise anyone can set the header and bypass authentication entirely.

Are you wanting to import your user or role lists to make them easier to use with the ACLs? Or are you just planning on using one role?

There are a couple other options that are also useful, including --secure if the proxy is using SSL and --path-prefix if you want MWS to respond to a specific subpath, although I'm guessing a subdomain is more likely what you're going with.

[Arlen22]

Actually, --secure might just be for the login part of things, which the header would bypass, so not a big deal.

[likuan61]

Many thanks for your quick @Arlen22

I have constructed a TiddlyWiki for my small organization using the stack TiddlyWiki + Nginx + htpasswd. That Wiki runs on an internal network cloud Ubuntu server. My colleagues want me to separate the currently co-managed contents into different parts, where only the leader can access everything while others can access only what they need. I believe MWS with its bag and recipe model is a perfect fit for managing these contents, including standards, specifications, rules, and administrative documents.

After researching, I initially considered the stack MWS + Nginx + Authelia in Docker. However, I encountered a critical constraint: our Ubuntu server is on an internal network with no domain name, making it difficult to obtain a trusted digital certificate. While Authelia 4.38 requires HTTPS (typically with a self-signed certificate), the resulting browser warnings would create a very poor experience for our internal users, whose devices we cannot control or install software on (ruling out solutions like mkcert or Tailscale).

Therefore, I have decided to adopt the stack MWS + Nginx + htpasswd without Docker as an interim solution, and I’m looking forward to MWS’s built‑in authentication and user management maturing over time.

Security measures I will implement:

• MWS will listen only on 127.0.0.1:8080, with Nginx as the sole reverse proxy via proxy_pass http://127.0.0.1:8080.
• External direct access to port 8080 will be blocked by the host firewall.
• Nginx will handle HTTP Basic Authentication using htpasswd.

Regarding your questions about users and roles:

• I do not plan to import user lists into MWS at this stage. For the interim period, I am prepared to accept the overhead of maintaining users in both htpasswd and MWS's internal database.
• However, my long-term preference is a "trust the proxy" model where MWS accepts the username and role directly from HTTP headers (e.g., X-Authenticated-User and ideally X-Authenticated-Role) without requiring pre-registered users. This would eliminate double-maintenance once the feature is available.
• My use case requires at least three distinct roles/groups with different ACLs. For the interim, I can configure these roles inside MWS manually. But if a header-only trust mode is not feasible in the near term, I would greatly appreciate a bulk import API or script to sync users and roles from an external source, which would at least reduce the transition friction.

I understand that --secure and --path-prefix are not applicable in my case, as I will be using a subdomain without SSL and without a path prefix.

Thank you again for considering this feature request. I am happy to test any early implementation and provide feedback.

[Arlen22]

Is there a reason you aren't just going to use the MWS login system directly?

[likuan61]

Thanks for the suggestion! I'm very interested in simplifying the stack if the built-in system fits our needs.

Our setup involves three groups/roles (e.g., leaders, editors, viewers), where each group contains multiple users with their own usernames and passwords. ACLs are applied at the recipe level — each role accesses a different recipe. This is the core requirement I need to verify.

Two questions to help me decide:

1. Is the built-in login system mature enough for this? Specifically, does it support RBAC (many users per role, roles mapped to recipe ACLs), and is the security model now stable enough for a small internal team? I recall earlier warnings about security being a work in progress.

2. Given our constraints: Our server has no public domain, so trusted HTTPS certificates are impractical (self-signed certs are not viable for our users). Would you still recommend keeping Nginx as a reverse proxy over plain HTTP, or is exposing MWS directly acceptable in this scenario?

If the built-in system handles multi-user roles and the security posture is reasonable, I'd be glad to drop htpasswd and streamline the deployment.

[likuan61]

Thanks for the thoughtful response and for being willing to add the authenticated-user-header @Arlen22

After further consideration and your suggestion to use MWS's built‑in login directly, I've decided to give the native authentication system a try first. If it proves stable enough for our small internal team, we won't need the external proxy authentication path at all, which makes this feature request unnecessary for now.

I'll close this issue to avoid taking up your time. If we encounter limitations later that require header‑based auth, I'll reopen or file a new one with more context.

Thanks again for your work on MWS — the bag and recipe model is exactly what we needed!