[Sat May 24 02:02:51.025715 2014] [:error] [pid 14334] [client ***] ModSecurity: Access denied with code 400 (phase 1). Operator GT matched 512 at ARGS_GET:_uids
such params should be POSt and not GET
affects mailboxes with a lot of messages and seems to be a very new problem with RC 1.0.x
[Sat May 24 02:02:51.025715 2014] [:error] [pid 14334] [client ***] ModSecurity: Access denied with code 400 (phase 1). Operator GT matched 512 at ARGS_GET:_uids
such params should be POSt and not GET
affects mailboxes with a lot of messages and seems to be a very new problem with RC 1.0.x
I think (not 100% sure) UID is passed with the URL to make messages cacheable.
Displaying messages -> Cache messages
On 24 May 2014, at 05:51, Rosali myroundcube@mail4us.net wrote:
[Sat May 24 02:02:51.025715 2014] [:error] [pid 14334] [client ***] ModSecurity: Access denied with code 400 (phase 1). Operator GT matched 512 at ARGS_GET:_uids such params should be POSt and not GET affects mailboxes with a lot of messages and seems to be a very new problem with RC 1.0.x
I think (not 100% sure) UID is passed with the URL to make messages cacheable.
Displaying messages -> Cache messages
That's not the point. The point it why is it a GET and not a POST, and thats a valid question. As a GET you end up with a huge parameter string, which can be mistaken for a hack attempt by things like mod_security. Of course, you could say, well dont run mod_security then, or teach it that this is valid. Which is also a good point.
I guess it depends on how difficult it would be to change. Probably not too bad id guess.
Cor
Am 24.05.2014 09:36, schrieb Cor Bosman:
On 24 May 2014, at 05:51, Rosali myroundcube@mail4us.net wrote:
[Sat May 24 02:02:51.025715 2014] [:error] [pid 14334] [client ***] ModSecurity: Access denied with code 400 (phase 1). Operator GT matched 512 at ARGS_GET:_uids such params should be POSt and not GET affects mailboxes with a lot of messages and seems to be a very new problem with RC 1.0.x
I think (not 100% sure) UID is passed with the URL to make messages cacheable.
Displaying messages -> Cache messages
That's not the point. The point it why is it a GET and not a POST, and thats a valid question. As a GET you end up with a huge parameter string, which can be mistaken for a hack attempt by things like mod_security. Of course, you could say, well dont run mod_security then, or teach it that this is valid. Which is also a good point.
I guess it depends on how difficult it would be to change. Probably not too bad id guess.
sure, i changed the rule now to phase:2 and whitelisted it for roundcube but that is not the point - the point is that we are running RC for years now and before upgrade from 0.9.5 to 1.0.1 i never had that problem
it's technically questionable add kilobytes of params to a URL - that's what POST is for and having 600 domains running on several servers with that ruleset and only one webapplication after an update triggers it speaks for me a clear language where the fix belongs to
On 05/24/2014 11:12 AM, Reindl Harald wrote:
it's technically questionable add kilobytes of params to a URL - that's what POST is for and having 600 domains running on several servers with that ruleset and only one webapplication after an update triggers it speaks for me a clear language where the fix belongs to
It was fixed some time ago, but I forgot to backport the change to release-1.0 branch. Done now.
https://github.com/roundcube/roundcubemail/commit/8b93fc92845d13e17795b9b3a5...
Am 25.05.2014 11:09, schrieb A.L.E.C:
On 05/24/2014 11:12 AM, Reindl Harald wrote:
it's technically questionable add kilobytes of params to a URL - that's what POST is for and having 600 domains running on several servers with that ruleset and only one webapplication after an update triggers it speaks for me a clear language where the fix belongs to
It was fixed some time ago, but I forgot to backport the change to release-1.0 branch. Done now.
https://github.com/roundcube/roundcubemail/commit/8b93fc92845d13e17795b9b3a5...
thank you!
-
A.L.E.C -
Cor Bosman -
Reindl Harald -
Rosali