Re: svn commit: r1569108 - /httpd/httpd/branches/2.4.x/STATUS
On 2/17/2014 1:11 PM, Mike Rumph wrote: Hello Jim, I voted for this change for backport to 2.4.8. The fix looks solid to me at this time. But I do have a couple of questions/ideas for the future. 1) proxy_schemes_t in modules/proxy/proxy_util.c and schemes_t in apr-util/uri/apr_uri.c are identical in structure and field names. Could this be pulled to apr-util/include/apr_util.h in future releases of apr-util? I meant apr-util/include/apr_uri.h 2) Could mod_proxy_wstunnel.c benefit from a similar change as this fix does for mod_proxy_http.c? Thanks, Mike Rumph On 2/17/2014 12:42 PM, mru...@apache.org wrote: Author: mrumph Date: Mon Feb 17 20:42:15 2014 New Revision: 1569108 URL: http://svn.apache.org/r1569108 Log: Vote for mod_proxy fix. 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=1569108&r1=1569107&r2=1569108&view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Mon Feb 17 20:42:15 2014 @@ -98,6 +98,14 @@ RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] + * mod_proxy: Use consistent canon formats for http, ajp and fcgi (if provided +port is the default port, don't add to canon URI). Ensures that ajp and +fcgi uses the defined workers and not the default generic reverse proxy +worker. +trunk patch: https://svn.apache.org/viewvc?view=revision&revision=1542562 +2.4.x patch: http://people.apache.org/~jim/patches/proxy-port-scheme.patch ++1: jim, druggeri, mrumph + PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ New proposals should be added at the end of the list ] @@ -114,20 +122,11 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: without mod_request and mod_session present would cause the very same failure. Would a warning in the release notes be good enough? - * mod_proxy: Use consistent canon formats for http, ajp and fcgi (if provided -port is the default port, don't add to canon URI). Ensures that ajp and -fcgi uses the defined workers and not the default generic reverse proxy -worker. -trunk patch: https://svn.apache.org/viewvc?view=revision&revision=1542562 -2.4.x patch: http://people.apache.org/~jim/patches/proxy-port-scheme.patch -+1: jim, druggeri - * prefork: PR: 54852. Only use a dummy_connection for idle processes trunk patch: http://svn.apache.org/viewvc?view=revision&revision=1542379 2.4.x patch: trunk patch works mod CHANGES +1: jim, covener - * FreeBSD: Disable IPv4-mapped listening sockets by default for versions 5+ instead of just for FreeBSD 5. PR 53824. trunk patch: http://svn.apache.org/r1551685
Re: how to use authn_provider for password-less authentication within a module ?
> In particular, the authn_provider struct doesn't seem well-suited to > non-password-based authentication mechanisms. Should I avoid that part > of the framework altogether, not call ap_register_auth_provider at all, > and just manually set r->user via ap_hook_check_authn(), or should I be > thinking about this a different way? > That is the conclusion I came to for a similar mod. I use an alternate proprietary SSL module and do not like fakebasic or SSLUsername: https://github.com/covener/apache-modules/blob/master/mod_authn_cert.c This relies on ssl_var_lookup via the expression parser. Hopefully mod_gnutls implements these ssl optional functions.
Re: svn commit: r1569108 - /httpd/httpd/branches/2.4.x/STATUS
Hello Jim, I voted for this change for backport to 2.4.8. The fix looks solid to me at this time. But I do have a couple of questions/ideas for the future. 1) proxy_schemes_t in modules/proxy/proxy_util.c and schemes_t in apr-util/uri/apr_uri.c are identical in structure and field names. Could this be pulled to apr-util/include/apr_util.h in future releases of apr-util? 2) Could mod_proxy_wstunnel.c benefit from a similar change as this fix does for mod_proxy_http.c? Thanks, Mike Rumph On 2/17/2014 12:42 PM, mru...@apache.org wrote: Author: mrumph Date: Mon Feb 17 20:42:15 2014 New Revision: 1569108 URL: http://svn.apache.org/r1569108 Log: Vote for mod_proxy fix. 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=1569108&r1=1569107&r2=1569108&view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Mon Feb 17 20:42:15 2014 @@ -98,6 +98,14 @@ RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] + * mod_proxy: Use consistent canon formats for http, ajp and fcgi (if provided +port is the default port, don't add to canon URI). Ensures that ajp and +fcgi uses the defined workers and not the default generic reverse proxy +worker. +trunk patch: https://svn.apache.org/viewvc?view=revision&revision=1542562 +2.4.x patch: http://people.apache.org/~jim/patches/proxy-port-scheme.patch ++1: jim, druggeri, mrumph + PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ New proposals should be added at the end of the list ] @@ -114,20 +122,11 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: without mod_request and mod_session present would cause the very same failure. Would a warning in the release notes be good enough? - * mod_proxy: Use consistent canon formats for http, ajp and fcgi (if provided -port is the default port, don't add to canon URI). Ensures that ajp and -fcgi uses the defined workers and not the default generic reverse proxy -worker. -trunk patch: https://svn.apache.org/viewvc?view=revision&revision=1542562 -2.4.x patch: http://people.apache.org/~jim/patches/proxy-port-scheme.patch -+1: jim, druggeri - * prefork: PR: 54852. Only use a dummy_connection for idle processes trunk patch: http://svn.apache.org/viewvc?view=revision&revision=1542379 2.4.x patch: trunk patch works mod CHANGES +1: jim, covener - * FreeBSD: Disable IPv4-mapped listening sockets by default for versions 5+ instead of just for FreeBSD 5. PR 53824. trunk patch: http://svn.apache.org/r1551685
how to use authn_provider for password-less authentication within a module ?
Hi, i'm trying to revive mod_gnutls and bring it up to date with current
apache module practices, and i'd like to use apache 2.4's mod_auth
framework for user authentication via client-side certificates. i'm
limiting the scope of this question to authentication because i do not
have a good use case for mod_gnutls for authorization at this point.
It seems like mod_gnutls should use:
ap_register_auth_provider(p, AUTHN_PROVIDER_GROUP, …)
but it's not clear how it should be done.
In particular, the authn_provider struct doesn't seem well-suited to
non-password-based authentication mechanisms. Should I avoid that part
of the framework altogether, not call ap_register_auth_provider at all,
and just manually set r->user via ap_hook_check_authn(), or should I be
thinking about this a different way?
Looking at the codebase, it looks to me like the authn_provider makes
some basic assumptions that an authentication provider will verify a
username and a password against some source. This doesn't make sense in
the context of client-certificate-based authentication. There are other
contexts in which a module could provide authentication (verifying a
given identity, or associating an identity with a given request) without
doing the sort of password authentication that the authn_provider struct
seems to assume.
include/mod_auth.h has:
--
typedef enum {
AUTH_DENIED,
AUTH_GRANTED,
AUTH_USER_FOUND,
AUTH_USER_NOT_FOUND,
AUTH_GENERAL_ERROR
} authn_status;
/* [...] */
typedef struct {
/* Given a username and password, expected to return AUTH_GRANTED
* if we can validate this user/password combination.
*/
authn_status (*check_password)(request_rec *r, const char *user,
const char *password);
/* Given a user and realm, expected to return AUTH_USER_FOUND if we
* can find a md5 hash of 'user:realm:password'
*/
authn_status (*get_realm_hash)(request_rec *r, const char *user,
const char *realm, char **rethash);
} authn_provider;
--
Any recommendations for how to best think about password-less
AUTHN_PROVIDER_GROUPs, or pointers to documentation that should clear it
up would be welcome.
Regards,
--dkg
pgpbZBWSVNE_1.pgp
Description: PGP signature
Re: Welcome to Mike Rumph and Yann Ylavic!
On 2/17/2014 11:28 AM, Daniel Gruno wrote: > Welcome aboard, and well deserved!! > > With regards, > Daniel. welcome++ (from another Daniel) See you in Denver
Re: Welcome to Mike Rumph and Yann Ylavic!
Hello team, thank you very much for your consideration. Let's keep up the good work! Best regards, Yann. On Mon, Feb 17, 2014 at 6:26 PM, Eric Covener wrote: > Mike Rumph and Yann Ylavic have recently joined us as committers. > > Welcome! > > (We don't usually send this welcome e-mail to dev@, but I think it's a > good thing to do).
Re: Welcome to Mike Rumph and Yann Ylavic!
Hello all, Thanks for the welcome! I look forward to working with all of you towards an even better Apache HTTP Server. See you in Denver, Mike Rumph On 2/17/2014 9:28 AM, Daniel Gruno wrote: On 02/17/2014 06:26 PM, Eric Covener wrote: Mike Rumph and Yann Ylavic have recently joined us as committers. Welcome! (We don't usually send this welcome e-mail to dev@, but I think it's a good thing to do). Welcome aboard, and well deserved!! With regards, Daniel.
Re: Welcome to Mike Rumph and Yann Ylavic!
On 02/17/2014 06:26 PM, Eric Covener wrote: > Mike Rumph and Yann Ylavic have recently joined us as committers. > > Welcome! > > (We don't usually send this welcome e-mail to dev@, but I think it's a > good thing to do). > Welcome aboard, and well deserved!! With regards, Daniel.
Welcome to Mike Rumph and Yann Ylavic!
Mike Rumph and Yann Ylavic have recently joined us as committers. Welcome! (We don't usually send this welcome e-mail to dev@, but I think it's a good thing to do).
Re: Building 2.4.7 on Windows
On 17 February 2014 14:48, Jeff Trawick wrote: > On Feb 17, 2014 9:18 AM, "Steve Hay" wrote: >> >> I'm trying to build 2.4.7 on Windows with VC++ 2010 but have run into >> a problem building mod_proxy_fcgi.so. >> >> I'm following the same process as I previously used with success for >> 2.4.6: build pcre, apr and apr-util (the latter two from the -deps >> archive), then httpd itself (using Jeff Trawick's >> http://people.apache.org/~trawick/cmake-for-steve.zip, which he kindly >> put together for me for building 2.4.6) -- all using cmake. It gets as >> far as mod_proxy_fcgi.so and then fails with unresolved symbols when >> linking. >> >> Do the cmake overlays need updating for 2.4.7 and/or is this a separate >> problem? > > Hi Steve, > > httpd 2.4.7 and the latest 1.5.x versions of apr and apr-util have cmake > support OOTB, so throw that old set of overlays away and let me/us know how > it goes. > > Thanks! Excellent! That's fixed it. Thank you! > > >> >> (It would be great if httpd built out of the box using VC++ rather >> than needing some special attention to make it work, btw.) ... And now it does :-) >> >> Scanning dependencies of target mod_proxy_fcgi >> [ 80%] Building C object >> CMakeFiles/mod_proxy_fcgi.dir/modules/proxy/mod_proxy_fcgi.c.obj >> mod_proxy_fcgi.c >> [ 81%] Building RC object >> CMakeFiles/mod_proxy_fcgi.dir/build/win32/httpd.rc.res >> >> Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385 >> Copyright (C) Microsoft Corporation. All rights reserved. >> >> Linking C shared library mod_proxy_fcgi.so >>Creating library mod_proxy_fcgi.lib and object mod_proxy_fcgi.exp >> mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol >> __imp__ap_fcgi_begin_request_body_to_array@8 referenced in function >> _send_begin_request >> mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol >> __imp__ap_fcgi_header_to_array@8 referenced in function >> _send_begin_request >> mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol >> __imp__ap_fcgi_fill_in_request_body@12 referenced in function >> _send_begin_request >> mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol >> __imp__ap_fcgi_fill_in_header@20 referenced in function >> _send_begin_request >> mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol >> __imp__ap_fcgi_encode_env@20 referenced in function _send_environment >> mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol >> __imp__ap_fcgi_encoded_env_len@12 referenced in function >> _send_environment >> mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol >> __imp__ap_fcgi_header_fields_from_array@24 referenced in function >> _dispatch >> mod_proxy_fcgi.so : fatal error LNK1120: 7 unresolved externals >> LINK Pass 1 failed. with 1120 >> NMAKE : fatal error U1077: 'C:\Dev\Software\cmake\bin\cmake.exe' : >> return code '0x' >> Stop. >> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual >> Studio 10.0\VC\BIN\nmake.exe"' : return code '0x2' >> Stop. >> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual >> Studio 10.0\VC\BIN\nmake.exe"' : return code '0x2' >> Stop.
Re: Building 2.4.7 on Windows
On Feb 17, 2014 9:18 AM, "Steve Hay" wrote: > > I'm trying to build 2.4.7 on Windows with VC++ 2010 but have run into > a problem building mod_proxy_fcgi.so. > > I'm following the same process as I previously used with success for > 2.4.6: build pcre, apr and apr-util (the latter two from the -deps > archive), then httpd itself (using Jeff Trawick's > http://people.apache.org/~trawick/cmake-for-steve.zip, which he kindly > put together for me for building 2.4.6) -- all using cmake. It gets as > far as mod_proxy_fcgi.so and then fails with unresolved symbols when > linking. > > Do the cmake overlays need updating for 2.4.7 and/or is this a separate problem? Hi Steve, httpd 2.4.7 and the latest 1.5.x versions of apr and apr-util have cmake support OOTB, so throw that old set of overlays away and let me/us know how it goes. Thanks! > > (It would be great if httpd built out of the box using VC++ rather > than needing some special attention to make it work, btw.) > > Scanning dependencies of target mod_proxy_fcgi > [ 80%] Building C object > CMakeFiles/mod_proxy_fcgi.dir/modules/proxy/mod_proxy_fcgi.c.obj > mod_proxy_fcgi.c > [ 81%] Building RC object CMakeFiles/mod_proxy_fcgi.dir/build/win32/httpd.rc.res > > Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385 > Copyright (C) Microsoft Corporation. All rights reserved. > > Linking C shared library mod_proxy_fcgi.so >Creating library mod_proxy_fcgi.lib and object mod_proxy_fcgi.exp > mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol > __imp__ap_fcgi_begin_request_body_to_array@8 referenced in function > _send_begin_request > mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol > __imp__ap_fcgi_header_to_array@8 referenced in function > _send_begin_request > mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol > __imp__ap_fcgi_fill_in_request_body@12 referenced in function > _send_begin_request > mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol > __imp__ap_fcgi_fill_in_header@20 referenced in function > _send_begin_request > mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol > __imp__ap_fcgi_encode_env@20 referenced in function _send_environment > mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol > __imp__ap_fcgi_encoded_env_len@12 referenced in function > _send_environment > mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol > __imp__ap_fcgi_header_fields_from_array@24 referenced in function > _dispatch > mod_proxy_fcgi.so : fatal error LNK1120: 7 unresolved externals > LINK Pass 1 failed. with 1120 > NMAKE : fatal error U1077: 'C:\Dev\Software\cmake\bin\cmake.exe' : > return code '0x' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio 10.0\VC\BIN\nmake.exe"' : return code '0x2' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio 10.0\VC\BIN\nmake.exe"' : return code '0x2' > Stop.
Building 2.4.7 on Windows
I'm trying to build 2.4.7 on Windows with VC++ 2010 but have run into a problem building mod_proxy_fcgi.so. I'm following the same process as I previously used with success for 2.4.6: build pcre, apr and apr-util (the latter two from the -deps archive), then httpd itself (using Jeff Trawick's http://people.apache.org/~trawick/cmake-for-steve.zip, which he kindly put together for me for building 2.4.6) -- all using cmake. It gets as far as mod_proxy_fcgi.so and then fails with unresolved symbols when linking. Do the cmake overlays need updating for 2.4.7 and/or is this a separate problem? (It would be great if httpd built out of the box using VC++ rather than needing some special attention to make it work, btw.) Scanning dependencies of target mod_proxy_fcgi [ 80%] Building C object CMakeFiles/mod_proxy_fcgi.dir/modules/proxy/mod_proxy_fcgi.c.obj mod_proxy_fcgi.c [ 81%] Building RC object CMakeFiles/mod_proxy_fcgi.dir/build/win32/httpd.rc.res Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385 Copyright (C) Microsoft Corporation. All rights reserved. Linking C shared library mod_proxy_fcgi.so Creating library mod_proxy_fcgi.lib and object mod_proxy_fcgi.exp mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol __imp__ap_fcgi_begin_request_body_to_array@8 referenced in function _send_begin_request mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol __imp__ap_fcgi_header_to_array@8 referenced in function _send_begin_request mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol __imp__ap_fcgi_fill_in_request_body@12 referenced in function _send_begin_request mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol __imp__ap_fcgi_fill_in_header@20 referenced in function _send_begin_request mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol __imp__ap_fcgi_encode_env@20 referenced in function _send_environment mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol __imp__ap_fcgi_encoded_env_len@12 referenced in function _send_environment mod_proxy_fcgi.c.obj : error LNK2019: unresolved external symbol __imp__ap_fcgi_header_fields_from_array@24 referenced in function _dispatch mod_proxy_fcgi.so : fatal error LNK1120: 7 unresolved externals LINK Pass 1 failed. with 1120 NMAKE : fatal error U1077: 'C:\Dev\Software\cmake\bin\cmake.exe' : return code '0x' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.exe"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.exe"' : return code '0x2' Stop.
