ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
69721
|
Fri Jan 19 15:49:13 2024 |
| Frank Heyroth | heyroth(at)cmat.uni-halle.de | Bug report | Linux | 3.1.4 | user change under webserver authentication not recognized |
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 |
69725
|
Wed Jan 24 14:50:21 2024 |
| Frank Heyroth | heyroth (at) cmat.uni-halle.de | Bug report | Linux | 3.1.5-1 | Re: user change under webserver authentication not recognized |
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. |
69726
|
Tue Jan 30 13:10:38 2024 |
| Alexey Khudyakov | khudyakov@sepulcarium.org | Bug report | Linux | ELOG V3.1.5 | Re: http status 200 returned for "file not found" |
> "file not found" should return http code 404. elogd returns code 200 together
> with a page containing text "404 not found". This pollutes the browser cache
> with wrong content (in this case, we are trying to load a css file, and the browser
> is trying to use text "404 not found" as if it were a css. bad. file not found
> should return http code 404. K.O.
Yes. That's quite a problem when interacting with ELOG programmatically. Only way to
find whether response succeeded or failed with 404 is to parse response body
When file is not found send_file_direct calls show_html_header which in turn calls
show_http_header which sets HTTP code 200 unconditionally. It's reasonably easy to
patch around. |
69741
|
Fri Feb 23 14:59:29 2024 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | ELOG V3.1.5 | Re: http status 200 returned for "file not found" |
> > "file not found" should return http code 404. elogd returns code 200 together
> > with a page containing text "404 not found". This pollutes the browser cache
> > with wrong content (in this case, we are trying to load a css file, and the browser
> > is trying to use text "404 not found" as if it were a css. bad. file not found
> > should return http code 404. K.O.
>
> Yes. That's quite a problem when interacting with ELOG programmatically. Only way to
> find whether response succeeded or failed with 404 is to parse response body
>
> When file is not found send_file_direct calls show_html_header which in turn calls
> show_http_header which sets HTTP code 200 unconditionally. It's reasonably easy to
> patch around.
I fixed the code to properly return "404 Not Found" in case a non-existing file is requested.
Stefan |
69742
|
Fri Feb 23 15:13:46 2024 |
| Stefan Ritt | Thstefan.ritt@psi.ch | Bug report | Linux | 3.1.5-1 | Re: user change under webserver authentication not recognized |
Thanks for the fix, I committed it. Please give it a quicky try sinc I cannot test it here (don't use webserver authentication...)
Stefan
Frank Heyroth wrote: |
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.
|
|
69752
|
Thu Mar 7 08:55:49 2024 |
| Andreas Warburton | andreas.warburton@mcgill.ca | Bug report | Mac OSX | 3.1.5-23df00d9 | Runaway bogus attachment counts in Summary view attachment column |
On a new MacBook Pro (Silicon M3), I installed version 3.1.5 build 23df00d9. The application appears to work normally, except that, after a short while, the indicated attachment count (paperclips in the attachment column of the Summary view) starts to increment fairly rapidly with each time that I visit the page. Attachment counts appear even for records that don't have any attachments. When I access records individually, either those with or without real attachments, everything looks OK. Any insights as to what might be causing this, and how to correct?
Installation went smoothly using the (now longstanding) MacOS installation instructions, with one small exception: When doing the "sudo launchctl load ..." step, there is occasionally an I/O error of some kind. (Sorry, I don't have an exact transcript of the error at the moment, but it appears to refer to line 5 of a script.)
Many thanks,
Andreas W. |
69755
|
Sat Mar 9 17:04:13 2024 |
| Andreas Warburton | andreas.warburton@mcgill.ca | Bug report | Mac OSX | 3.1.5-23df00d9 | Re: Runaway bogus attachment counts in Summary view attachment column |
A quick follow-up concerning the secondary matter I mentioned in my last post, namely the issues I had with the deprecated "sudo launchctl load ..." and "sudo launchctl unload ..." subcommands currently provided in the ELOG installation instructions for MacOS. I found a solution to this -- will post it in a separate thread.
The strangely auto-incrementing attachment counts in the Summary view are still present, and I'm curious if anyone else has experienced those. Also, I could not find a way to customize the Summary view such that the final (rightmost) column with the attachment counts can be suppressed. That would at least put the problem out of sight until a developer can intervene and fix the bug.
Andreas Warburton wrote: |
On a new MacBook Pro (Silicon M3), I installed version 3.1.5 build 23df00d9. The application appears to work normally, except that, after a short while, the indicated attachment count (paperclips in the attachment column of the Summary view) starts to increment fairly rapidly with each time that I visit the page. Attachment counts appear even for records that don't have any attachments. When I access records individually, either those with or without real attachments, everything looks OK. Any insights as to what might be causing this, and how to correct?
Installation went smoothly using the (now longstanding) MacOS installation instructions, with one small exception: When doing the "sudo launchctl load ..." step, there is occasionally an I/O error of some kind. (Sorry, I don't have an exact transcript of the error at the moment, but it appears to refer to line 5 of a script.)
Many thanks,
Andreas W.
|
|
69756
|
Sat Mar 9 17:14:09 2024 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Mac OSX | 3.1.5-23df00d9 | Re: Runaway bogus attachment counts in Summary view attachment column |
I'm traveling right now and will only next week be able to look into that, so please be patient for a few more days.
Stefan |