| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69370
|
Mon Jun 14 17:25:02 2021 |
 | Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | All | V3.1.4 | Bug Report with CSS includes (was Re: How to format a column in list display?) | Okay, found some solution for my problem:
List Change Pikett = <div class="pikett">$Pikett</div>
CSS=pikett.css
And file themes/default/pikett.css contains:
.pikett {
background-color:white;
font-size:16px;
font-family:monospace;
text-align:left;
}
That works like a charm - until I log in to the logbook. Then the include of the CSS in the header is garbled with some "prefix" of random chars:
And a quick check in the source code shows some bad code:
L7615: function "show_html_header"
rsprintf("<link rel=\"stylesheet\" type=\"text/css\" href=\"%s%s\">\n", css_base, css);
Here css_base is a not initialized local variable of the function. In fact the above line is the only reference of that variable char css_base[1000].
The bug is still present in elog-3.1.4-611489b
| Andreas Luedeke wrote: |
|
There is the nice conditional formatting feature for List display:
Cell Style <attribute> <value> = <style>
I would like to use it without conditions: some attributes should always be formatted in a specific way.
Specifically I want a generated attribute (combined from other attributes) to be display in monospace font.
The "Format Pikett = 0, attribname, messagelist" works nicely for the single entry display (pik1), but not for List view (pik-list).
Would it be possible to create a new command "List format <attribute> = <css_class_name>,<css_class_value>,<width>,<size>", or is there another way to achieve this?
|
|
|
69372
|
Mon Jun 14 18:51:59 2021 |
 | Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Bug report | All | V3.1.4 | Bug Report with CSS includes (was Re: How to format a column in list display?) | Hi Andreas,
the bug you have found was already reported in an earlier issue, together with the same solution you have found.
https://elog.psi.ch/elogs/Forum/69368
Best wishes,
Sebastian
| Andreas Luedeke wrote: |
| [...]
That works like a charm - until I log in to the logbook. Then the include of the CSS in the header is garbled with some "prefix" of random chars:
And a quick check in the source code shows some bad code:
L7615: function "show_html_header"
rsprintf("<link rel=\"stylesheet\" type=\"text/css\" href=\"%s%s\">\n", css_base, css);
Here css_base is a not initialized local variable of the function. In fact the above line is the only reference of that variable char css_base[1000].
The bug is still present in elog-3.1.4-611489b
|
|
|
69387
|
Wed Aug 18 09:05:51 2021 |
| Jan Just Keijser | janjust@nikhef.nl | Bug report | Linux | 3.1.4-2 | Re: "New User" option does not work when Authentication=Webserver | here's the patch that I use to enable use creation and deletion in combination with Webserver authentication.
The idea behind the patch is that if the user logged in via "http_user" is an elog admin, then {s}he is allowed to save a random user configuration, including creating or deleting a user.
| Stefan Ritt wrote: |
|
Unfortunately I locallly don't have Webserver authentication, so I cannot check or debug. If you send me a diff that works for you, I'm happy to incorporate it.
Stefan
| Jan Just Keijser wrote: |
|
Our setup uses "Authentication=Webserver" + no automatic user registration. Thus, logbook admins should add a user by clicking "Config" and then "New user". However, no matter what they fill in in the "new user " dialog, as soon as they hit "Save" an error pops up saying that their username (the admin one, not the new one) already exists. I found the following code:
int save_user_config(LOGBOOK * lbs, char *user, BOOL new_user)
{
char file_name[256], str[256], *pl, user_enc[256], new_pwd[80], new_pwd2[80], smtp_host[256],
email_addr[256], mail_from[256], mail_from_name[256], subject[256], mail_text[2000], str2[256],
admin_user[80], url[256], error[2000], sid[32];
int i, self_register, code, first_user;
PMXML_NODE node, subnode, npwd;
/* if we outsourced the authentication, use external username */
getcfg(lbs->name, "Authentication", str, sizeof(str));
if (stristr(str, "Webserver")) {
/* do not allow HTML in user name */
strencode2(user_enc, http_user, sizeof(user_enc));
} else {
strencode2(user_enc, user, sizeof(user_enc));
}
which seems to be the culprit: the admin user is logged using his/her Webserver (http_user) credentials and this overrides anything that he/she might fill in. If I remove the "Authentication" check then I can create a new user without problems. So, how to fix this? should the "Authentication=Webserver" check be extended with a self/auto registration check?
|
|
|
| Attachment 1: elog-webauth.patch
|
diff -Naur elog-3.1.4-3.org/src/elogd.c elog-3.1.4-3/src/elogd.c
--- elog-3.1.4-3.org/src/elogd.c 2021-02-19 09:55:03.000000000 +0100
+++ elog-3.1.4-3/src/elogd.c 2021-08-17 17:26:06.492232620 +0200
@@ -13273,7 +13273,7 @@
/* if we outsourced the authentication, use external username */
getcfg(lbs->name, "Authentication", str, sizeof(str));
- if (stristr(str, "Webserver")) {
+ if (!is_admin_user(lbs, http_user) && stristr(str, "Webserver")) {
/* do not allow HTML in user name */
strencode2(user_enc, http_user, sizeof(user_enc));
} else {
@@ -26139,6 +26139,8 @@
}
/* make sure user is logged in */
+ if (strcmp(user, http_user) == 0)
+ return TRUE;
if (lbs && !logged_in(lbs))
return FALSE;
|
|
69388
|
Sat Aug 28 21:32:09 2021 |
 | Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | ELOG V3.1.4 | Adding entries without being logged in stopped working with attachments | Hi Stefan (et al),
we have several logbooks that allow to add new entries without logging in first.
That still works, as long as these entries don't have any attachments.
As soon as there is an attachment you are asked to login in the web interface.
I hope that this is not an intentional feature, but a bug?
Several of our software tools now fail to submit elog entries.
The problem occured when we upgraded to ELOG V3.1.4-2e1708b.
Version elog-3.1.4-611489b did not show this behaviour.
Kind Regards
Andreas
|
|
69399
|
Thu Oct 21 11:00:46 2021 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | 3.1.4-2e1708b | Redirect in Execute new needs space after ">" | EDIT: forget the tip below. Instead just call script files: inline scripting in the ELOG config shows very strange behavior. Doing the same in external scripts works reliable.
I just spend an hour searching for a problem. To avoid others to spend the hour again, here's a little "special behaviour" of shell execution in ELOG you should know about:
If you want to do redirect to a file in a shell execution, put a space before and after the redirecting. The following does not work:
Execute new = if ! [ -z "$CampaignID" ] ; then echo "$CampaignID" >/usr/local/elog/logbooks/elog-campaign.default ; fi
You will not get an error message, but the file is not created. But if you add a space it will work as expected:
Execute new = if ! [ -z "$CampaignID" ] ; then echo "$CampaignID" > /usr/local/elog/logbooks/elog-campaign.default ; fi
It is not really a bug; if you know about it, then it is not a big deal: hence this entry here. I saw this behavior on a Linux RHEL7 system.
In case you are wondering: I use this to create a default for the field CampaignID, to be used for new entries in combination with a Preset:
Preset CampaignID = $shell( if [ -r /usr/local/elog/logbooks/elog-campaign.default ] ; then cat /usr/local/elog/logbooks/elog-campaign.default;fi ) |
|
Draft
|
Thu Oct 21 14:57:14 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Linux | 3.14 | wrong server HTTP status code when login failed | Hi,
I am trying to access elog through a python client (https://github.com/paulscherrerinstitute/py_elog) and found a strage strange behavior which may be related server side problem. The python script generates get/post messages via the python requests library. This works fine so far and I can view and post messages. However, if a wrong user/password is provided, the server still returns HTTP status code "200 OK", although login failed. Instead, it should return something like "401 Unauthorized". This behavior later causes problems since the python client thinks login was successful. After experimenting around I think this could be caused by a server side misconfiguration. Any ideas?
I am not sure if this imformation is important: We use LDAP as user/password provider for elog. |
|
69402
|
Thu Oct 21 15:17:52 2021 |
 | Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Linux | 3.14 | wrong server HTTP status code when login failed | Hi,
I am trying to access elog through a python client (https://github.com/paulscherrerinstitute/py_elog) and found a strage strange behavior which may be related server side problem. The python script generates get/post messages via the python requests library. This works fine so far and I can view and post messages. However, if a wrong user/password is provided, the server still returns HTTP status code "200 OK", although login failed. Instead, it should return something like "401 Unauthorized". This behavior later causes problems since the python client thinks login was successful. After experimenting around I think this could be caused by a server side misconfiguration. Any ideas?
I am not sure if this imformation is important: We use LDAP as user/password provider for elog. |
|
69403
|
Thu Oct 21 15:19:16 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Linux | 3.14 | Re: wrong server HTTP status code when login failed | Seems like I've discovered another bug here related to umlauts in my name. :D
I was submitting this post and forgot to put an icon. Elog seems to have saved a copy of my message, which I could not edit since my username does not match the bugged name saved for this message.
| Chris Körner wrote: |
|
Hi,
I am trying to access elog through a python client (https://github.com/paulscherrerinstitute/py_elog) and found a strage strange behavior which may be related server side problem. The python script generates get/post messages via the python requests library. This works fine so far and I can view and post messages. However, if a wrong user/password is provided, the server still returns HTTP status code "200 OK", although login failed. Instead, it should return something like "401 Unauthorized". This behavior later causes problems since the python client thinks login was successful. After experimenting around I think this could be caused by a server side misconfiguration. Any ideas?
I am not sure if this imformation is important: We use LDAP as user/password provider for elog.
|
|
|