Role of the authenticated-user-header parameters behind a reverse proxy

Hi,

I’m building an authentication service using nginx in front of my wiki.
I’m not clear on how to use the authenticated-user-header parameter of tiddlywiki
Reading carefully https://tiddlywiki.com/languages/fr-FR/static/WebServer%20Parameter%3A%20authenticated-user-header.html

For example, if the authenticated-user-header is set to X-Authenticated-User, then the HTTP request must include a header field X-Authenticated-User with a value that is the username:
* X-Authenticated-User: JeremyRuston *

Does it means that

  • I must start tiddlywiki with username=JeremyRuston such as tiddlywiki check if both value match (and then reroute to an un-authenticated tiddler …’ OR
  • the JeremyRuston value could be whatever we want, meaning the tiddltwiki trust the frontend nginx to authenticate the user …?

Thanks for your help guys !

Regards

Vpl

Hi @vpl good to see you back.

The purpose of the authenticated username header is to allow middleware to pass an explicit username to TiddlyWiki. It would be used when there is some kind of proxy in front of TiddlyWiki that is handling authentication.

Your first suggestion is correct: TiddlyWiki trusts the username to be correct, but in order to actually authenticate a request it still needs to match the username to the access control list. The simplest way to do this is indeed to use the username=JeremyRuston option, but in practice presumably you’d want to keep a list of usernames in a CSV file.

1 Like

Hi Jeremy !
Thanks a lot for your answer.
I’ve conducted additional test that I would like to submit to your attention
My intend, with these tests, is to deploy a authentication server in front of my lovely tw5
Once I have authenticated the user, I want to use nginx (see below my config) to update the X-Authenticated-User header
The idea is to forbit the access to the user if the AuthN server decides it (inactivity of the browser for a
certain amount of time for example like on the banking systems).
The test I’ve done

  • tw5 server start command:

node_modules/tiddlywiki/tiddlywiki.js wikis/mynewwiki --listen host=0.0.0.0 port=9090 username=joe authenticated-user-header=X-Authenticated-User

  • nginx (see attached) but mainly
    • js_set $authenticated_user main.getAuthenticatedUser; for updating a variable on each request
      • proxy_set_header X-Authenticated-User $authenticated_user; for setting the value

I’ve captured the traces (wireshark traces cannot be attached I put a screenshot

nginx is listening on 80
tw5 backend listeing on 9090

What I noticed

  • (frame 717) The request is sent from my browser
  • (frame 722) The X-Authenticated-User is set to ‘jack’. As my username=joe I expect a 404
  • (frame 726 729) Here I get a 200 OK where I should get a 404 … no ?
  • (frame 745-754) I have a new request starting from the browser, going through the nginx, reaching tw5 with jack as X-Authenticated-User
    Looks nice
  • (frame 782-792) Here another session with a PUT /tw5_vpl/… with the same path & ‘jack’ header.
    This time I get a 204 … why not a 404
  • (frame 871-904) Again a 200 OK where we should get a 404 …?

So I don’t understand why I do not get a 404 all the time ?
I do not understand why, when I get a 404 (frame 745-754) this does not stop the session definitely ?

From a user perspective, it is as if nothing was going wrong when I use the tw5. I can search for, add, delete tiddler…

=====================================================
nginx.conf

load_module modules/ngx_http_js_module.so;

events {}

http {
# Set the path to our njs JavaScript files
js_path “/etc/nginx/njs/”;

# Import our JavaScript file into the variable "main"
js_import main from tw5.js;

log_format custom_format '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_backend"';
                      
access_log /var/log/nginx/access.log custom_format;
error_log /var/log/nginx/error.log debug;

server {
  js_var $log_level "DEBUG";
  listen 80;
    js_set $authenticated_user main.getAuthenticatedUser;

    # Main access to /tw5_vpl/ 
    location /tw5_vpl/ {        
        proxy_pass http://127.0.0.1:9090/;
        proxy_set_header Host $host;  # Forward the original Host header
        proxy_set_header X-Original-URI $request_uri;  # Forward the original request URI
        proxy_set_header X-Real-IP $remote_addr;  # Forward the real client IP
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # Forward the X-Forwarded-For header
        proxy_set_header X-Forwarded-Proto $scheme;  # Forward the original scheme (http/https)
        proxy_set_header X-Authenticated-User $authenticated_user;
        proxy_intercept_errors on;
    }
}

}

Could you please provide me some guidance on how to stop the session ?

Thanks very much for your help

Juste trying to get the attention of the experts around the table …
Any idea that could help me ?

Regards

Vpl

@vpl can you simplify the question rather than forcing a lot of reading and detail?, we always need to be aware of how much effort we ask of people and if we ask too much in one go people may find it hard to justify the time to answer your question.

Even if you divide the problem into more but smaller questions and seperate essential reading from “evidence” or “source code” that the reader can deside if they need to read it or not.