user change under webserver authentication not recognized, posted by Frank Heyroth on Fri Jan 19 15:49:13 2024
|
Hi all,
I am using the Apache webserver authentication and redirection over http (not https). I have configured it 1:1 as described in the Adminguide. In the elog.cfg I set Authentication = Webserver .
All works fine; the webserver requests an authentication and elog recognizes me correctly.
However, when I close and reopen the browser and log in as a different user, elog does not change the user (tested with Firefox and Edge).
I can only change the user if I use a different browser or restart the elogd (reload is not enough).
The X-Forwarded-User header is set to the correct username - I have checked it with a CustomLog in Apache.
Best regards,
Frank |
Re: How to not expose elog port when running under a reverse proxy, posted by Frank Heyroth on Mon Jan 22 20:50:50 2024
|
Hi,
as I understand right you can do this in the elogd.cfg via
Interface = 127.0.0.1
port = 8080
however than this can be changed by any user how has global admin rights in elog.
So I changed the line in the elogd.service startscript
ExecStart=/usr/local/sbin/elogd -D -p 8080 -n 127.0.0.1 -c /usr/local/elog/elogd.cfg
I hope this has the priority (not tested).
Nicola wrote: |
I am running elog under Apache as explained in the administrator's guide. Everything works fine, butmy IT service complains about the elog port being publicly exposed, so I have to fix this. As far as I understand when running under a reverse proxy there's no need for the port to be publiuclyexposed, but I cannot find how to configure the elog server to expose it only locally
|
|
Re: user change under webserver authentication not recognized, posted by Frank Heyroth on Wed Jan 24 14:50:21 2024
|
I found the reason of the bug:
In line 27441 of elogd.cxx the http_user is overwritten by the user saved in the sid_ array as a sideeffect of the sid_check function:
sid_check(getparam("sid"), http_user)
It can solved by changing elogd.cxx @ line 27441
27441c27441,27446
< if (!sid_check(getparam("sid"), http_user)) { /* if we don't have a sid yet, set it */
---
> i=sid_check(getparam("sid"), thumb_name);
> if (i && strcmp(http_user,thumb_name)!=0) { /* user changed */
> sid_remove(getparam("sid"));
> i=FALSE;
> }
> if (!i) { /* if we don't have a sid yet, set it */
Remark: I have used the variables i & thumb_name of the function in a local context. |
Re: el cheapo LDAP binding, posted by Christian Herzog on Fri Feb 3 09:30:20 2012
|
Hi Christof,
wow thanks, that's (almost) exactly what I was looking for! I only had to add
--- src/elogd.c.orig 2012-02-03 09:11:42.000000000 +0100
+++ src/elogd.c 2012-02-03 09:11:32.000000000 +0100
@@ -8375,6 +8375,10 @@
strcpy(list[i], "remote_host");
strlcpy(value[i++], rem_host, NAME_LENGTH);
+ /* add LDAP author */
+ strcpy(list[i], "http_user");
+ strlcpy(value[i++], http_user, NAME_LENGTH);
+
/* add local host */
strcpy(list[i], "host");
strlcpy(value[i++], host_name, NAME_LENGTH);
in order to get
Preset Author = $http_user
to work. I fully support getting your patches into upstream.
thanks a bunch,
-Christian
|
Re: Too many redirects when running behind load balancer?, posted by Tamas Gal on Fri Jan 20 14:08:25 2023
|
The issue is still present and now it's quite urgent to move this last service into the Swarm. Does anyone maybe have an idea what's wrong? To sum up: if there is a non-empty password file, the login page chokes in an infinite loop of redirects. I am using the same HAProxy load balancer configuration as for all the other services (running Apache, NGINX, GitLab, XWiki, etc.):
backend be_elog.km3net.de
mode http
option forwardfor except 127.0.0.1
http-request add-header X-Forwarded-Proto https if { ssl_fc }
server-template km3net-elog- 1 km3net-elog_elog:8080 check resolvers docker init-addr libc,none
Tamas Gal wrote: |
Yes, I used the empty `passwd` file from example. When I then click on one of the logbooks, I get to the page where I can register a user (see attached screenshot). After clickin on "Save" for the user registration, I again get the redirect error. Once there is a registered user (i.e. a non-empty password file) the redirect issue is persistent. Any idea where the problem might be? I just emptied the password file again, so you can have a one-shot, if you like.
Btw. I have SSL termination in the load balancer, so ELOG does not need to do any SSL related things (the swarm is in a locally isolated network, so all internal communication between the load balancer and the swarm machines are safe). Maybe that's the issue? On the other hand, the main page loads fine and uses SSL termination too, so I don't know, maybe there is logic behind the authentication which collides with the SSL termination.
Stefan Ritt wrote: |
Yes I see the redirects. You say with the example logbook it works, right? Is it the password protection which triggers the problem or anything else? Does it work if you take out the password protection? The key is to identify which setting in your config file triggers the problem, so you can bracket the problem down between the example logbook and your logbook definition.
|
|
|
elog submit problem, posted by Heiko Scheit on Thu Jul 4 16:52:59 2002
|
If a message is submitted via the elog command then the reply string '> ' is only inserted in the first line if a reply is made.
This message was submitted with the following commandline:
elog -v -h midas.psi.ch -p 80 -s elogdemo -l Forum -a "Icon=icon4.gif" -a "Author=Heiko Scheit" -a "Author Email=h.scheit@mpi-hd.mpg.de" -a "Subject=elog submit problem" "...Message-text..."
Please press the reply button to see the problem. |
reverse sort and threaded mode does not display first entry, posted by Heiko Scheit on Thu Jul 4 17:05:03 2002
|
When the option 'Reverse sort = 1' is used then the first entry
is not displayed (ID=1) when threaded mode is requested.
Probably you can see the problem using this link and switching
on reverse sort.
http://midas.psi.ch/elogdemo/Linux/last20?mode=threaded |
exit status of elog, posted by Heiko Scheit on Thu Jul 4 17:09:09 2002
|
The exit status of elog is always 1. It should be zero for
a successful submission. |
|