ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
67476
|
Fri Apr 5 10:07:57 2013 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.9.2 | Re: Checking logging before posting |
Daniel Campora wrote: |
Hi there,
Here's a bit of a special scenario. There's no server-side check the user is logged in upon posting, but it rather seems the server relies on the post data sent from the form.
An example of this can be triggered on a write restricted elog, by hitting on New and logging out in another tab. Then posting, from the first tab, will post as if the user was logged on. Hitting back and posting again also works.
Cheers
|
Yes the credentials are stored in the form where you enter your text. This has following reason: In a shared environment (several people sitting around a computer) we want to identify who submits an elog entry, but not bother the person to enter his/her password every few minutes. So in our experiment I set the time-out to 15 min, meaning after 15 minutes of inactivity a user gets logged out. If the user accesses ELOG every ten minutes or so, he/she stays logged in for a whole shift, which is what you want. Now the problem is that one starts an elog entry, waits twenty minutes, then wants to submit it, but you are bought back to the login screen and your entry is gone. Therefore I store the credentials (encrypted) in the form, so that the form can even be submitted after 20 minutes. Users at our lab are pretty happy with this solution.
In fact there is no way you can 100% ensure that the logged in user submits an entry without asking for his/her password during the submit. Even if the time span above is only very short, it still can happen that someone starts an entry, leaves the room, and someone else submits it. So people got used to the good practice not to leave any unfinished elog entry open when they go or leave the browser (to another tab for example). If I would implement to password request during the submit, there would be two problems: 1) Users will heavily complain and 2) I have to store the form data temporary (together with some optional attachments) on the server side, start a password query, and only if that succeeds submit the entry. This is somehow complicated to implement since I cannot use the normal elog database. Then I have to care about dangling entries (like if the password was wrong I should delete the temporary data???) and so on.
I plan for the future a kind of "draft" mode, where entries can be stored as "drafts" (like in most email systems). You get an auto-save every few minutes, and can work on the draft before actually submitting it. In that case your password query could be implemented more easily. But implementing the draft mode needs a change of the database system, so I have to find time to do that.
Best regards,
Stefan |
66429
|
Thu Jul 2 08:36:57 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Windows | 2.7.6-2227 | Re: Checks on datetime seconds field generate warning in IE7 |
Richard Stamper wrote: |
When adding a log entry containing a datetime field using the IE7 browser a Javascript warning is displayed - see the attachment. This is due to a change in the naming of the "seconds" field of a datetime entry (made in version 2143) not being propagated to the code that generates the Javascript that checks the supplied values.
Suggested patch follows.
Change "s%d" to "c%d" in lines 9675 and 9678.
Showing lines 9675-9680 below, change from:
rsprintf(" if (document.form1.s%d.value == \"\") {\n", i);
sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
rsprintf(" alert(\"%s\");\n", str);
rsprintf(" document.form1.s%d.focus();\n", i);
rsprintf(" return false;\n");
rsprintf(" }\n");
to:
rsprintf(" if (document.form1.c%d.value == \"\") {\n", i);
sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
rsprintf(" alert(\"%s\");\n", str);
rsprintf(" document.form1.c%d.focus();\n", i);
rsprintf(" return false;\n");
rsprintf(" }\n");
Regards,
Richard Stamper
|
This is absolutely correct, even the right fix. I put that into the distribution. Thanks a lot. |
67028
|
Fri Mar 18 11:07:50 2011 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.9.0 | Re: Cleaning up attachments |
Louis de Leseleuc wrote: |
I noticed a behavior that might be irritating.
After attaching/uploading files to an entry and before submitting it, one might press 'Back' or close the browser window.
This in effect cancels the entry and sends into oblivion. HOWEVER the attachments and their thumbnail files remain on the server forever.
Would there be a way to either delete attachments after some time if they don't show up in an entry? Or some other magic trick with the browser? My logbook directories are already full of orphan files that I need to seek and destroy.
Also, any thoughts on automatically cleaning up a logbook directory when the damage is done?
Louis
|
Well, this is not so easy. When you leave the browser (via 'Back' or just by closing), it has no way to communicate with the elog server. I could put in some JavaScript, but if people switch off JavaScript there is no way. On the other hand it might be simple to write just a little shell script, which goes through all files on the server and checks if the file name occurs in some elog entry. This can probably be done with some combination of "find" and "grep", but I'm not a shell script expert. |
67031
|
Mon Mar 21 17:42:15 2011 |
| Louis de Leseleuc | louis.deleseleuc@nrc-cnrc.gc.ca | Bug report | Linux | 2.9.0 | Re: Cleaning up attachments |
Stefan Ritt wrote: |
Louis de Leseleuc wrote: |
I noticed a behavior that might be irritating.
After attaching/uploading files to an entry and before submitting it, one might press 'Back' or close the browser window.
This in effect cancels the entry and sends into oblivion. HOWEVER the attachments and their thumbnail files remain on the server forever.
Would there be a way to either delete attachments after some time if they don't show up in an entry? Or some other magic trick with the browser? My logbook directories are already full of orphan files that I need to seek and destroy.
Also, any thoughts on automatically cleaning up a logbook directory when the damage is done?
Louis
|
Well, this is not so easy. When you leave the browser (via 'Back' or just by closing), it has no way to communicate with the elog server. I could put in some JavaScript, but if people switch off JavaScript there is no way. On the other hand it might be simple to write just a little shell script, which goes through all files on the server and checks if the file name occurs in some elog entry. This can probably be done with some combination of "find" and "grep", but I'm not a shell script expert.
|
How about this:
Whenever a new file is uploaded, it would first be stored in a temporary directory. When the entry gets submitted, the files would be moved to the logbook directory and the entry edited accordingly.
Any wrongfully stored file would remain in that temp dir. Starting/restarting the daemon would cleanup that directory. Seems like a simpler approach and does not involve scripting the browser. |
1197
|
Fri Jun 17 22:08:28 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.6.0 | Re: Cloning |
Gerfried Kumbartzki wrote: | The elogd.cfg has a read and write passwd set. Any user can access the logbook, read and write after providing the proper user id and password. |
This might be your problem. Try to temporarily remove the read and write password from you config file, then do the cloning, then put it back. Cloning works with a passowd file, but I haven't tested it with read/write passwords.
Gerfried Kumbartzki wrote: | Beside missing the real stuff everything ends up in the users home directory. I would like it in the general area (/usr/local/elog for instance). |
The cloning works in the current directory. So just go to /usr/local/elog and start "elogd -C ..." from there. Alternatively, copy your whole /usr/local/elog tree to the server manually. The "Synchronize" button then works again only with a password file. You need a "Mirror user = xxx" option in that case. |
1209
|
Wed Jun 22 18:34:18 2005 |
| Gerfried Kumbartzki | kum@physics.rutgers.edu | Question | Linux | 2.6.0 | Re: Cloning | Thank you for the suggestions; I commented the read and write passwd in elogd.cfg out and only then I was able to clone
(elogd -v -C http://laptop:8080) the logbook to the new server.
But this is only part of the story. The logbook on the labtop is owned by the
default user elog and default group elog, that is needed to start up the elogd. Only a user "elog" can do the cloning, unless temporarily the owner ship in /usr/local/elog is changed. I made it work by temporarily changing the owner ship on both machines, did the cloning, changed back to owner elog, started elogd and all was running.
I setup synchronizing and here too it works only if the read passwd in elogd.cfg is commented out.
Sync works fine from the RedHat linux laptop (rpm installed), but crashes the elogd on the alpha Linux machine (compiled from src) most of the time. elogd hast to be restarted and the sync had not finished.
So for now I settled to do the synchronize only from the laptop but have to remove the read passwd each time. That is tolerable but not
convenient.
Here I have another question: My Elog is passwd protected, encrypted passwd in elogd.cfg (read and write). When connecting to the elog the window
pops up asking for a user name and the passwd. I donot remember exactly, what was done to set name and passwd. But I find it "strange" that the user name can be anything as long as the passwd is right to access the ELog.
I think I have to learn more about the whole user and passwd protection schema.
Thanks again
Gerfried |
1214
|
Fri Jun 24 21:24:55 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.6.0 | Re: Cloning |
Gerfried Kumbartzki wrote: | But this is only part of the story. The logbook on the labtop is owned by the
default user elog and default group elog, that is needed to start up the elogd. Only a user "elog" can do the cloning, unless temporarily the owner ship in /usr/local/elog is changed. I made it work by temporarily changing the owner ship on both machines, did the cloning, changed back to owner elog, started elogd and all was running. |
The /usr/local/elog files should be owned by user elog on both machines, and both elogd daemons should be started under user elog. Since only the two elogd daemons communicate with each other during synchronization, that should be fine. Only after the initial cloning (which you presumably do under your own user account), you have to do a "chmod" to change ownership of all files to uid/gid "elog/elog".
Gerfried Kumbartzki wrote: | I setup synchronizing and here too it works only if the read passwd in elogd.cfg is commented out. |
As I said, the read password is not really supported for synchronization. It is there historically, from the times when there was no user level password access. If you use synchronization, you should use that authentication (by putting a "password file = ..." into your config.
Gerfried Kumbartzki wrote: | Here I have another question: My Elog is passwd protected, encrypted passwd in elogd.cfg (read and write). When connecting to the elog the window pops up asking for a user name and the passwd. I donot remember exactly, what was done to set name and passwd. But I find it "strange" that the user name can be anything as long as the passwd is right to access the ELog. I think I have to learn more about the whole user and passwd protection schema. |
If you switch to user level password access, this problem goes away as well.
- Stefan |
66670
|
Tue Jan 12 09:12:28 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Windows | 2.7.8-2280 | Re: Collapse to Last and Quick Filter | > Hello,
> I feel that the filter result could be confusing and unexpected when "COLLAPSE TO LAST" is enabled: you
> filter the first entry but you show the last one. What is filtered doesn't correspond with what is shown (look
> the attached example).
>
> I suggest to implement an option to let the user decide which entry (first or last) should be retrieved for
> filtering (a tentative patch is attached).
>
> Thank you
>
> Gabriele
>
> P.S. A similar behaviour occurs when you sort the logbook: it could appear as not sorted because you sort the
> first entry but the last one is shown.
You are absolutely right. When doing filtering, entries shown or not shown have not much to do with the filter.
Rather than messing around with first and last entries, I decided to break apart threads completely when doing
filtering, so the entries are treated as individual entries, just like what you do when filtering in summary mode.
This gives then consistent filtering results. The modification is done in revision 2282. |
|