Re: Multi Logook Login, posted by Stefan Ritt on Wed May 6 16:03:56 2009
|
| Yoshio Imai wrote: | Hi, Stefan!
| Stefan Ritt wrote: | | If "password file = xxx" is however in each individual logbooks configuration, then you get "path=/<lobook>". You can check that by inspecting your browser's cookies. In that case the login name and password cookies are only sent to the URL for that specific logbook. I have not tested that extensively (different browsers, with/without Apache proxy), but if it works reliably, I will put this into the documentation. |
We had done so on your advice and in principle this works, but our experience has shown one problem:
We have separated our logbooks into different top groups because of the sheer number of them (i.e. experiment logbooks in one top group with logbook groups for the sub-categories, personal analysis logbooks in another top group etc.). Obviously, the experiment logbooks may share the same login, therefore we have put the "password file" statement into that top group's global section (otherwise, we would have to log on to every beamtime logbook individually, which can be cumbersome when comparing e.g. experiment settings between beamtimes). For the personal logbooks, of course, we use per-logbook-access (i.e. "password file" statement in the individual logbook sections) such that logging on to one's own logbook does not imply access to someone else's logbook. However, since the group/top group structure does not appear in the elog URLs, the cookies for the beamtime logbooks all have the path set to "path=/". This breaks the scheme again (I guess we have sort of "abused" the concept of top groups a little) and it is not possible to work in one of the experiment logbooks in parallel with one's own logbook without having to renew the login when switching the logbook.
Is it possible to modify the elogd such that it first checks if, among the cookies sent, there is one where the path corresponds to the path of the current logbook, and evaluate cookies with "path=/" only if no such cookie is found?
Yoshio |
I'm not sure if that helps. As soon as you have top groups, cookies have to use "path=/". I agree it would be best to use URLs in the form "http://<server>/<top group>/<logbook>", but cookies only support one level of directories (at least that was the case when I designed that a few years ago, I'm not sure if that's still the case). The only way around that is to give up top groups and run one elog server for each top group on a different port. |
|
Re: "Forgot Password?" link not working?, posted by Stefan Ritt on Thu May 7 08:05:54 2009
|
| Mike wrote: |
|
Thanks for the fix. I tried out 2197 and when I click the "Forgot Password" link it causes elog to crash. I've attached my cfg file.
|
The problem was the password recovery in conjunction with "Bottom text", thanks for supplying your configuration file. I fixed that in revision 2198. |
|
Re: E-log crash, posted by Stefan Ritt on Thu May 14 17:59:04 2009
|
| soren poulsen wrote: |
|
Hi
I am having a little problem with e-log that I can easily reproduce.
I have defined a number of constraints on my e-log fields and I am testing what happens when the user does not respect them.
So this only happens when I am not observing the input formats or the mandatory fields.
This is the GDB trace. This is not very verbose, so I must learn to use the other tracers, I guess.
Server listening on port 8079 ...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000414077 in is_script (
at src/elogd.c:5414
5414 for (i = 0; script_tags[i][0]; i++) {
(gdb)
Soren
|
It would be best if I could reproduce your problem. So can you start from a very simple configuration file, add your constraints until the problme happens, and then send me the config file? |
|
Re: Mail and logged in user , posted by Stefan Ritt on Mon May 18 12:28:00 2009
|
| Arno Teunisse wrote: |
|
Hello
Was playing with elog. I send mail to the persons involved with a elog entrie. This mail produces something like this ( rather default) .
Logbook: Accelerator Message ID: 4 Entry time: 05/10/09 21:48:25 In reply to: 3
When I am logged in into elog , clicking on the Message ID 4 or 3 from the mail client , elog is started with the logged in user at that time and it's permissions. So instead of starting a new elog session ( and getting the guest permission ) I get the permission of the currently logged in user.( Could be the administrator / root) . The process will function correctly i no one is logged in into elog. I've tested this on a local machine, so I cannot say if the same happens when multiple machines are used. So, maybe it's a bug, maybe it's my testing configuration.
Do not know if i explained the problem clear enough, but is seems something that could be examined.
By the way : thanks for this great and free program.
|
This is not a bug, this is a feature! Once you log in to ELOG, your credentials are stored in cookies of your local browser. If you access a logbook entry, like via the link you in your email, you still use that credentials. If you clear all cookies of your browser, or log out explicitly from ELOG, then of course you will only get guest access. |
|
Re: elogd dies after receiving second SIGHUP, posted by Stefan Ritt on Thu Jun 4 09:49:13 2009
|
> > > elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
> > > This was observed on Solaris 10 (SPARC).
> > > The documentation states that elogd should re-read configuration after receiving SIGHUP.
> >
> > I tried to reproduce this but without success. I could send many SIGHUPs without the daemon terminating. Maybe
> > you modified the configuration file in between and elogd barked out because of some wrong configuration? Try to
> > start the daemon interactively and see what exactly happens if you send several SIGHUPs.
>
> The problem is that under Solaris signal handlers installed via signal() get uninstalled *before* the signal handler
> is called. Thus the second time elogd receives a SIGHUP, you get the default action, which is to kill the process.
>
> The solution is to use the POSIX sigaction() call instead of signal().
Can you try to modify the signal() calls into sigaction(). If this really works under Solaris, I will incorporate this
then into the distribution. |
|
Re: Supress Email to Author of a message?, posted by Stefan Ritt on Thu Jun 4 14:04:21 2009
|
| Mike wrote: |
|
I couldn't find an obvious solution to the problem. I'd like to suppress email
notification to the author of a message. I've had some people complaining
that when they use elog they don't want to get an email about what they wrote
since they wrote it.
Is it possible?
|
Actually I do want to receive a copy, just to be sure that the emails got sent out correctly. I agree that an option would be good for that but it's not implemented right now. An alternative solution is to define a filter in their email client to discard these messages (like if subject contains ELOG and sender equals your own mail address). |
|
Re: E-log crash, posted by Stefan Ritt on Thu Jun 4 14:05:58 2009
|
| soren poulsen wrote: |
|
Hi
I am having a little problem with e-log that I can easily reproduce.
I have defined a number of constraints on my e-log fields and I am testing what happens when the user does not respect them.
So this only happens when I am not observing the input formats or the mandatory fields.
This is the GDB trace. This is not very verbose, so I must learn to use the other tracers, I guess.
Server listening on port 8079 ...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000414077 in is_script (
at src/elogd.c:5414
5414 for (i = 0; script_tags[i][0]; i++) {
(gdb)
Soren
|
I had finally the same problem. This is due to a bug indeed inside is_script(). It has been fixed in revision 2201. |
|
Re: User can modify Fixed Attributes Edit when selecting preview, posted by Stefan Ritt on Thu Jun 4 14:37:54 2009
|
| Allen wrote: |
|
Hi. I'm pretty new to ELOG, so I'm not sure if I'm doing something wrong.
I have a bunch of fields set so that after an entry has been submitted, they cannot edit certain fields. When I click the edit button, everything looks restricted as it should be, but if I click Preview, the user is then able to change the fixed attributes.
Is there anyway to remove the preview button inside the edit page, or is anyone else having this issue?
|
Thanks for reporting this bug. I fixed it in revision #2203. |
|