Mark Montague wrote:
If you're ignoring the "remarkably bad idea" part of Rich's response, above, here are some more ways to get in trouble:- mod_cosign allows you to make authentication optional via the CosignAllowPublicAccess directive. If you are serving dynamic content (a CGI, etc.), you (or your developer) can then have your dynamic content (a CGI, etc.) force authentication if the user is not authenticated and the query string does not contain ":25:", but allow both authenticated and unauthenticated access otherwise. For specifics on how to implement this, ask on the cosign-discuss mailing list ( https://lists.sourceforge.net/lists/listinfo/cosign-discuss ). Unfortunately, this solution will not work for static content.- You (or your developer) can modify mod_cosign to get what you need; this is horrible and ugly, but probably easier than implementing your own authentication mechanism. You'll probably want to add your additional check (return DECLINED if the query string contains ":25:") in the cosign source code near filters/apache/mod_cosign.c line 428. Lines 209-222 of the same file provide an example of code that checks the query string that could be rewritten for your needs. See http://cosign.git.sourceforge.net/git/gitweb.cgi?p=cosign/cosign;a=blob;f=filters/apache/mod_cosign.c;h=3a279745e70acef52211678e2a6a3acb89392a04;hb=HEAD
ABSOLUTELY not a consideration, so don't worry on that one. Admittedly, I was hoping that some other folks (as yet unasked) would tell me I'd missed some delightful feature in MOD_COSIGN that would allow me to put some kind of env= optionality onto the CosignProtected directive... But this whole discussion has proven the fool heartiness of that, too.
Again, this seems like a really bad idea.The above bears repeating (if it's not obvious why its a bad idea, let us know so we can explain).WHY does your developer think he needs to bypass authentication based on what's in the query string? Knowing the details of the situation may allow us to suggest an alternative solution. Remind your developer of http://www.catb.org/~esr/faqs/smart-questions.html#goal
Well, I've asked this question already. Seems that the 3 DYNAMIC
pages of content that will not require authentication are being rolled
into the other DYNAMIC pages which do. They (not sure who THEY are,
perhaps the application's customer, perhaps the developer's supervisor,
or somebody else along the hierarchy) want it all in the same DNS
name and Oracle application.
After floating some alternatives back to him, I offered to pass on
the conceptual request to this august group on the off chance it wasn't
as ill-advised as I suspected. Turns out, however, that it's even more
ill-advised than I'd suspected.
--
J.Lance Wilkinson ("Lance") InterNet: Lance.Wilkinson@xxxxxxx
Systems Design Specialist - Lead Phone: (814) 865-4870
Digital Library Technologies FAX: (814) 863-3560
E3 Paterno Library
Penn State University
University Park, PA 16802
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|