|
cosign-discuss at umich.edu
|
general discussion of cosign development and deployment
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
mod_cosign / mod_authz_ldap behavior
- To: cosign-discuss@xxxxxxxxx
- Subject: mod_cosign / mod_authz_ldap behavior
- From: Kris Steinhoff <steinhof@xxxxxxxxx>
- Date: Wed, 7 Sep 2005 09:29:44 -0400
- Mail-followup-to: cosign-discuss@umich.edu
- User-agent: Mutt/1.4.2.1i
I have mod_cosign setup and working nicely on my OS X Server (10.4.2),
and I've followed the directions for setting up mod_authz_ldap to work
with cosign:
http://www.umich.edu/~umweb/downloads/mod_authz_ldap-NOTES-UMICH.txt
However using that file to patch mod_authz_ldap fails in two places:
patching file module/auth.c
patching file module/mod_authz_ldap.h
Hunk #1 FAILED at 52.
Hunk #2 FAILED at 61.
2 out of 2 hunks FAILED -- saving rejects to file
module/mod_authz_ldap.h.rej
patching file module/modconf.c
I've applied the changes in those two hunks by hand and compiled
mod_authz_ldap.
Things seem to work pretty well, but there is a problem with my server
not redirecting to the weblogin server when the browser requests a
directory which has a "Require group ..." directive associated with
it. But it works just fine if the browser already has the cosign
cookies set.
For example, take two directories "/broken" and "/ok." The directory
entries in httpd.conf are the same for both, but "/broken" includes a
"Require group ... " directive. If I visit "/broken" the browser gets
a 401 error and
basic LDAP authentication of user '(null)' failed
is printed to my server's error log. But if I then visit "/ok" the
browser is redirected normally to the weblogin server. After I
authenticate at the weblogin server and the cosign cookies are set I
can visit "/broken" without any trouble.
It seems like mod_authz_ldap is doing its thing before mod_cosign gets
a chance to, but I've double checked to make sure that mod_cosign is
loaded before mod_authz_ldap, so I'm not sure if that the problem.
Any suggesting about where I might start looking to fix this? Could it
be the problem I had with the patch? Something else?
thanks
-kris
--
Kris Steinhoff
University of Michigan Health Service
Information Technology Services
Electronic mail is not secure, may not be read every day,
and should not be used for urgent or sensitive issues.
|