ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
655
|
Thu Aug 5 10:49:21 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | | All | all | Login/Logout problem with elog and their solution |
Hi everybody,
several people have reported of strange problems concering the login/logout
behaviour of elog. After editing elogd.cfg, they could not logout any more
from a logbook, or they were not able to log in. Here comes some
explanation. If you are not interested in the details, skip to the last section.
The login parameters (user name and password) are sored in cookies, which of
course have to be enabled for the elog site in your browser. Each cookie can
contain an optionsl "path=..." statement, which defines for which subtree in
the URL the cookie is valid. If you use a "global" password file (one where
the "password file = ..." statement is in the [global] section of
elogd.cfg), the elogd server stores a cookie with path "/", so it will apply
to the whole site and therefore to all underlying lobooks. If your password
file is defined in an individual logbook section, the elogd server stores a
cookie with path "/<logbook>", so that it applies only to the specific logbook.
The problem arises now if one moves the password file statement from the
global section to the logbook section or back. The browser might still have
old cookies, whic can override any newly set cookie.
Long story short conclusion: If you observe this behaviour, just delete all
cookies in your browser and you should be fine. I added some additional code
to version 2.5.4 which catches a few cases but unfortunately not all. |
654
|
Tue Aug 3 20:14:55 2004 |
| Alexandre Camsonne | camsonne@jlab.org | Bug report | Linux | 2.5.2 - 2. | Re: User/Admin privlege question |
Thank you, I misunderstood how the "Guest menu commands" worked I thought I had to specify
a limited set of commands to actually limit guest users.
Thanks again for your wonderful work on this program too.
Regards,
Alexandre
> Ok, now I see your problem. You defined a "Guest menu commands" which explicitly allows
> not-authorized access (that's what it's for). If you only want to allow authorized
> access, remove the "guest menu commands" from the logbook sections and also from the
> [global] section.
>
> Please note that if an option is not preent in a logbook section, it is looked for in
> the [global] section. I see that most of your logbooks have similar settings. Just put
> them into the [global] section, and override it in the logbook section if they are
> different. |
653
|
Tue Aug 3 16:59:36 2004 |
| Drew | drew.card@gmail.com | Bug fix | Linux | Windows | 2.5.3 | Re: speeding up elog : gcc compile optimizations |
> > Is there something else which is making this difficult to do?
>
> Not really, but hsearch() & Co. are not available under Windows, so I have to extract the
> source code from the GNU C libarary or so. Since the last discussion I had lots of other
> topics on my to-do list, such as mirroring and cloning, but the speed issue is getting more
> and more up on the priority list.
Speaking of windows I'd like to note that when I moved my call tracking config from a slow BSD
system (PPro 200Mhz) to a faster windows system (P3 733M) I noted a huge slow down in the
interface. Talking about perhaps 1-2 seconds before to 10-15 seconds after. Using
sysinternals file monitor I see that elogd is hammering each log file in the directory. Not
sure what else is going on. 309 log files - only 1.25Meg.
Anything I can do short of pruning down the files?
[Edit: In both cases above my default view is filtered and sorted - so that I only see things
with a specific status. Taking away the filtering resolves this hit - but does not explain the
speed difference between platforms.]
-D |
652
|
Tue Aug 3 16:34:23 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.5.2 - 2. | Re: User/Admin privlege question |
Ok, now I see your problem. You defined a "Guest menu commands" which explicitly allows
not-authorized access (that's what it's for). If you only want to allow authorized
access, remove the "guest menu commands" from the logbook sections and also from the
[global] section.
Please note that if an option is not preent in a logbook section, it is looked for in
the [global] section. I see that most of your logbooks have similar settings. Just put
them into the [global] section, and override it in the logbook section if they are
different. |
651
|
Tue Aug 3 16:18:45 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.5.4 | Re: curly parenthesis problem {smiley} |
> Everything after curly parenthesis is ignored in attribute entry boxes
> like 'Subject' above
>
> What I typed in the subject line was exatcly this:
>
> 'curly parenthesis problem {abc}'
Just don't use curly brackets (;-)
Nevertheless I fixed it in the current version (see subject) |
650
|
Tue Aug 3 15:44:07 2004 |
| Heiko Scheit | h.scheit@mpi-hd.mpg.de | Bug report | Linux | 2.5.4 | curly parenthesis problem |
Everything after curly parenthesis is ignored in attribute entry boxes
like 'Subject' above
What I typed in the subject line was exatcly this:
'curly parenthesis problem {abc}' |
649
|
Tue Aug 3 14:51:34 2004 |
| Alexandre Camsonne | camsonne@jlab.org | Bug report | Linux | 2.5.2 - 2. | Re: User/Admin privlege question |
The elogd.cfg is attached in the previous message as attachement 3. Sorry it is a
little bit buried between pictures.
The reason I put the picture of the global elogd.cfg is to show that the not logged
user has access to elogd.cfg which is some kind of trouble...
> I just see your [global] part of elogd.cfg, could you send me the complete file?
>
Hi I tried to remove the cookies and it still did not ask for password under 2.5.4.
Has the password file format changed between 2.5.2 and 2.5.3 ?
> What you also could try is to delete all cookies stored in your browser. The way
> cookies are formed changed between 2.5.2 and 2.5.3, so the system could be
> confused by old cookies.
>
> - Stefan |
648
|
Tue Aug 3 13:31:08 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.5.4 | Re: too many <table> tags |
> Couldn't one include the extra <table> tag only when there is really more than
> one attribute per line. All other lines could then be aligned properly.
Sure one can do a lot of things if one has enough time and not tens of other
requests on the wishlist which really concern some functionality and not just
cosmetics. |