Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 363 of 808  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Icon Author Author Emaildown Category OS ELOG Version Subject
  69369   Mon Jun 14 16:15:10 2021 Warning Sebastian Schenksebastian.schenk@physik.uni-halle.deBug reportLinux | Windows | Mac OSX | All | Other3.1.4Additional forbidden attributes

Hello Stefan,

I stubbled on a issue with our elog.
We introduced an attribute "mode" to one of the elogs and it breaks the "Find" function as this attribute is already used for the viewing settings "full", "summary" and "threaded".
(HTTP parameter pollution)

I suspect other special attributes used by the internals of elog should also not be allowed.
A quick search in the "Find" reveals these attributes in the URL, so I guess, these should also be avoided.
This list could be incomplete

npp, ma, da, ya, mb, db, yb, attach, reverse, mode

A simple workaround would be updating the documentation to add these to the list of forbidden attributes.
https://elog.psi.ch/elog/config.html
Maybe a warning can be added, if the elog behaves unexpected, try other attribute names, as they can conflict with internal attributes.

A fix could be to add a prefix for internal attributes, which can't be used for user attributes.

Best wishes,
Sebastian

 

PS: I also noticed using the "Find" command, the generated URL contains 2 reverse attributes like "reverse=0&reverse=1"

  69372   Mon Jun 14 18:51:59 2021 Reply Sebastian Schenksebastian.schenk@physik.uni-halle.deBug reportAllV3.1.4Bug Report with CSS includes (was Re: How to format a column in list display?)

Hi Andreas,

the bug you have found was already reported in an earlier issue, together with the same solution you have found.
https://elog.psi.ch/elogs/Forum/69368

Best wishes,
Sebastian

Andreas Luedeke wrote:
[...]

That works like a charm - until I log in to the logbook. Then the include of the CSS in the header is garbled with some "prefix" of random chars:

<link rel="stylesheet" type="text/css" href="elog.css">
<link rel="stylesheet" type="text/css" href="`=T ýpikett.css">

And a quick check in the source code shows some bad code:

L7615: function "show_html_header"

         rsprintf("<link rel=\"stylesheet\" type=\"text/css\" href=\"%s%s\">\n", css_base, css);

Here css_base is a not initialized local variable of the function. In fact the above line is the only reference of that variable char css_base[1000].

The bug is still present in elog-3.1.4-611489b

 

  69378   Mon Jun 28 14:53:44 2021 Reply Sebastian Schenksebastian.schenk@physik.uni-halle.deQuestionLinux3.13Re: Drop attachments here...

I can't confirm this behavoiur. In our instance, every user can use the attachment function of the elog.
Either through "Drag&Drop" or "Browse&Upload" in the entry editor.

What do you mean by "root" user?
The elog can have serveral admin users, but this behaviour is equal for admin and non-admin users.
You should not run the elog server as user "root" of the machine for security reason, but also for issues with file permissions.

Xuan Wu wrote:

The function of "Drop attachments here..." is only for root user? I'd like it could be used by all users.

 

  69380   Tue Jun 29 15:21:06 2021 Reply Sebastian Schenksebastian.schenk@physik.uni-halle.deQuestionLinux3.13Re: Drop attachments here...

In my testings I didn't found this behaviour, but my collegues also reported this issue.
So I searched for the difference between my test setup and the production logbooks.

I believe the "restrict edit = 1" config option may be responsible for this behaviour.
I had the browser console running in the background and "Drag&Drop" send an XHR request,
which failed with the message: "Only user can edit this entry".
This message is tied to the "restrict edit" option as far as I know.
So I tried removing the option and upload via "Drag&Drop" started to work as intended.
This behaviour only occurs for non-admin users, as admin users are not affected by

Can you verify this?
I can verify to get the same error message in this elog forum in the browser console.

Xuan Wu wrote:

I just used my own account to test the "Drag&Drop" function in this forum ,  and it failed.  In our case, we need to upload ten more images into logbook at once, it's more effective to use "Drag&Drop" than "Browse&Upload" feature for "Browse&Upload" only can choose one attachment at once, but "Drag&Drop" can choose several attachments at once. The admin user can use this feature, but non-admin user not in our site. I did run the elog server as  user "root". I'm not sure it is related to the problem.

Sebastian Schenk wrote:

I can't confirm this behavoiur. In our instance, every user can use the attachment function of the elog.
Either through "Drag&Drop" or "Browse&Upload" in the entry editor.

What do you mean by "root" user?
The elog can have serveral admin users, but this behaviour is equal for admin and non-admin users.
You should not run the elog server as user "root" of the machine for security reason, but also for issues with file permissions.

Xuan Wu wrote:

The function of "Drop attachments here..." is only for root user? I'd like it could be used by all users.

 

 

 

  69381   Tue Jun 29 20:13:36 2021 Reply Sebastian Schenksebastian.schenk@physik.uni-halle.deQuestionLinux3.13Re: Drop attachments here...

I could figure out the bug. A fix can be found in this commit.
https://bitbucket.org/merrx/elog/commits/c3e3c4af9666006558aaf26d8f4841800e69f9af

Sebastian Schenk wrote:

In my testings I didn't found this behaviour, but my collegues also reported this issue.
So I searched for the difference between my test setup and the production logbooks.

I believe the "restrict edit = 1" config option may be responsible for this behaviour.
I had the browser console running in the background and "Drag&Drop" send an XHR request,
which failed with the message: "Only user can edit this entry".
This message is tied to the "restrict edit" option as far as I know.
So I tried removing the option and upload via "Drag&Drop" started to work as intended.
This behaviour only occurs for non-admin users, as admin users are not affected by

Can you verify this?
I can verify to get the same error message in this elog forum in the browser console.

Xuan Wu wrote:

I just used my own account to test the "Drag&Drop" function in this forum ,  and it failed.  In our case, we need to upload ten more images into logbook at once, it's more effective to use "Drag&Drop" than "Browse&Upload" feature for "Browse&Upload" only can choose one attachment at once, but "Drag&Drop" can choose several attachments at once. The admin user can use this feature, but non-admin user not in our site. I did run the elog server as  user "root". I'm not sure it is related to the problem.

Sebastian Schenk wrote:

I can't confirm this behavoiur. In our instance, every user can use the attachment function of the elog.
Either through "Drag&Drop" or "Browse&Upload" in the entry editor.

What do you mean by "root" user?
The elog can have serveral admin users, but this behaviour is equal for admin and non-admin users.
You should not run the elog server as user "root" of the machine for security reason, but also for issues with file permissions.

Xuan Wu wrote:

The function of "Drop attachments here..." is only for root user? I'd like it could be used by all users.

 

 

 

 

  69384   Wed Jun 30 13:50:08 2021 Reply Sebastian Schenksebastian.schenk@physik.uni-halle.deQuestionLinux3.13Re: 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.

 

  69412   Mon Nov 15 14:02:42 2021 Reply Sebastian Schenksebastian.schenk@physik.uni-halle.deBug reportWindows3.14Re: Restrict edit time = 0 behavior intended?

Hi Chris,

my old entry was related to the admin options of edit time.
The option "Admin restrict edit time" was implemented later, see ab8b98c

As a workaround you should be able to give "Restrict edit time" a ridiculous high number in the specific logbook, which should overwrite the global.
In the documentation is no rule specified for diabling global settings for specific logbooks, as far as i know.

Best wishes,
Sebastian

 

Chris Körner wrote:

Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?

Chris Körner wrote:

Hi,

I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.

 

 

  69414   Mon Nov 15 17:40:08 2021 Reply Sebastian Schenksebastian.schenk@physik.uni-halle.deQuestionAll3.1.4Re: Shared logbook and elog.cfg file across multiple installations

Hi Anthony,

the elog has a mirroring function, which synchornizes config and logs between multiple instances.
See the bottom section of https://elog.psi.ch/elog/config.html

Best wishes,
Sebastian

Anthony wrote:

Hi,

I'm wondering if it's possible to have a shared logbook and elog.cfg between multiple instances of elog.  Ideally, I'd like to have my logbooks folder and elog.cfg hosted on a nextcloud instance while running the elog service locally.  I've tried this using symlinks and shortcuts on windows with no luck.  I was able to install elog into my mounted nextcloud folder, but this isn't ideal as I would like this to work from multiple computers.

Any ideas or thoughts on how I can do this (if I can actually do this)?

 

ELOG V3.1.5-3fb85fa6