Hi Sebastian,

Nice to hear !

So i retried some tests and in fact, as my NAS LDAP is using self-signed certificate, connexion is refused by openldap libs from ELOG (ldap_simple_bind_s Can't contact LDAP server).

By disabling certificates verification in ldap.cfg on ELOG VM, i could connect using LDAPS URL...

Maybe it should be an option to add in elog.conf... :-)

Thanks for information,

Laurent

Do you actually need to convert the date into the internal format? Why not keeping simply the full string YYYY-MM-DD HH:MM. If the use is disciplined enough to always use the correct format, there should be no issue. I invented the datetime format to "force" all date/time inputs to have the correct format. If you have a proper YYYY-MM-DD HH:MM format, even sorting (now by string) should work correctly.

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

Hi,

It seems that ELOG does not support LDAPS but only simple LDAP connection.


Regards

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

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.

Hello all,

I have the issue, that we can't list entries older than 1 year, if "Last default = 31" (or any other number, but they are restricted to 1, 3, 7, 31, 92, 182, 364) is active.
The quick filter displays the option for "-- all entries --" but selecting this only reloads the default time frame (31 days).

A workaroud is to select a different time e.g. 1 day and then modifying the URL to ?last=1000 or so, gives acces to the old entries.
But this is not the intended way to do it.

The Find results are also affected by this. e.g. selecting 1.1.2020 to 1.6.2020 with "Last default = 31" yields 0 results.
The "Show last default" atrtribute for 1, 3, 7, 31, 92, 182, 364 work fine and overwrite the "last default" time in the quick filter.

In the Find page, there will be a "All entries" option at the top of the date selection box, if "Show last default" equals to 1, 3, 7, 31, 92, 182 or 364
(2, Bug: it is empty for "Show last default = 0" and not All entries")

Selecting "All entries" or the empty first value in the Find "show last:" date , will give a Find result with the "Last default" time constraint.

Thus it is not possible to get any entry older then the longst period possible (364 days), if you don't know about the workaround.

Best wishes,
Sebastian

PS: I use a self-compiled version of elog up to the 395e101 commit in the bitbucket repository with pull request #7 (which hasn't been merged for over 1,5 years) and a simple patch for our local LDAP.

I don't feel comfortable allowing the elog daemon to execute random shell scripts. Is there no other way?