Feat: decode url-encoded user name in authenticate request header to allow CJK username in header (#7471)

* fix: CJK in header has to be urlEncoded

* refactor: use $tw.utils.decodeURIComponentSafe

* docs: about chagne in this field

* docs: update

* docs: use less "field"
This commit is contained in:
lin onetwo 2023-05-22 19:25:51 +08:00 committed by GitHub
parent 9b78e871aa
commit 3f763775d6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 17 additions and 5 deletions

View File

@ -18,7 +18,7 @@ All parameters are optional with safe defaults, and can be specified in any orde
* ''anon-username'' - the username for signing edits for anonymous users
* ''username'' - optional username for basic authentication
* ''password'' - optional password for basic authentication
* ''authenticated-user-header'' - optional name of header to be used for trusted authentication
* ''authenticated-user-header'' - optional name of request header to be used for trusted authentication.
* ''readers'' - comma-separated list of principals allowed to read from this wiki
* ''writers'' - comma-separated list of principals allowed to write to this wiki
* ''csrf-disable'' - set to "yes" to disable CSRF checks (defaults to "no")

View File

@ -37,7 +37,7 @@ HeaderAuthenticator.prototype.authenticateRequest = function(request,response,st
return false;
} else {
// authenticatedUsername will be undefined for anonymous users
state.authenticatedUsername = username;
state.authenticatedUsername = $tw.utils.decodeURIComponentSafe(username);
return true;
}
};

View File

@ -4,6 +4,10 @@ tags: [[WebServer Authentication]]
title: WebServer Header Authentication
type: text/vnd.tiddlywiki
Header authentication is a web integration technique enabling external entities to securely pass details of the authenticated user to an application. It is commonly used for "single sign on" in corporate environments.
Header authentication is a web integration technique enabling external entities to securely pass details of the authenticated user to an application.
Header authentication is activated if is configured via the [[authenticated-user-header|WebServer Parameter: authenticated-user-header]]
!! Usage in SSO
Header authentication is commonly used for "single sign on" in corporate environments. When doing header authentication, the user is not prompted for a username and password on TiddlyWiki. Instead, the user is required to login at a SSO proxy server. When the user authenticates themselves to the SSO proxy server, the proxy server redirects the user request to the TiddlyWiki server with this additional request header containing the username. Then TiddlyWiki server is able to use the value of this request header to identify the user.

View File

@ -1,8 +1,16 @@
caption: authenticated-user-header
created: 20180630180213047
modified: 20180702140416583
modified: 20230522184416583
tags: [[WebServer Parameters]]
title: WebServer Parameter: authenticated-user-header
type: text/vnd.tiddlywiki
The [[web server configuration parameter|WebServer Parameters]] ''authenticated-user-header'' activates [[header authentication|WebServer Header Authentication]] by specifying the name of the HTTP header that will be used to pass the username to TiddlyWiki.
The [[web server configuration parameter|WebServer Parameters]] ''authenticated-user-header'' activates [[header authentication|WebServer Header Authentication]] by specifying the name of the HTTP header field that will be used to pass the username to TiddlyWiki.
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:
```http
X-Authenticated-User: JeremyRuston
```
<<.from-version "5.3.0">> Value of this header field should be URI-encoded before transit on the client (using `encodeURIComponent` JS function or [[encodeuricomponent Operator]]), and will be URI-decoded by the server.