Re: svn commit: r1687642 - /httpd/httpd/trunk/server/protocol.c
IMHO, the core_input_filter() should not return APR_SUCCESS with an
empty brigade when the underlying socket is EOF, APR_EOF would be more
appropriate.
On Thu, Jun 25, 2015 at 10:44 PM, cove...@apache.org wrote:
Author: covener
Date: Thu Jun 25 20:44:42 2015
New Revision: 1687642
URL: http://svn.apache.org/r1687642
Log:
elaborate on a misleading comment
Modified:
httpd/httpd/trunk/server/protocol.c
Modified: httpd/httpd/trunk/server/protocol.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1687642r1=1687641r2=1687642view=diff
==
--- httpd/httpd/trunk/server/protocol.c (original)
+++ httpd/httpd/trunk/server/protocol.c Thu Jun 25 20:44:42 2015
@@ -236,7 +236,9 @@ AP_DECLARE(apr_status_t) ap_rgetline_cor
return rv;
}
-/* Something horribly wrong happened. Someone didn't block! */
+/* Something horribly wrong happened. Someone didn't block!
+ * (this also happens at the end of each kept-alive connection)
+ */
if (APR_BRIGADE_EMPTY(bb)) {
return APR_EGENERAL;
}
Re: svn commit: r1687642 - /httpd/httpd/trunk/server/protocol.c
To be more clear, that's only true for GETLINE or when NONBLOCK_READ
is used, not for READBYTES.
On Thu, Jun 25, 2015 at 11:02 PM, Yann Ylavic ylavic@gmail.com wrote:
IMHO, the core_input_filter() should not return APR_SUCCESS with an
empty brigade when the underlying socket is EOF, APR_EOF would be more
appropriate.
On Thu, Jun 25, 2015 at 10:44 PM, cove...@apache.org wrote:
Author: covener
Date: Thu Jun 25 20:44:42 2015
New Revision: 1687642
URL: http://svn.apache.org/r1687642
Log:
elaborate on a misleading comment
Modified:
httpd/httpd/trunk/server/protocol.c
Modified: httpd/httpd/trunk/server/protocol.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1687642r1=1687641r2=1687642view=diff
==
--- httpd/httpd/trunk/server/protocol.c (original)
+++ httpd/httpd/trunk/server/protocol.c Thu Jun 25 20:44:42 2015
@@ -236,7 +236,9 @@ AP_DECLARE(apr_status_t) ap_rgetline_cor
return rv;
}
-/* Something horribly wrong happened. Someone didn't block! */
+/* Something horribly wrong happened. Someone didn't block!
+ * (this also happens at the end of each kept-alive connection)
+ */
if (APR_BRIGADE_EMPTY(bb)) {
return APR_EGENERAL;
}
mod_auth_fixup -- check authentication, update user's login for subsequent authorization
Hello,
I'd like to ask for feedback about module that I called mod_auth_fixup.
It is available at
https://fedorapeople.org/cgit/adelton/public_git/mod_auth_fixup.git/
and I'd like to know if the Apache HTTP Server team would find
it useful for inclusion in httpd's distribution, and if not, whether
in general people find it as good idea, to be able to post-process
results of (for example) mod_ssl authenticaion, when the user
identifier that you might get is not directly usable for subsequent
authorization operations.
In the future I plan to add a way to retrieve the username from
external identity sources, for example via SSSD as Apache's
counterpart of new feature
https://fedorahosted.org/sssd/ticket/2596
Thank you.
The README of the module:
Apache module mod_auth_fixup
Apache module mod_auth_fixup uses results of previous authentication
and other phases and checks that user was authenticated, optionally
updating the user identifier with a substring based on regular
expression match.
Possible use is processing result of mod_ssl's operation on Apache 2.2.
Module mod_ssl has SSLVerifyClient require mechanism which sets the
user identifier and it is not proper authentication module to the rest
of Apache HTTP Server internals. That makes it hard to combine
mod_ssl with authorization modules to check additional attributes
of the authenticated user.
Module configuration
Let us assume we have mod_ssl configured with client authentication:
Location /login
SSLVerifyClient require
SSLVerifyDepth 1
SSLOptions +StrictRequire
SSLUserName SSL_CLIENT_S_DN_CN
/Location
The access will only be allowed if the client certificate can be
verified by mod_ssl, and the authenticated user identifier will be
the content of client's Subject DN's common name. In access log
we will see the CN value as the user identifier.
Often, there are two issues with that situation:
1) On Apache 2.2, when we try to use the result of such authentication
for example with Require, like
Require group admins
or even plain
Require valid-user
we will get an error:
configuration error: couldn't perform authentication.
AuthType not set!
It's because mod_ssl does not run the standard authentication
handler.
By adding
AuthType Fixup
to the configuration, mod_auth_fixup takes the role of the
authentication handler, even if it does not do anything else than
checking that the result of the mod_ssl operation, the user
identifier it has left in the internal r-user, set.
Of course, any other module could have set the user identification,
not just mod_ssl, and mod_auth_fixup would process it just fine.
2) The Common Name field of the Subject DN is often filled with
structured information, and for the subsequent authorization phase,
only a substring of that might be the actual user identification
in the identity management setup used.
For that, AuthFixupRegexp directive can specify regular expression
to match the user identifier against, and substitution string. When
the user identifier matches, it is the updated with the new value,
and this new value will be then shown in the access log and
available to later authorization phases. So for example,
AuthFixupRegexp userid=(.+?); user$1
will make sure the user identifier contains substring
userid=the-identifier;
and the nonempty string between userid= and the first semicolon
will replace the $1 part in the substitution string. Note that
the first part of the requirement matched by the above
AuthFixupRegexp example could be handled by
SSLRequire %{SSL_CLIENT_S_DN_CN} =~ m/userid=.+?;/
But there is no way to extract the identifier with SSLRequire (and
to add Require to it in Apache 2.2).
When AuthFixupRegexp is not specified, it is effectively equivalent
to
AuthFixupRegexp .+ $0
The full example configuration might then be:
Location /login
SSLVerifyClient require
SSLVerifyDepth 1
SSLOptions +StrictRequire
SSLUserName SSL_CLIENT_S_DN_CN
AuthType Fixup
AuthFixupRegexp userid=(.+?); user$1
Require group admins
/Location
--
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
Re: svn commit: r1684900 - in /httpd/httpd/trunk: CHANGES modules/filters/mod_substitute.c
On Wed, Jun 24, 2015 at 11:09 PM, Eric Covener cove...@gmail.com wrote: SubstituteInheritBefore I chose this one, was the easiest for me to write its doc. Committed in r1687539.
Re: svn commit: r1687564 - /httpd/httpd/branches/2.4.x/STATUS
Just a quick observation on the patch, you know you can use a tristate to avoid an int? Simply set the value to 2 in the config-create (the enum being off=0, on=1, unset=2), check for RHS 'unset' during the merge, and in the feature toggle test, explicitly check test for == of the non-default value. And a style nit, we explicitly put in the variable type for each member, and don't carry the type from member to member in the project's structs/enums. On Thu, Jun 25, 2015 at 10:47 AM, yla...@apache.org wrote: Author: ylavic Date: Thu Jun 25 15:47:39 2015 New Revision: 1687564 URL: http://svn.apache.org/r1687564 Log: Update mod_substitute proposal with SubstituteInheritBefore. Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1687564r1=1687563r2=1687564view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Thu Jun 25 15:47:39 2015 @@ -201,10 +201,17 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: ints added at the end of core_server_config, the proposed merge does a minor bump only. - *) mod_substitute: Fix configuraton merge order. PR 57641 + *) mod_substitute: Configure patterns merge order. PR 57641 trunk patch: http://svn.apache.org/r1684900 - 2.4.x patch: trunk works (modulo CHANGES) - +1: ylavic, minfrin + http://svn.apache.org/r1687539 + 2.4.x patch: http://people.apache.org/~ylavic/httpd-2.4.x-SubstituteInheritBefore.patch + +1: ylavic + ylavic: added r1687539 and discarded minfrin's vote (we must preserve + the current behaviour). SubstituteInheritBefore allows to + configure the merge order; the default is Off in trunk (2.5+), + but still On in 2.4.x thanks to the changes in the backport patch + only (dcfg-inherit_before = 1 by default, and the doc is updated + accordingly). *) core: Avoid a possible truncation of the faulty header included in the HTML response when LimitRequestFieldSize is reached.
Re: Proxy balancer providers and aging
On 6/24/2015 3:12 PM, Jim Jagielski wrote: All LBmethods have an age function which is designed to appropriately age the data so that things even out after awhile. Of course, right now, none actually *uses* that. I had never realized this function exists... what triggers it? ... or are you saying that today nothing triggers it because of the next sentence? But I think the reason is because there is no real good way, currently, in mod_proxy to do that... Well, in the LBmethod I was hacking away on, it really DOES need its age function, and currently it's doing so via mod_watchdog. But the more I think of it, ideally, mod_proxy *itself* should create the watchdog thread and just handle the age itself, rather than having a LBmethod provider having to be responsible for creating that (it also kind of destroys the abstraction that pure providers should have, imo)... Yup - if there is some sort of contract between mod_proxy such that each balancer ought to be able to age its data, mod_proxy should provide the facilities to call that age function on some interval. However, looking at the age function signature in the existing balancers, I'm seeing a conspicuous lack of a time delta since the last call to age(). It seems to me that if mod_proxy is responsible for the 'tick' it should also be responsible for providing a time delta so the lbmethod can age the data proportionally to the time since last tick. (or, maybe I'm missing it altogether and the module should be managing this itself which kinda puts us back to the beginning of which module should be responsible for this stuff) Anyway... anyone opposed to me adding this to mod_proxy in trunk with hope towards it backporting to 2.4? It does mean that mod_proxy will now have a dependency on mod_watchdog. I'm conflicted. This is useful functionality but would break existing configurations using 2.4 in an unexpected way. I remember dealing with lots of questions about why is this slotmem thing needed all of a sudden when moving from 2.2 to 2.4. I think that if I were to be forced to work through the cognitive dissonance I'd be +1 for adding this to trunk but -1 for 2.4 unless we can find a way to avoid the dependency unless the lbmethod really needs it (I don't see how, but please do enlighten me if this is possible). -- Daniel Ruggeri
