One other way would be to do the conversion on the client-side using javascript.
Overwrite the complete datetime input cell and add an event listener to either onChange of this input or the submit event, to trigger the conversion before submitting, so elog would get the converted time.

In out elog some entries get additional information added in this way.

Dear Stefano,

the support for the LDAP is limited. As stated in the documentation "on an as-is basis".
We use the AD of our university, but I had to re-write a part of the elog auth.c to match the LDAP-tags, so this could also be a issue.

As for your question.
If some of the logins a working fine, then the other ones could have issues with the DN string, maybe...

Your 2 lines of the logfile output show 2 (attempt) directly after each other.
There should be some lines regarding LDAP in between.
I get the (attempt) and directly (success) case only for FILE authentication.

If you have left out these lines on purpose, ignore the following suggestion.
Is it possible that you have previously used FILE authentication for the users, who could login via LDAP successfully?
If yes, delete a user in passwd.file, which could successfully login via LDAP and let them login again.
This should prove, that there is no artifact from previous FILE authentication.

An other idea may be, check if the users have non-standard characters in their name, mail or password.
e.g. I had problems with german umlauts and your mail ends in it, so there could be some other special charaters.

I hope, I could help.
Best wishes,
Sebastian


> Dear experts,
>    I have a logbook which has authentication as follow
> 
> Authentication = LDAP, File
> Password file = PASSWD.file
> LDAP server = ldaps://it-ldap-XXX.XXX.XX:1636
> LDAP userbase = ou=people,ou=RGY,o=XXX,c=XX
> LDAP login attribute = uid
> LDAP register = 0
> Self register = 0
> Allow password change = 0
> 
> Some of the my user (but not all) have issue in accessing this protected elogbook.
> The ldap password is correct (we checked).
> What I see in the log is as follow:
> 
> 22-Feb-2021 11:25:51 [XXX.YYY.ZZZ.QQ] {Beam Run} LOGIN user "USERNAME" (attempt)
> 22-Feb-2021 11:25:59 [XXX.YYY.ZZZ.QQ] {Beam Run} LOGIN user "USERNAME" (attempt)
> 
> The user USERNAME is present in PASSWD.file.
> 
> For other user, for which the login works, I do see an (attempt) and then (success)
> 
> we tried the standard stuff: clear cache/cookies and with different browser. We also tried to remove the user from PASSWD.file and 
> create it again, but nothing has worked.
> 
> Any suggestion how I can debug this problem?
> 
> Thanks in advance,
>   Stefano

Hi,

we use the LDAPS connection in our setup and it works without issues.
You have to specify "LDAP server = ldaps://server.tld:port" and normally it uses a different port (636) than insecure LDAP (389).

Best wishes,
Sebastian

I am not Stefan, but maybe I can add to this issue.

Personally I think it is not a good way to dump all the information into the text field and try to let the server parse it.
This could be archived more simply by using e.g. the python elog scripts or using the elog command tool to directly submit well structured elog entires.

As you have mentioned you could use the "execute new|edit|delete" commands to do the things you want to do.
Let the called script fetch the elog entry and alter it in the way you like and resubmit the entry.
(You have to make sure to don't generate a endless loop and you have to proably have to use a forwarding script as the elog "execute" command waits for finished execution).
This way you don't touch the 1500 characters limit of passing $text to the execute command.

Also the point "filling an attribute X with free text" needs some kind of (extended) parsing, which isn't possible with the subst command.
In our elog we such an attribute X, which is in some conditions filled with a set of other attributes and on other conditions just a normal input field, so the user could type custom text in.

"fill an attribute automatically with the character length of the text" could be done with the above mentioned execute command or it could be done on the clientside (e.g. browser using javascript or if automatically generated by a script, then directly by the script)

I hope it helps to build our application.
Best wishes,
Sebastian

Sorry Stefan, but it is possible as you have the scripting ability.

The idea is to use "Preset Test_Attribute = $shell(script_to_get_the_last_entry)", where the script asks elog about the details and parses them.
The problem here is, that the elogd already is working to resolve the click on "new entry" request (or similar) and the script can't call elogd until the page is delievered, what is to late.
(If it would, the elogd will hang.)

So the script either has to directly parse all the entry.log files in the logbook folder or you need a second elogd running, which can answer the request from the script.
This second elogd could run on a different port and it doen't need to be public as it only answers internal requests and could use the same config as the "primary" elogd.
My idea for the script uses the python elog module to establish the connection and do the parsing.

I hope this helps as a workaround.
Best wishes,
Sebastian

Hi Chris,

Additional the the HTTP request sugested by Stefan you could also use the search functionality of the elog python module.
For the HTTP request you may also need a way to provide credentials or transmit cookies, if the elog needs authentification.

I think your request to alter the samples logbook will be called with "execute new" or similar at submit time of the entry to the measurement logbook.
Then both methods will have the issue that elogd is still processing the submit and can't answer new requests until the old is finished.
Have a look at https://elog.psi.ch/elogs/Forum/69328 for possible workarounds.

Best wishes,
Sebastian

I am glad, we could help.

I can see a caveat in the recommendation.
By having "Execute New = echo $attrib > /path/last_attrib" and "Preset attrib = $shell(cat /path/last_attrib)" as the most simple construction.
But there are cases, where /path/last_attrib can get out of sync with the elog by e.g. editing or deleting the last entry, which is the most likely one to edit or delete.

I am aware, that you can make the logic more complex to fix this issue,
but basically you have the same information stored in two locations and you have to keep them in sync for the system to be reliable.
I am not sure, if it will be more hassle to construct a script/config system to keep them in sync or to find a solution which gets the information from the elog database.