ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
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.
|
|
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;
|
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?
|
|
69392
|
Tue Sep 14 18:18:03 2021 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | ELOG V3.1.2-bd7 | Re: How to lock a specific entry? | You can either lock all entries or none. So I would propose you set up two logbooks, one for technical changes which is not locked and one for what experimentalists are doing which is locked. Locking can be done a certain time after an entry has been made (like 1h, 1d, 1 month etc.). Or you simply make the logbook read-only.
Stefan
Manoel Couder wrote: |
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
|
|
69393
|
Wed Sep 15 13:52:59 2021 |
| Bolko Beutner | bolko.beutner@desy.de | Question | Linux | Other | 3.1.2 | Re: Reverse proxy of Elog using Docker and Nginx? | I have the same problem -- did you find a solution in using the nginx revese proxy with user login?
Andrew Wade wrote: |
It does indeed seem to be a cookie stripping issue. I just need to figure out how to get Nginx to forward these properly.
Thanks for the help.
Stefan Ritt wrote: |
Actually this forum works through an Apache reverse proxy with authentication and it works, so I suspect that the problem has to do with jwilder/nginx-proxy. Since we don't have this here, all I can propose is that you do debugging yourself. Run elogd with the -v flag so that you see all requests coming from the user through the proxy. Compare the requests through Apache and Nginx to see if any argumets are stripped or mangled. Upon successful login, elog sets a cookie with a unique session-ID (the cookie name is "sid") to the browser. If you proxy strips that cookie, you would land on the login page. Maybe look in that direction.
Stefan
Andrew Wade wrote: |
Yes, I tried setting the URL parameter to the url used by the proxy. It goes to the correct address but that landing is the login page.
Andrew
Stefan Ritt wrote: |
Have you tried the "URL = ..." statement? This determines you elog redirects if you log in. If you reach elog through a proxy, the URL is a different one that if you access it directly. In your case the proxy URL might be necessary.
Stefan
Andrew Wade wrote: |
I've been trying to configured a Synology NAS to run my personal elog with a reverse proxy to the outside world. The best way seems to be running Elog in a Docker instance and then running a separate connected Docker running a nginx-proxy (in this case jwilder/nginx-proxy). This second container manages the certificates to letsencrypt and mapping URL requests to relevant containers so that connection is secured properly.
It worked great in the initial test. However, I have an issue with authentication. When I password protect the elog it goes to a login page. When I give an correct password it loops back to the login page (incidentally when I give an incorrect password it gives an 'Invalid user name or password!' warning). So I know that its getting the correct password but there is some issue that is resetting or ignoring the authentication. I am never able to actually get to the protected content.
Does anyone have any experience in using Nginx to setup a secure reverse proxy? Any insights into why this would mess with the authentication of elog?
Side note: I have tried using Apache to do the same and authentication worked fine. But the pre-canned jwilder/nginx-proxy docker manages all the certificates automatically and seamlessly and allows me to have multiple services running on the same outward facing port on my router. There is no equivalent (as far as I know) that uses Apache for proxying with letsencrypt.
|
|
|
|
|
|
69395
|
Wed Oct 13 08:17:23 2021 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Unknown | Re: How to access PSI Elog data from other web clients | When elog has been developed, REST did not yet exist. The closest you can get is the RSS API. Just try https://elog.psi.ch/elogs/Forum/elog.rdf and you see the result for this forum. To write to elog, you can use teh HTTP/HTML interface and mimic a browser. See for example elog:69209
Stefan
Lin Wang wrote: |
We want to develop separate mobile web pages for the web applications deployed at CSNS accelerator, including the PSI Elog.
In Elog, is there RESTful API or HTTP/JSON or HTTP/XML interface for other web clients to access?
Or is there any workaround?
|
|
69398
|
Thu Oct 21 00:42:42 2021 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Info | Linux | Unknown | Re: How to access PSI Elog data from other web clients | There is a python API to access ELOG via HTTP: https://github.com/paulscherrerinstitute/py_elog
Lin Wang wrote: |
We want to develop separate mobile web pages for the web applications deployed at CSNS accelerator, including the PSI Elog.
In Elog, is there RESTful API or HTTP/JSON or HTTP/XML interface for other web clients to access?
Or is there any workaround?
|
|
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.
|
|
|