| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69391
|
Tue Sep 14 17:48:52 2021 |
 | Manoel Couder | mcouder@nd.edu | Question | Linux | ELOG V3.1.2-bd7 | How to lock a specific entry? | Hi All,
I am using elog to track technical changes in an experiment but also to log what experimentalist are doing during an experiment. For the latter, I would like to be able to lock those entries from being further edited after the expertiment if finished. Is there a way to do that?
Thanks,
Manoel |
|
69390
|
Mon Aug 30 08:41:14 2021 |
 | Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 3.1.4 | Re: Large log file size | If the logbook files are getting big, searching text in entries can take quite some time. But if you have a log file logging all activities, that should not slow down elog since the server just appends at the end of that file which is a quick operation.
| Alan Grant wrote: |
|
Can the size of the application log file affect performance?
|
|
|
69389
|
Mon Aug 30 03:08:15 2021 |
| Alan Grant | agrant@winnipeg.ca | Question | Windows | 3.1.4 | Large log file size | Can the size of the application log file affect performance? |
|
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
|
|
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;
|
|
69386
|
Wed Jul 21 16:16:29 2021 |
| Alan Grant | agrant@winnipeg.ca | Question | Windows | 3.1.4 | Logging Main page entries, each with multiple ongoing events | Is there any way to log child events on the detail pages for a fixed number of entries on the main page? For example, I have 15 vehicles to enter on the main page, ID'd by Vehicle Number. Within each of those entries I will be logging ongoing repair service entries with certain attributes.
So how might I design this concept without having repeating vehicle entries on the main page for every service event, and preferably without splitting the information between two linked logbook tabs?
|
|
69385
|
Mon Jul 19 18:41:29 2021 |
| Janusz Szuba | janusz.szuba@xfel.eu | Question | Linux | 3.1.4 | Deny option and Guest commands | Hi,
I have a logbook with guest access and guest can also enter a new entry (in config: Guest List Menu commands = New, Find, Select, Login). For other reason in a global section, I put
Deny New = account1, account2
This somehow invalidates Guest List Menu commands, since as guest I don't see New button anymore. Is this behaviour desired? Otherwise, I would need to move Deny option to plenty of individual logbook configs. Just to explain the reason, those accounts are set up to only read entries and not to create new ones. Or maybe you can suggest a different solution?
Best |
|
69384
|
Wed Jun 30 13:50:08 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Question | Linux | 3.13 | Re: Drop attachments here... | Thanks for the merge.
I found a more general solution, as there could be the posibility to have the author as "select" or "radio box" input in the form, where the fix breaks.
But I think in most of the cases the author is a preset input, if used with "restrict edit = 1", so the merged fix should be fine.
https://bitbucket.org/merrx/elog/commits/7aacfbcac43b1192e5271fa7b2c80f4825c94d23
Today we ran into this issue again, but this time the curpit was encoding...
The author name in the password file was differently encoded as the author name from the xhr request.
For this instance there was a umlaut in the name.
I haven't got a good solution for this at the moment.
The workaround is to check the encording in the password file and make it matching.
But as for automated logins / user generation e.g. via LDAP (in our case) one should be aware of this issue.
| Stefan Ritt wrote: |
|
Looks good, I merged the pull request.
|
|
|