ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68220
|
Tue Jan 12 21:07:59 2016 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.1 | Re: drag and drop attachments not working with web server authentication |
Have a look here: elog:68014
Devin Bougie wrote: |
Hello, The "Drop attachments here..." section does not work when using Webserver authentication. Both elog 3.1.1 (the binary RPM) and apache are running on EL6.6 and are configured according to the docs. Authentication works fine and the normal "Choose File - Upload" attachment table works fine. However, when dragging an attachment to the "Drop attachments here..." section the dashes on the border turn green but when dropping the attachment nothing happens. If we revert to File authentication, everything works fine. I don't see any errors in our elog or apache log files. Any suggestions would be greatly appreciated. Many thanks, Devin |
|
68221
|
Tue Jan 12 21:13:54 2016 |
| Devin Bougie | devin.bougie@cornell.edu | Bug report | Linux | 3.1.1 | Re: drag and drop attachments not working with web server authentication |
Thanks, Stefan. I read that before asking my question, but didn't see a resolution in that thread. I am already at 3.1.1, and I am testing on a clean installation. Are you saying that the solution is in the development branch after the release of 3.1.1?
Thanks again,
Devin |
68222
|
Tue Jan 12 21:19:25 2016 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.1 | Re: drag and drop attachments not working with web server authentication |
No. What the thread says is first try this forum, see if you can drag and drop here. If not, you have a problem on your browser. If yes, you have somewhere some old JavaScript file around. Might be in the cache of your browser.
Devin Bougie wrote: |
Thanks, Stefan. I read that before asking my question, but didn't see a resolution in that thread. I am already at 3.1.1, and I am testing on a clean installation. Are you saying that the solution is in the development branch after the release of 3.1.1?
Thanks again,
Devin
|
|
68223
|
Tue Jan 12 21:31:42 2016 |
| Devin Bougie | devin.bougie@cornell.edu | Bug report | Linux | 3.1.1 | Re: drag and drop attachments not working with web server authentication |
Yeah, I had tried that and it did work in your demo forum. It just didn't work in mine with authentication = webserver, even with a clean browser profile.
However, after playing with the config and a few restarts, everything now seems to be working properly. Really not sure what changed, but thanks for helping.
Devin |
68225
|
Wed Jan 13 08:37:42 2016 |
| Tamas Gal | tgal@km3net.de | Question | Linux | ELOG V3.1.0-241 | Re: Monitoring a logbook for changes |
I recommend monitoring directly on the server. Here is an example of a very simply Python script (https://github.com/tamasgal/elog-slack) which monitors the files very efficiently and immediately pushes notifications to Slack (slack.com). Just look at the code, it's pretty straight forward and very easy to adapt it to other (web) services.
Btw. here is an ELOG entry of it https://midas.psi.ch/elogs/Forum/68224
Johan Forsberg wrote: |
Hi again!
I've another need that you probably already thought of :)
I'd like to be able to efficiently monitor a logbook for changes (new or edited posts) somehow. The most reasonable way I've found so far is to periodically poll a search that looks for posts after the time of the last poll. But that might note be very efficient, especially if the polling period gets short (or number of clients grows).
Is there some other feature that could be used for this? I was thinking maybe the ETag or Last-Modified HTTP header field could be used to show changes to a logbook by just reading the headers, but it would also require HEAD request support which does not seem to be there.
Cheers,
Johan
|
|
68226
|
Wed Jan 13 10:27:21 2016 |
| Johan Forsberg | johan.forsberg@maxlab.lu.se | Question | Linux | ELOG V3.1.0-241 | Re: Monitoring a logbook for changes |
Yeah, I found the RSS feed feature, but I could not get ETags/Last-Modified header fields which meant that I'd have to read and parse the entire feed every time. Maybe I made a mistake and they do work, but if not, I think it would make sense to implement as it should save work for both the server and the client.
Johan Forsberg wrote: |
Hi again!
I've another need that you probably already thought of :)
I'd like to be able to efficiently monitor a logbook for changes (new or edited posts) somehow. The most reasonable way I've found so far is to periodically poll a search that looks for posts after the time of the last poll. But that might note be very efficient, especially if the polling period gets short (or number of clients grows).
Is there some other feature that could be used for this? I was thinking maybe the ETag or Last-Modified HTTP header field could be used to show changes to a logbook by just reading the headers, but it would also require HEAD request support which does not seem to be there.
Cheers,
Johan
|
|
68227
|
Wed Jan 13 10:29:54 2016 |
| Johan Forsberg | johan.forsberg@maxlab.lu.se | Question | Linux | ELOG V3.1.0-241 | Re: Monitoring a logbook for changes |
Yeah, I suppose something like that would be both faster and more efficient than polling ELOG itself. Fortunately the ELOG disk format looks easily parsed.
Thanks for the pointer!
Tamas Gal wrote: |
I recommend monitoring directly on the server. Here is an example of a very simply Python script (https://github.com/tamasgal/elog-slack) which monitors the files very efficiently and immediately pushes notifications to Slack (slack.com). Just look at the code, it's pretty straight forward and very easy to adapt it to other (web) services.
Btw. here is an ELOG entry of it https://midas.psi.ch/elogs/Forum/68224
Johan Forsberg wrote: |
Hi again!
I've another need that you probably already thought of :)
I'd like to be able to efficiently monitor a logbook for changes (new or edited posts) somehow. The most reasonable way I've found so far is to periodically poll a search that looks for posts after the time of the last poll. But that might note be very efficient, especially if the polling period gets short (or number of clients grows).
Is there some other feature that could be used for this? I was thinking maybe the ETag or Last-Modified HTTP header field could be used to show changes to a logbook by just reading the headers, but it would also require HEAD request support which does not seem to be there.
Cheers,
Johan
|
|
|
68228
|
Wed Jan 13 17:04:34 2016 |
| Tamas Gal | tgal@km3net.de | Question | Linux | ELOG V3.1.0-241 | Re: Monitoring a logbook for changes |
I just noticed that there are multiple messages per file, so I have to adapt the parser. I'll update this thread when I'm done!
Johan Forsberg wrote: |
Yeah, I suppose something like that would be both faster and more efficient than polling ELOG itself. Fortunately the ELOG disk format looks easily parsed.
Thanks for the pointer!
Tamas Gal wrote: |
I recommend monitoring directly on the server. Here is an example of a very simply Python script (https://github.com/tamasgal/elog-slack) which monitors the files very efficiently and immediately pushes notifications to Slack (slack.com). Just look at the code, it's pretty straight forward and very easy to adapt it to other (web) services.
Btw. here is an ELOG entry of it https://midas.psi.ch/elogs/Forum/68224
Johan Forsberg wrote: |
Hi again!
I've another need that you probably already thought of :)
I'd like to be able to efficiently monitor a logbook for changes (new or edited posts) somehow. The most reasonable way I've found so far is to periodically poll a search that looks for posts after the time of the last poll. But that might note be very efficient, especially if the polling period gets short (or number of clients grows).
Is there some other feature that could be used for this? I was thinking maybe the ETag or Last-Modified HTTP header field could be used to show changes to a logbook by just reading the headers, but it would also require HEAD request support which does not seem to be there.
Cheers,
Johan
|
|
|
|