I recommend to clear all your browser cookies for the elog server. Sometimes an old cookie confuses the
access mechanism.

Stefan

Hi,

we're using elog to handle various logbooks. It's a great tool by the way. 
While replacing the Win32 2.7.8 Release with Release 3.1.4-2, we ran into the 
following problem.

Since elog is for internal usage only, we allow users to self-register if they 
are new. Therefore  "Self register = 1" is set in the [global]-area.

Using the Win32-Release of elog, it worked fine while using Release 2.7.8 or 
2.8.0. Starting with Release 3.x everytime you try do add a user, the following 
error occurs:

      Error: Command "config" is not allowed for user ""

No matter if the user self-registers or is added by an elog-admin-user. We 
tried various 3.x Releases from 3.1.0-1 up to the latest 3.1.4-2. 
The error-message remains the same. Curious, although an error-message occurs, 
the user is added and able to use all logbooks. We also ran elogd in 
Debug-Mode (-v3), but the output didn't give a clue.

By the way using the same configuration on a linux-based installation (Debian 
and RaspiOS) self-registration works smooth. No error-message occurs.

So what could be the problem? Any suggestion is greatly appreciated.

Thanks in advance. 

I just tried the same on my latpop (MacOSX 12.4) and it worked flawlessly:

ritt@MBP14 build % echo "blah" | ./elog -h 127.0.0.1 -p 8080 -l demo -r 2 -x
Message successfully transmitted, ID=3
ritt@MBP14 build % host 127.0.0.1
Host 1.0.0.127.in-addr.arpa. not found: 3(NXDOMAIN)
ritt@MBP14 build % echo "blah" | ./elog -h localhost -p 8080 -l demo -r 2 -x
Message successfully transmitted, ID=4
ritt@MBP14 build %

So have you tried with the "-v" flag? Maybe your network is not correctly configured. You can also try the "curl" utility (see elog:68597), maybe you see some different error there. You get that via MacPorts.

Stefan

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.

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.

Attached is the log, where you can see that `Operations+IT` redirects to `Operations+IT/` and that redirects to `Operations+IT` again, which then goes to `elog.test.km3net.de` and `Operations+IT` again etc. etc.

EDIT: I  use the very same load balancer confugration for dozens of other services incl. Apache, Nginx, GitLab, Mattermost, RocketChat etc. and all work fine. As written before, also the "example" logbook works (without password protection).

I also tried `/` at the end of the URL but it has no effect.

I am pretty clueless currently...

My problem is that I don't even reach the page where I can enter a password. If you go to https://elog.test.km3net.de and click on a logbook, you'll see that it immediately goes into a redirect loop. I already logged the routing but there is nothing else...

Yeah, after you enter a password, elog redirects to what it finds in "URL". You can trace that by opening "development tools" in Google Chrome, go to "network" and watch packets going back and forth. I never worked with the load balancer, but maybe you need a different "URL" containing a '/' at the end?