Apache::Request equivalent of CGI::Capture?

[David Naughton <na...@umn.edu>]

Has anyone implemented the equivalent of CGI::Capture for
Apache::Request? If not, I may want to implement it myself. However, I'm
fairly new to mod_perl, so maybe there's a completely different and
better way to solve my problem, in which case I would appreciate some
enlightenment.

My problem is that I need to interact with a single sign-on system that
runs on a different server. If the user must authenticate, my server
must redirect the user to a login application on the SSO server, which,
upon successful login, will redirect the user back to whatever uri she
was originally trying to access on my server. I want to do this in a way
that is transparent to the user, even if she was uploading a file at the
time of the redirect. 

Under CGI, I don't think just saving the CGI object will work for file
uploads, but it seems that saving a CGI::Capture object will work just
fine. Is there a similar, already-existing solution for Apache::Request?
Or would I be better off pursuing a different solution, anyway?

Any help would be much appreciated!

Thank you,
David Naughton

Re: Apache::Request equivalent of CGI::Capture?

[William McKee <wi...@knowmad.com>]

On Wed, Feb 16, 2005 at 10:40:52PM -0500, Stas Bekman wrote:
> I wonder if it'd be a good idea to make CGI.pm libapreq aware. Most people 
> use CGI.pm since it parses input and generates the output, so empowering 
> CGI.pm with libapreq speed would be really cool.

Actually, I thought[1] the goal of Apache::Request was to mimic most of
the functions in CGI.pm. I know that Michael Peters (who is hopefully
reading this message and can speak for himself) had to do some extra
coding for his CGI::Application plugin[2] which uses the Apache::*
modules when running inside a mod_perl environment. From a programmers
point-of-view, there are some extra keystrokes involved if you want to
support both mod_cgi and mod_perl simply due to the difference in the
APIs.

I suppose though that adding libapreq to CGI.pm would garner more
results for more developers faster than amending the A::R API to mimic
CGI.pm (which may not even be the goal of this module).


William

[1] Presently, I'm primarily an Apache::Registry user.
[2] http://search.cpan.org/~wonko/CGI-Application-Plugin-Apache-0.10/

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: Apache::Request equivalent of CGI::Capture?

[Stas Bekman <st...@stason.org>]

Joe Schaefer wrote:
> Adam Kennedy <ad...@phase-n.com> writes:
> 
> 
>>For the record, and those that haven't seen CGI::Capture before (I
>>wrote it only fairly recently) all it really does is grab the
>>environment and a couple of magic variable values, then take STDIN
>>before CGI.pm gets a chance to parse it.
> 
> 
> Cool.  One of the goals we have with apreq2 is to use apache's input 
> filters to transparently parse the data without actually consuming it.
> So Apache::Request (or Apache2::Request, if we go that route) shouldn't 
> really need a similar module, because that's already built into the
> filter design.  Module authors that use apreq2 exclusively can discard 
> the request body if they have no other use for the raw POST data.

I wonder if it'd be a good idea to make CGI.pm libapreq aware. Most people 
use CGI.pm since it parses input and generates the output, so empowering 
CGI.pm with libapreq speed would be really cool.



-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache::Request equivalent of CGI::Capture?

[Joe Schaefer <jo...@sunstarsys.com>]

Adam Kennedy <ad...@phase-n.com> writes:

> For the record, and those that haven't seen CGI::Capture before (I
> wrote it only fairly recently) all it really does is grab the
> environment and a couple of magic variable values, then take STDIN
> before CGI.pm gets a chance to parse it.

Cool.  One of the goals we have with apreq2 is to use apache's input 
filters to transparently parse the data without actually consuming it.
So Apache::Request (or Apache2::Request, if we go that route) shouldn't 
really need a similar module, because that's already built into the
filter design.  Module authors that use apreq2 exclusively can discard 
the request body if they have no other use for the raw POST data.

-- 
Joe Schaefer

Re: Apache::Request equivalent of CGI::Capture?

[Adam Kennedy <ad...@phase-n.com>]

For the record, and those that haven't seen CGI::Capture before (I wrote 
it only fairly recently) all it really does is grab the environment and 
a couple of magic variable values, then take STDIN before CGI.pm gets a 
chance to parse it.

These bits are all stored in an object, which is just Storable'd to disk.

Rebuilding simple consists of setting the environment back again, and 
replacing STDIN with a IO::Scalar to the previously captured data.

Adam

David Naughton wrote:
> Has anyone implemented the equivalent of CGI::Capture for
> Apache::Request? If not, I may want to implement it myself. However, I'm
> fairly new to mod_perl, so maybe there's a completely different and
> better way to solve my problem, in which case I would appreciate some
> enlightenment.
> 
> My problem is that I need to interact with a single sign-on system that
> runs on a different server. If the user must authenticate, my server
> must redirect the user to a login application on the SSO server, which,
> upon successful login, will redirect the user back to whatever uri she
> was originally trying to access on my server. I want to do this in a way
> that is transparent to the user, even if she was uploading a file at the
> time of the redirect. 
> 
> Under CGI, I don't think just saving the CGI object will work for file
> uploads, but it seems that saving a CGI::Capture object will work just
> fine. Is there a similar, already-existing solution for Apache::Request?
> Or would I be better off pursuing a different solution, anyway?
> 
> Any help would be much appreciated!
> 
> Thank you,
> David Naughton