aerusso
commented
3 years ago I also ran into this problem. I worked around it by just curl-ing the CalDAV and CardDAV commands.
Open grunlab opened 4 years ago
aerusso
commented
3 years ago I also ran into this problem. I worked around it by just curl-ing the CalDAV and CardDAV commands.
jtorrex
commented
3 years ago Same case here as detailed by @grunlab.
timakro
commented
3 years ago Seems like you can log in with any username and password. And even though it says "logged in as xyz", the effective user is always the one from X-Remote-User. No security issue here but confusing UX.
chris2fr
commented
2 years ago Yes, confusing GUI.
gardiol
commented
10 months ago Agreed, some thing happens here. User seems logged, but web ui requires another login (useless). Works tough. Just confusing and ugly.
57194
commented
4 months ago I'm not sure exactly where all in the code it would need to be updated, but basically anywhere in the code the login page would be called, I think there just needs to be a check of the config file and just send the user in if they have the config option set and the right header. Would probably need another "passwordless" code path added, since most of the login code looks like it all requires a (username, password) tuple.
pbiering
commented
3 months ago Hi all, I need more details to understand what happens when and what is unexpected? Would be good if one can provide related request+response headers.
pbiering
commented
3 months ago I ran some analysis and assume the issue is related to WebUI only which still after passing Basic Auth on a reverse proxy, which protects e.g. complete /radicale/* is displaying the login screen and also requires credentials to work.
This is somehow by nature as the WebUI is client-only Javascript implementation and requires the credentials to run the C*DAV-requests.
@MatthewHana : is there any chance that the WebUI is able to take advantage of already provided BasicAuth of the initial request, so to say "borrow" for it's own requests generated in Javascript the BasicAuth from the browser session?
Final goal would be bypassing the login screen if surrounding BasicAuth is already provided and tested by Javascript successfully in case of "forbidden" fallback to login screen.
A workaround would be excluding the .web from BasicAuth, but I haven't tested whether this is supported by web servers to exclude a sub-path from BasicAuth while the main path is protected. If not supported, one can test internal redirects and expose the WebUI on a different main path outside BasicAuth - but here potentially some base URI must be adjusted.
gardiol
commented
3 months ago Could this info be of any use? https://www.authelia.com/integration/proxies/support/#standard
ALso check the NGINX configiration files for authelia here https://www.authelia.com/integration/proxies/nginx/#authelia-authrequestconf and here https://www.authelia.com/integration/proxies/nginx/#authelia-location-basicconf
It already just works with proxy auth, i guess it's only matter of checking the right headers?
selenith
commented
2 months ago Hi, I made a quick and dirty hack that gets the username from the server environment variables and submits the form when the page is opened on my server.
If it helps, here's how I did it.
I've created a php page in the same vhost that returns the user name present in the variable $_SERVER['REMOTE_USER'] in json like this: {“user”:“
My php code :
//file userinfos.php
<?php
$user_data = ['user'=>'not_connected'];
if(!empty($_SERVER["REMOTE_USER"])){
$user_data['user'] =$_SERVER["REMOTE_USER"];
}
echo(json_encode($user_data));
?>I modified the fn.js file in two places:
function LoginScene() {
/* ..... */
this.on_login_ext = function(){
onlogin();
}
/* ..... */
}I've modified the main function like this :
function main() {
// Hide startup loading message
document.getElementById("loadingscene").classList.add("hidden");
let log_screen = new LoginScene();
push_scene(log_screen, false);
// callback executed once the file giving the user name has been requested.
function get_username_and_connect() {
let username = this.response.user;
let html_scene = document.getElementById("loginscene");
let form = html_scene.querySelector("[data-name=form]");
let user_form = html_scene.querySelector("[data-name=user]");
// fill the form and submit
user_form.value = username;
log_screen.on_login_ext();
}
const req = new XMLHttpRequest();
req.responseType = 'json';
req.addEventListener("load", get_username_and_connect);
req.open("GET", "/userinfos.php");
req.send();}
With a little tweaking of the nginx config, I also got it to work with p12 certificates for authentication via HTTPS without password. If anyone is interested I can detail the configuration.
Use case:
I'm trying to configure radicale this way:
Radicale is running into a docker container deployed on top of a kubernetes cluster. Traefik is used as edge router to access the apps running into the cluster.
Radicale config:
Authentication type set to
http_x_remote_userin order to:X-Remote-Userheader set by TreafikTraefik config:
radicale-basic-authconfigured to manage login/password at Traefik level + forward authenticated user name to radicale withX-Remote-Userheader:radicale-basic-authmiddleware activated:Expected result:
adrienhas been correctly forwarded by traefik to the app --> OKadrienfolder exist --> OKDid i missed something into the configuration or is there a bug somewhere !?
Thank you for your support