Re: "New User" option does not work when Authentication=Webserver, posted by Stefan Ritt on Tue Aug 4 13:29:23 2020
|
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?
|
|
Re: "New User" option does not work when Authentication=Webserver, posted by Jan Just Keijser on Wed Aug 18 09:05:51 2021
|
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?
|
|
|
Re: "New User" option does not work when Authentication=Webserver, posted by Stefan Ritt on Thu Feb 10 17:32:42 2022
|
Thanks for your patch, I committed it.
Stefan |
Re: "Logkook dir" in top group [global] section ineffective, posted by Yoshio Imai on Fri Nov 25 14:05:08 2005
|
OK, I found the note about "Logbook dir" in Stephen Wood's entry (http://midas.psi.ch/elogs/Forum/1101)  |
Re: "Logkook dir" in top group [global] section ineffective, posted by Stefan Ritt on Thu Dec 22 20:50:57 2005
|
Yoshio Imai wrote: | There are also one question/request (you see that we use the elog extensively now ):
When searching for a particular event in our shift log using the "Find" function, it would often be useful not to go to the single entry, but to the page where that entry resides. This way we can see the whole context of the event. When clicking onto an entry in the "Find" result page, this takes us of course to the single entry, but could you add a function to go to the page instead. Alternatively, is it possible to include a button "Go to page" in the single entry view (it need not even be exactly +/-N entries around, the usual page partition would do)? |
I implemented that request. When you click on "list", it takes you to the listing page containing the current entry, which is even highlighted. Have a look at this forum if this is what you like. |
Re: "Logkook dir" in top group [global] section ineffective, posted by Yoshio Imai on Wed Jan 4 15:27:31 2006
|
Stefan Ritt wrote: | I implemented that request. When you click on "list", it takes you to the listing page containing the current entry, which is even highlighted. Have a look at this forum if this is what you like. |
Thank you!
I just installed the latest revision; it is exactly what we need.
I found one problem, however: while linking the binaries for elogd, the linker complained about an undefined reference to forkpty implemented in libutil. I had to add the linker option -lutil to the Makefile target elogd:, then it compiled correctly.
One strange thing (maybe it isn't strange at all) is the following behaviour: when the list view is set to "summary", then the line containing the entry where we clicked "list" is highlighted, however when the list view is set to "full", it isn't. Is this "a bug, or a feature"? 
Thanks for the work from all, and happy new year.
Yoshio |
Re: "Logkook dir" in top group [global] section ineffective, posted by Stefan Ritt on Mon Jan 9 20:09:16 2006
|
Yoshio Imai wrote: | One strange thing (maybe it isn't strange at all) is the following behaviour: when the list view is set to "summary", then the line containing the entry where we clicked "list" is highlighted, however when the list view is set to "full", it isn't. Is this "a bug, or a feature"?  |
Was a bug. I have fixed that in revision 1591. |
Re: "Leave Page" pop-up when "Submit" entry, posted by Stefan Ritt on Tue May 12 11:27:52 2015
|
Thanks for the "boiling-down" of your config file. That helped me to reproduce the error quickly. It only occurs if you have a date/time attribute which is hidden as a conditional attribute. This is a unusual combination, that's why I haven't seen that bug before. Actually some
JavaScript code checks the validity of the date attribute, but since it is conditionally not there, the JavaScript code crashes, which triggers the dialog box you see. It's now fixed in the repository.
/Stefan
> I have a little problem with elogd 3.1.0. The problem persists up to the latest ELOG version, even in the
> development branch (V3.1.0-8196b81):
>
> When I want to "Submit" a new entry, I get a javascript pop-up that asks me:
>
> _This page is asking you to confirm that you want to leave - data you have entered may not be saved._
>
> with the options:
> "Stay on page" or "Leave page".
>
> The entry is properly submitted if I agree to "Leave page".
> But it is very confusing for my users: they are afraid to loose their entry text.
>
> This problem only shows for some specific logbook configurations.
> Below is a minimal logbook configuration that shows this problem:
> if you select "entry = short", the pop-up is shown;
> if you select "entry = long", the pop-up is not shown, the entry is created immediately.
>
> Attributes = entry, when
> Options entry = short{1}, long
> Type when = datetime
> {1} Show Attributes Edit = entry
>
>
> (PS: it took me several hours to boil down my 120 line configuration into four lines :-) ) |
|