On Fri, Aug 2, 2013 at 8:24 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
The modules in your examples deliberately use the authz mechanism to
generate different output based on the results. But what is doing it in the
case I describe -- where the generated content is exactly the same?
Am Freitag, 2. August 2013, 23:05:09 schrieb Ben Reser:
If all of your authz/authn providers are using the CONF flag and
you're getting duplicated authz processing for subrequests that have
the same conf applied to them then it's possible there's a bug
here. I haven't ever specifically looked
03.08.2013 02:05, Ben Reser wrote:
You don't seriously expect the auth system to know all of those intricacies?
Let me take a step back here. What I found about my particular situation
is -- using your own term -- absurd:
1. The current behavior is not documented.
2. The current behavior is
On Sat, Aug 3, 2013 at 1:41 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
03.08.2013 02:05, Ben Reser wrote:
You don't seriously expect the auth system to know all of those intricacies?
Let me take a step back here. What I found about my particular situation is
-- using your own term --
03.08.2013 14:14, Eric Covener wrote:
I don't agree re: necessity. As Ben said, httpd only knows that /tiv
(where you tried to punch a hole) and the target of your Action
directive have different per-directory configurations, so
authorization is checked on the subrequest. It's erring on the
On Sat, Aug 3, 2013 at 11:34 AM, Mikhail T. mi+t...@aldan.algebra.com wrote:
Point is, it is erring. I asked Ben for possible use-cases and his two
examples were modules, which use the authorization rules to generate
different content depending on the result. Rather than to decide, whether to
On Sat, Aug 3, 2013 at 2:34 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
03.08.2013 14:14, Eric Covener wrote:
I don't agree re: necessity. As Ben said, httpd only knows that /tiv
(where you tried to punch a hole) and the target of your Action
directive have different per-directory
03.08.2013 15:19, Eric Covener ???(??):
I didn't interpret his response that way. Those are modules that will
create subrequests/internal redirects to new URIs that could have
separate authz applied to them from the original URI -- you can't
assume the server is any less interested in
On Thu, Aug 1, 2013 at 7:54 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
01.08.2013 22:47, Ben Reser написав(ла):
That's not a bug at all. In some cases it may be necessary for
authorization to run for sub-requests.
Could you give an example or two? Thanks,
Sure.
mod_autoindex
02.08.2013 20:17, Ben Reser написав(ла):
mod_autoindex automatically provides a directory listing of files
under a path. However, by default it doesn't display any paths that
you don't have access to, e.g. .htaccess. It does this by issuing
subrequests for those other paths so that authz can
On Wed, Jul 31, 2013 at 8:02 AM, Mikhail T. mi+t...@aldan.algebra.com wrote:
As a minimum, testing the subsequent children of RequireAll after one of
them already responded with denied seems like a bug...
I'm not sure about the AuthMerging but I can say that trying the tiv
expiration is not a
30.07.2013 19:18, I wrote:
authorization result of Require all granted: granted
authorization result of RequireAny: granted
authorization result of AuthMerging Any: granted
authorization result of Require all granted: granted
authorization result of RequireAny: granted
On Thu, Aug 1, 2013 at 6:55 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
The problem -- and I do think, it is a bug -- is that the entire
authorization is invoked not just for the request, but for the internal
subrequests too. So, in my scenario, when I asked for /tiv/, the authz core
made
01.08.2013 22:47, Ben Reser ???(??):
LocationMatch ^(/php-fpm)?/tiv/
Require all granted
DirectoryIndex index.php
/LocationMatch
I'm guessing you're using AP_AUTH_INTERNAL_PER_CONF which should avoid
the 3rd call with the above
30.07.2013 19:27, Tim Bannister ???(??):
The server might be working properly and it's just the documentation that has
fallen short.
As a minimum, testing the subsequent children of RequireAll after one of
them already responded with denied seems like a bug...
-mi
Hello!
I realize, configurations questions aren't meant for this list, but I'm
beginning to suspect a bug...
Here is the configuration:
Location /
AuthTypeform
AuthFormProvidertiv
Session
On 31 Jul 2013, at 00:18, Mikhail T. wrote:
Hello!
I realize, configurations questions aren't meant for this list, but I'm
beginning to suspect a bug...
I'd try the users list first. The server might be working properly and it's
just the documentation that has fallen short.
Tim
--
Tim
17 matches
Mail list logo
