Re: elog client authentication and attachment comment, posted by Stefan Ritt on Fri Apr 7 10:29:49 2006
|
| Yoshio Imai wrote: | | Until revision 1642, it was possible to submit entries to a password-protected logbook using the elog client without supplying authentication information. With revision 1671 this is no longer possible. In principle this is good. However, many of our run control programs use the elog client (via rsh to the elog server computer) to submit automatic entries, which fails now. In order for this mechanism to work again, we would have to change the command-line call in the sources, including now the password in clear text. Since this can be considered a security issue, we would like to avoid it if at all possible. I guess my request would go in the direction of PAM support, but would it be possible to revert to the old behaviour as an option? (If you tell me where in the code to look, we could probably also comment out the respective lines ourselves so that you don't have extra work...) |
There was a quite strong request to not allow unauthorized access via the elog utility. People were also able to submit entries with the "curl" program without supplying authorization. So I rather would not like to go back to the old version. But I would propose a different scheme: We could save the username/password in a file on the server, which is maybe readable only by the owner. Then one could call elog with
elog ... -u @filename
so that the user name and password gets retrieved from the file on the server. This way the password does not have to be passwd over the network. BTW, you also could use ssh instead of rsh to prevent password being sent over the network in plain text.
| Quote: |
The second remark is about attachment comments. When editing a logbook entry, the attachment upload buttons appear again, but without the comment. Shouldn't it be there, too? |
I'll have a look and fix it. |
|
Re: elog client authentication and attachment comment, posted by Yoshio Imai on Mon Apr 10 20:08:02 2006
|
| Stefan Ritt wrote: | | We could save the username/password in a file on the server, which is maybe readable only by the owner. |
I have discussed it with the others, and it sounds like a good idea. There is only the debate whether it should be readable by the owner or by the root user of the elog server. I can't tell at the moment which is more favourable ... |
|
Re: MOptions problem ?, posted by Alex H on Tue Feb 28 11:26:22 2006
|
> Hi Holger,
>
> > Which ELOG version do you use?
> I'am using the version V2.6.1-1653 of Elog
>
> > From which logbook are the screenshots? (I assume it's Liste - right?)
> Right :)!
>
> I've just seen that Stefan has build a V2.6.1-1663 version of ELOG.
> I try to install this new version and gave you answer as soon as possible :)!
Now I'am using the Elog V2.6.1-1668 and same probleme.
I think it's a data problem. I have edited my logbooks\Liste\050302a.log with an Hexadecimal editor and found one
carruage return juste before the |
[SOLVED] Re: MOptions problem ?, posted by Alex H on Tue Feb 28 12:08:42 2006 
|
Yop,
I think I found the solution! I was in fact a conditions conflict!
See the attached picture for easiest comprehension.
My list box type's conditions (FWL1{1}, FWL2{2}, FWL4{3}, VPN1{4}, VPN2{5}, CLIVPN-PROC{6}) conflict with my Equipment's conditions. It seems that the condition ID must be unique across the whole elogd.cfg.
So I have replaced my "Options Type = FWL1{1}, FWL2{2}, FWL4{3}, VPN1{4}, VPN2{5}, CLIVPN-PROC{6}"
by : "Options Type = FWL1{101}, FWL2{102}, FWL4{103}, VPN1{104}, VPN2{105}, CLIVPN-PROC"
and it works well  ! |
|
[SOLVED] Re: MOptions problem ?, posted by Stefan Ritt on Wed Mar 1 07:48:11 2006
|
| Alex H wrote: | | It seems that the condition ID must be unique across the whole elogd.cfg. |
Right. Here is a quote from the Manual:
| ELOG Manual wrote: | | The only requiremnt is that conditions are unique, meaning that a condition in one option list cannot be used in another list. |
So just read the manual  |
require smileys to have whitespace on either side?, posted by Glenn Horton-Smith on Sat Mar 4 05:17:14 2006
|
It would be nice if elog would only interpret something as a smiley if it is surrounded by whitespace. It can be particularly annoying that an 8 followed by a right paren becomes a "cool" smiley -- e.g., a parenthetical reference to event eighteen (18) becomes mangled... [That was "18" inside the parens.]
Is there already a way to solve this issue (other than always previewing your entries and adding spaces before parans)? Is the feature hard to implement? |
|
Re: require smileys to have whitespace on either side?, posted by Stefan Ritt on Mon Mar 6 13:50:07 2006
|
| Glenn Horton-Smith wrote: | It would be nice if elog would only interpret something as a smiley if it is surrounded by whitespace. It can be particularly annoying that an 8 followed by a right paren becomes a "cool" smiley -- e.g., a parenthetical reference to event eighteen (18) becomes mangled... [That was "18" inside the parens.]
Is there already a way to solve this issue (other than always previewing your entries and adding spaces before parans)? Is the feature hard to implement? |
Interpreting smileys only if they are surrounded by whitespace does not solve the problem completely. It will solve it for (1\8), but not if you have (1, \8) (1, 9) in your text. So it's not a good solution. If you have problems with simleys, I would post my text in plain mode, or surround your numbers with [code]...[/code] tags. If you write
[code](1\8)[/code]
then it will look like
(18)
which should be fine. |
|
Provide option to require smileys to be bracketed a la ELCode?, posted by Glenn Horton-Smith on Mon Mar 6 20:51:57 2006
|
| Stefan Ritt wrote: |
| Glenn Horton-Smith wrote: | It would be nice if elog would only interpret something as a smiley if it is surrounded by whitespace. It can be particularly annoying that an 8 followed by a right paren becomes a "cool" smiley -- e.g., a parenthetical reference to event eighteen (18) becomes mangled... [That was "18" inside the parens.] ...
|
Interpreting smileys only if they are surrounded by whitespace does not solve the problem completely. It will solve it for (1\8), but not if you have (1, \8) (1, 9) in your text. So it's not a good solution. If you have problems with simleys, I would post my text in plain mode, or surround your numbers with [code]...[/code] tags...
|
Hmm, you're right. But I like EL Code, and I don't want to give it up just because of the smileys! A better solution would be to provide an option, which when set, would require smileys to be in brackets, e.g., [\8)] would become the cool smiley [8)], rendered without surrounding brackets if the option was set.
I actually just spent some time I didn't really have and modified my copy of elogd to see if it could be done and would work as intended. Eureka, it works! The modification implements an option "use bracketed smileys" which, if set to 1, causes the editor smiley bar to insert smileys with the square brackets around them and causes rsputs_elcode() to only substitute for smileys if there are square brackets around them, suppressing the square brackets.
I like this feature. Maybe others would like it too. I have a patch file (diff -cbw) w.r.t. svn version 1663 if you're interested. |
|