On Mar 29, 2010, at 4:17 PM, J.Lance Wilkinson wrote:
> J.Lance Wilkinson wrote:
>> We have a 3rd party application which interacts via a handler with our
>> Apache server that has the COSIGN Apache Filter being used for
>> authentication.
>>
>> That application uses the SWFUPLOAD.ORG flash utility to do some of its
>> work.
>>
>> The flash utility cannot supply the cookies back from the browser's cookie
>> stash so as a result the input from the flash utility back to Apache and
>> then that 3rd party application are unauthenticate, and COSIGN's redirect
>> sidelines the entire operation.
>>
>> IF there were a way to simply materialize REMOTE_USER (and optionally
>> REMOTE_REALM) without requiring passing through the COSIGN authenticator yet
>> again, we'd be able to get around this.
>
> OK, maybe I've made a monster out of the vendor -- he actually
> went to the Cosign wiki and thinks that this will resolve our
> issues.
>
> <Location /tmp>
> CosignAllowPublicAccess ON
> (implicitly CosignProtected ON)
> </Location>
>
> He thinks this will:
>
> 1) allow the 1st POST from the FLASH utility uploading a file
> to /tmp to be unauthenticated (public access)
> 2) allow the 2nd POST for the move operation which comes from
> the swfupload javascript running within the browser and
> needs to be authenticated (to /var/dam, which is by default
> CosignProtected ON).
>
> But I see several issues being discussed about this directive when
> I do a search for "CosignAllowPublicAccess" in google. Some report
> problems, others seem to be suggesting all is well.
>
> I'm using Cosign v3.0.2 -- is CosignAllowPublicAccess {ON|OFF}
> going to have the desired effect here?
Unfortunately, I doubt it this is really what you want to do.
"CosignAllowPublicAccess On" means exactly what you think it means: the public
has access to the resource. If you use CosignAllowPublicAccess with an upload
utility, there's nothing stopping the public red in tooth and claw from DoS'ing
your server with uploads.
CosignAllowPublicAccess means that if the user's not already authenticated,
mod_cosign will still let them through to the resource. If the user is
authenticated, mod_cosign will set all the usual environment variables. This
allows sites to display different information depending on availability of
REMOTE_USER, rather than simply denying access without authentication.
CosignAllowPublicAccess *will never* cause mod_cosign to redirect the user to
log in. Most sites using this directive have a conspicuous "Log In" button
somewhere on the page if REMOTE_USER isn't set.
andrew
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss
