| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68089
|
Mon Aug 17 10:41:22 2015 |
 | Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls | Look for "&subtext=" in the URL
| Philip Leung wrote: |
|
Is there no good way of differentiating search operations from others by URL?
| Philip Leung wrote: |
|
Thanks for the quick response!
It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.
The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.
| Stefan Ritt wrote: |
|
I guess the underlying problem is the long time these requests take and block other users.
I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.
| Philip Leung wrote: |
|
Hello all,
I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.
Does anybody have any suggestions?
Regards,
Philip
|
|
|
|
|
|
68090
|
Mon Aug 17 11:17:37 2015 |
| Philip Leung | philip.leung@cern.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls | This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter
| Stefan Ritt wrote: |
|
Look for "&subtext=" in the URL
| Philip Leung wrote: |
|
Is there no good way of differentiating search operations from others by URL?
| Philip Leung wrote: |
|
Thanks for the quick response!
It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.
The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.
| Stefan Ritt wrote: |
|
I guess the underlying problem is the long time these requests take and block other users.
I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.
| Philip Leung wrote: |
|
Hello all,
I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.
Does anybody have any suggestions?
Regards,
Philip
|
|
|
|
|
|
|
68091
|
Mon Aug 17 11:26:22 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls | For any other filter you need "&<attribute>=", which of course requires the knowlede of all attributes. There is no other "standard" flag in the URL indicating a search.
| Philip Leung wrote: |
|
This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter
| Stefan Ritt wrote: |
|
Look for "&subtext=" in the URL
| Philip Leung wrote: |
|
Is there no good way of differentiating search operations from others by URL?
| Philip Leung wrote: |
|
Thanks for the quick response!
It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.
The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.
| Stefan Ritt wrote: |
|
I guess the underlying problem is the long time these requests take and block other users.
I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.
| Philip Leung wrote: |
|
Hello all,
I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.
Does anybody have any suggestions?
Regards,
Philip
|
|
|
|
|
|
|
|
68092
|
Mon Aug 17 11:28:08 2015 |
| Philip Leung | philip.leung@cern.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls | Would there be a simple way to redirect all URLs BUT the ones which trigger searches?
| Stefan Ritt wrote: |
|
For any other filter you need "&<attribute>=", which of course requires the knowlede of all attributes. There is no other "standard" flag in the URL indicating a search.
| Philip Leung wrote: |
|
This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter
| Stefan Ritt wrote: |
|
Look for "&subtext=" in the URL
| Philip Leung wrote: |
|
Is there no good way of differentiating search operations from others by URL?
| Philip Leung wrote: |
|
Thanks for the quick response!
It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.
The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.
| Stefan Ritt wrote: |
|
I guess the underlying problem is the long time these requests take and block other users.
I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.
| Philip Leung wrote: |
|
Hello all,
I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.
Does anybody have any suggestions?
Regards,
Philip
|
|
|
|
|
|
|
|
|
68093
|
Mon Aug 17 11:36:49 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls | No, no and again: no.
| Philip Leung wrote: |
|
Would there be a simple way to redirect all URLs BUT the ones which trigger searches?
| Stefan Ritt wrote: |
|
For any other filter you need "&<attribute>=", which of course requires the knowlede of all attributes. There is no other "standard" flag in the URL indicating a search.
| Philip Leung wrote: |
|
This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter
| Stefan Ritt wrote: |
|
Look for "&subtext=" in the URL
| Philip Leung wrote: |
|
Is there no good way of differentiating search operations from others by URL?
| Philip Leung wrote: |
|
Thanks for the quick response!
It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.
The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.
| Stefan Ritt wrote: |
|
I guess the underlying problem is the long time these requests take and block other users.
I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.
| Philip Leung wrote: |
|
Hello all,
I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.
Does anybody have any suggestions?
Regards,
Philip
|
|
|
|
|
|
|
|
|
|
68094
|
Mon Aug 17 11:52:54 2015 |
| Philip Leung | philip.leung@cern.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls | Noted. Thank you for your time
| Stefan Ritt wrote: |
|
No, no and again: no.
| Philip Leung wrote: |
|
Would there be a simple way to redirect all URLs BUT the ones which trigger searches?
| Stefan Ritt wrote: |
|
For any other filter you need "&<attribute>=", which of course requires the knowlede of all attributes. There is no other "standard" flag in the URL indicating a search.
| Philip Leung wrote: |
|
This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter
| Stefan Ritt wrote: |
|
Look for "&subtext=" in the URL
| Philip Leung wrote: |
|
Is there no good way of differentiating search operations from others by URL?
| Philip Leung wrote: |
|
Thanks for the quick response!
It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.
The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.
| Stefan Ritt wrote: |
|
I guess the underlying problem is the long time these requests take and block other users.
I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.
| Philip Leung wrote: |
|
Hello all,
I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.
Does anybody have any suggestions?
Regards,
Philip
|
|
|
|
|
|
|
|
|
|
|
68619
|
Thu May 4 17:20:36 2017 |
 | Michal Falowski | michal.falowski@uj.edu.pl | Bug report | Linux | Windows | 2.9.2-245 | MIME-version header duplicated in e-mail messages. | When there are attachments in an entry, logbook is adding additional "MIME-Version" header to e-mail messages.
Spam filter in our university system is mostly giving warnings:
- X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
But sometimes it is not redirecting further the message.
- Remote Server returned '< #5.6.0 smtp; 554 5.6.0 Bounce, id=27666-07 - BAD HEADER>'
In code I noticed there is always "MIME-Version" header added to the message and additionaly it is added again when a file is attached. I think it is not neccessary to add again this header. |
|
68747
|
Tue Feb 27 15:11:23 2018 |
 | KaterKarlo99 | katerkarlo99@gmail.com | Bug report | Linux | Windows | 3.1.3.1 | User passwords not configurable with loacl passwordfile | Hi!
Tryed windows an linux version. On booth the "Register new User" dialog is not displaying a password line.
so what password is used for the new user? Further the user can't change his password, because he didn't know the old one.
And if an admin user trys to change the password of an other user, a error is displyed that the old password of the admin user is
wrong and nothing happens with the password of the non-admin user.
elog console (admin user awrzkrz changes the password of testuser1):
GET /demo/?cmd=Config&config=TestUser1&cfgpage=1&admin=1&cfg_user=TestUser1&active=1&new_user_name=TestUser1&new_full_name=TEST+User&new_user_email=test%40heaven.org&cmd=Change+password HTTP/1.1
Returned 1032 bytes
GET /demo/?config=TestUser1&newpwd=test1234&newpwd2=test1234 HTTP/1.1
Returned 20 bytes
GET /demo/?cmd=Change%20password&config=awrzkrz&fail=1 HTTP/1.1
Returned 1215 bytes
Thanks for help!
|
|