ap_authn_cache_store call for groups
I was looking into caching of user credentials, but I think I might be missing something. The call ap_authn_cache_store seems to store user credentials which will help, if you have a directive like 'Require valid-user', but it won't help for directives like 'Require group admin'. Am I right? So in case of an authentication module that uses database queries, all subsequent requests will still generate SQL statements for the user/group matching. Which means that only half of the database requests are actually cached. Can someone please elaborate. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
documentation issues for mod_authn_socache
Hello, http://httpd.apache.org/docs/2.4/mod/mod_authn_socache.html There are 2 things I want to mention: 1) cacheing is not a word. It should be replaced with caching on the entire page 2) AuthnCacheSOCache Directive: If not set, your platform's default will be used. There's no indication whatsoever what the platforms' defaults actually are. Can someone please tell me what the platforms' defaults are? I'm mostly interested in Linux and MacOSX, but a list would be nice in the docs. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: ap_authn_cache_store call for groups
On 17.06.15 18:56 , Eric Covener wrote: Sounds right. The authn in the name is shorthand for authentication (vs authorization). It seems possible to shoehorn other data into this cache though, but it's not clear to me what it adds using socache directly. The problem is that I don't know how. I just read the information in the documentation http://webauth.stanford.edu/manual/mod/mod_authn_socache.html how to use it to cache credentials. I wrote my own caching algorithms for my module, but learned that Apache provides this funtionality already. Or at least part of it - as in user caching. That's why I thought of getting rid of my own caching (which caches users and group info) and make use of already available functionality. Why reinvent the wheel? I just can't figure out how to cache group info. My module is an authnz module, but I couldn't find an authz_socache variant. Is there something like that? Are there any examples? Maybe this is off topic here, but I'd appreciate any pointers. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
sni+alpn, vhost+certs
Seems like a good idea to not place the ALPN patches into 2.4 - yet. During my tests, I discovered that the order of my vhost definitions affected the certificate chosen - when ALPN was in play. After some analysis, the following seems to occur. This is to make the mod_ssl people here aware and get their opinion on a workaround. 1. connection, setup for base server and defaults 2. client hello arrives 3. ALPN callback is invoked by openssl 4. ALPN protocol is chosen, this triggers the server answer 5. SNI callback is invoked by openssl and sets up vhost info and configs 6. Oops. Lacking the SNI name and vhost setups, the sendback in 4 seems to fallback to the default vhost selection and that certificate is used to answer the call. The issue has been reported by me on the openssl dev list. As a workaround for now and compatibility to older openssl versions, I propose to add to the ALPN patch something that a) checks in ALPN callback if vhost has been setup by SNI callback b) if not, retrieves SNI servername via SSL_get_servername() c) if servername is returned, setup vhost just like in SNI callback d) if SNI callback is invoked and vhost has been setup already, nop Sounds reasonable? //Stefan green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: sni+alpn, vhost+certs
On Wed, Jun 17, 2015 at 8:21 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: 1. connection, setup for base server and defaults 2. client hello arrives 3. ALPN callback is invoked by openssl 4. ALPN protocol is chosen, this triggers the server answer 5. SNI callback is invoked by openssl and sets up vhost info and configs 6. Oops. Lacking the SNI name and vhost setups, the sendback in 4 seems to fallback to the default vhost selection and that certificate is used to answer the call. The issue has been reported by me on the openssl dev list. As a workaround for now and compatibility to older openssl versions, I propose to add to the ALPN patch something that a) checks in ALPN callback if vhost has been setup by SNI callback b) if not, retrieves SNI servername via SSL_get_servername() c) if servername is returned, setup vhost just like in SNI callback d) if SNI callback is invoked and vhost has been setup already, nop Sounds reasonable? Seems fair -- Eric Covener cove...@gmail.com
Re: Bug 57641
I have updated the bugzilla ticket since this was committed in r1684900 and a backport to 2.4.x is already proposed. Regards, Yann. On Wed, Jun 17, 2015 at 11:06 AM, Mario Brandt jbl...@gmail.com wrote: Hi Nick, please add a unified diff file to the bug and add the keyword PatchAvailable Cheers Mario On 11 June 2015 at 13:31, Nick Gearls nickgea...@gmail.com wrote: Hi all, Can anybody have a look at this trivial bug waiting for months? The bug is obvious and the fix is a one line change. Thanks a lot
Re: Bug 57641
Hi Nick, please add a unified diff file to the bug and add the keyword PatchAvailable Cheers Mario On 11 June 2015 at 13:31, Nick Gearls nickgea...@gmail.com wrote: Hi all, Can anybody have a look at this trivial bug waiting for months? The bug is obvious and the fix is a one line change. Thanks a lot
