| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69272
|
Wed Dec 2 22:45:16 2020 |
 | Harry Martin | harrymartin772@gmail.com | Question | Linux | Windows | Mac OSX | All | Other | 3.1.3 | length of condition names | The documentation describing the use of conditionals uses a single character (letter or number) for names of conditions. I don't see any update/change to that rule anywhere in the docs.
I have been using multi-character condition names successfully. I find these are easier to use since they can be more descriptive of each condition. It works, but I am concerned I may be doing something that might not be supported going forward. (It is simple enough to change these, but I'd prefer to know if this practice is acceptable.)
Thank you, again, for this fine (and, may I add, fun?) tool. I'm having a good time with it! |
|
69273
|
Thu Dec 3 01:51:49 2020 |
 | Harry Martin | harrymartin772@gmail.com | Question | Linux | Windows | 3.1.3 | Re: Options <...> vs ROptions <...> | Same problem here, in version 3.1.3. It would be very nice if this worked.
| Wolfgang Bayer wrote: |
|
According to section "Syntax of elogd.cfg" of the "Administrator's Guide" Options <attribute> = <list> and ROptions <attribute> = <list> should be the same. But there is a litle difference, because choosing an entry of the Options-pull-down menu causes a reload of the entry mask while choosing a ROption-radio-button the entry mask is not reloaded. This causes a problem using conditional attributes. The condition is only paid attention to in case of Options but not in case of ROptions. In my case I would like to use ROption, as it is faster to set a radio button than to choose an item in a pull-down menu, but I can't as I have also to use conditional attributes. Is there any solution?
|
|
|
69275
|
Thu Dec 3 09:57:20 2020 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | Mac OSX | All | Other | 3.1.3 | Re: length of condition names | You can easily use multi-character conditionals, up to 256 chars.
| Harry Martin wrote: |
|
The documentation describing the use of conditionals uses a single character (letter or number) for names of conditions. I don't see any update/change to that rule anywhere in the docs.
I have been using multi-character condition names successfully. I find these are easier to use since they can be more descriptive of each condition. It works, but I am concerned I may be doing something that might not be supported going forward. (It is simple enough to change these, but I'd prefer to know if this practice is acceptable.)
Thank you, again, for this fine (and, may I add, fun?) tool. I'm having a good time with it!
|
|
|
69276
|
Thu Dec 3 09:58:44 2020 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | 3.1.3 | Re: Options <...> vs ROptions <...> | For conditional attributes, you have to use Options, not ROptions. Maybe I will implement that one day, but only if I will have plenty of time...
| Harry Martin wrote: |
|
Same problem here, in version 3.1.3. It would be very nice if this worked.
| Wolfgang Bayer wrote: |
|
According to section "Syntax of elogd.cfg" of the "Administrator's Guide" Options <attribute> = <list> and ROptions <attribute> = <list> should be the same. But there is a litle difference, because choosing an entry of the Options-pull-down menu causes a reload of the entry mask while choosing a ROption-radio-button the entry mask is not reloaded. This causes a problem using conditional attributes. The condition is only paid attention to in case of Options but not in case of ROptions. In my case I would like to use ROption, as it is faster to set a radio button than to choose an item in a pull-down menu, but I can't as I have also to use conditional attributes. Is there any solution?
|
|
|
|
69279
|
Fri Dec 4 02:03:56 2020 |
| Harry Martin | harrymartin772@gmail.com | Question | Linux | Windows | Mac OSX | All | Other | 3.1.3 | Re: length of condition names | Could we update the doc for this?
| Stefan Ritt wrote: |
|
You can easily use multi-character conditionals, up to 256 chars.
| Harry Martin wrote: |
|
The documentation describing the use of conditionals uses a single character (letter or number) for names of conditions. I don't see any update/change to that rule anywhere in the docs.
I have been using multi-character condition names successfully. I find these are easier to use since they can be more descriptive of each condition. It works, but I am concerned I may be doing something that might not be supported going forward. (It is simple enough to change these, but I'd prefer to know if this practice is acceptable.)
Thank you, again, for this fine (and, may I add, fun?) tool. I'm having a good time with it!
|
|
|
|
69284
|
Fri Dec 18 18:08:54 2020 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Request | Other | 3.1.3 | outdated debian package | Hi everyone,
I am currently trying to setup elog as a docker container. I wonder if there is any reason why the elog debian package is stuck at version 3.1.3? Would it be possible to update it to the latest version?
Thanks very much! |
|
69285
|
Thu Dec 31 18:35:19 2020 |
| prinnydood | moltensolderlabs@pm.me | Bug report | Linux | 3.1.3 | Re: Path disclosure on unfound file | I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.
The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.
This is what I found:
1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish
2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd
3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path
4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.
Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).
=====
My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.
====
What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.
(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point). |
|
69288
|
Fri Jan 8 13:47:14 2021 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.3 | Re: Path disclosure on unfound file | Ok, I fixed the code in the current commit (395e101add19f0fe8a11a25d0822e511f34d94d1). The path gets stripped, and we see a
| prinnydood wrote: |
|
I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.
The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.
This is what I found:
1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish
2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd
3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path
4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.
Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).
=====
My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.
====
What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.
(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point).
|
|
|