JSP forward Equivalent in mod_perl
Hi, Java/Servlet/jsp world there are two types of http forwards/redirect redirect -> This is make a complete new request, loose all the request parameters forward-> Will preserve all the information (e.g parameters) and forward to the other URL in mod_perl when we make a redirect (using the constant REDIRECT) it will loose everything make a complete new request. Instead of this How can I preserve the information (as in above java jsp forward) and transfer to a another URL, I like to preserve the cookie and other request parameters. Is this something possible in mod_perl. Thanks, -- View this message in context: http://www.nabble.com/JSP-forward-Equivalent-in-mod_perl-tf3026553.html#a8408219 Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: JSP forward Equivalent in mod_perl
Tracy12 wrote: > Hi, > > Java/Servlet/jsp world there are two types of http forwards/redirect > > redirect -> This is make a complete new request, loose all the request > parameters > forward-> Will preserve all the information (e.g parameters) and forward to > the other URL > > > in mod_perl when we make a redirect (using the constant REDIRECT) it will > loose everything make a complete new request. Instead of this > How can I preserve the information (as in above java jsp forward) and > transfer to a another URL, I like to preserve the cookie and other request > parameters. Is this something possible in mod_perl. $r->internal_redirect --Geoff
Re: JSP forward Equivalent in mod_perl
Geoffrey Young wrote: $r->internal_redirect That's the most equivalent. You can also just call some other handler directly: Foo::handler($r); - Perrin
Apache2::Const::MOVED ?
doesn't exist. Is the correct way to return a 301 to use Apache2::Const::HTTP_MOVED_PERMANENTLY ? I keep thinking that i've read somewhere that using the ::HTTP* constants isn't a good idea. Adam
Re: Redirects?
Will Fould wrote:
I have a strange issue with a particular script that sometimes (often)
generates a 302 to another script without a clear reason why.
Oddly enough, I simply placed a few "warn('blah')" code snippets to
crudely determine from the error log where it was happening in
production (because I cannot replicate the issue in development (linux
client/local server)) but with the Warn() statements, if seems to no
longer happen !! -- any suggestions/clues where I might look? This is
the only script that does this under the same location/configuration.
Could this be an issue with buffering? The warns might be triggering a
buffer flush.
$|=1 might solve the issue once the warns are removed.
Rob
Re: Redirects?
On Tue, 2007-01-16 at 16:45 -0800, Will Fould wrote: > I have a strange issue with a particular script that sometimes (often) > generates a 302 to another script without a clear reason why. Are you saying that you don't have any code in the script that generates redirects, but they sometimes happen anyway? That would mean you're really getting them from somewhere else, like an auth handler or mod_dir. - Perrin
Re: Apache2::Const::MOVED ?
On Wed, 2007-01-17 at 10:25 -0500, Adam Prime x443 wrote: > doesn't exist. Is the correct way to return a 301 to use > Apache2::Const::HTTP_MOVED_PERMANENTLY ? I keep thinking that i've read > somewhere that using the ::HTTP* constants isn't a good idea. This thread covered it pretty well: http://marc.theaimsgroup.com/?l=apache-modperl&m=116784025805764&w=2 Also, http://perl.apache.org/docs/2.0/user/porting/compat.html#Deprecated_Constants - Perrin
file descriptor for client socket?
Is it possible to get the file descriptor for the client socket from the RequestRec? I.e. something like $r->FILENO (which doesn't seem to work) or perhaps $r->connection->client_socket->os_sock (os_sock exists in the APR structure in C, but there doesn't seem to be a perl accessor method.) Reason I want to do this... I'm trying write a perl module to pass the connection to another process using File::FDpasser.
Session Handling/Set Session attributes
Hi, My perl authentication handler works fine BUT the biggest problem inside my Auth handler I do some resource intenstive tasks and if everything successful set the REMOTE_USER env variable. But for the subsequent requests from the same user (after the initial Authentication is successful) how can I bypass these resource intensive tasks because the user already been authenticated (but I need REMOTE_USER value for subsequent request My suggestions 1) After initial Authentication set a session attribute (my_remote_user) with the value REMOTE_USER, in subsequent requests check this attribute is there and return OK, without going further Question -> How does the session handling supported in mod_perl, how can I retrieve the user session and set variables like that, 2)Does mod_perl supports in such a way that for subsequent requests the user has authenticated and hence gives the value of the remote user. Currently my Auth handler does the all the tasks inside the authentication handler, which might be a performance killer thanks -- View this message in context: http://www.nabble.com/Session-Handling-Set-Session-attributes-tf3030824.html#a8420979 Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: file descriptor for client socket?
Daniel Risacher wrote: Is it possible to get the file descriptor for the client socket from the RequestRec? I.e. something like $r->FILENO (which doesn't seem to work) or perhaps $r->connection->client_socket->os_sock (os_sock exists in the APR structure in C, but there doesn't seem to be a perl accessor method.) Reason I want to do this... I'm trying write a perl module to pass the connection to another process using File::FDpasser. $fd = fileno(STDOUT); won't work? Is this really what you want to do? I think apache will still terminate the connection (I'm not sure there's away to avoid that). Rob
Re: Session Handling/Set Session attributes
Tracy12 wrote: My perl authentication handler works fine BUT the biggest problem inside my Auth handler I do some resource intenstive tasks and if everything successful set the REMOTE_USER env variable. But for the subsequent requests from the same user (after the initial Authentication is successful) how can I bypass these resource intensive tasks because the user already been authenticated (but I need REMOTE_USER value for subsequent request I would use Apache::Session and store a cookie that says that this user is authenticated. The session would include to be set for REMOTE_USER. The user would only get the session cookie if they had successfully authenticated. It should work fine and will likely solve your performance problem. Rob
Re: Session Handling/Set Session attributes
What about the security measures if we store authenticated user information in a cookie, Cant we handle in the server session and and store it as a session variable. This would be much secure? Robert Landrum wrote: > > Tracy12 wrote: >> My perl authentication handler works fine BUT the biggest problem inside >> my >> Auth handler I do some resource intenstive tasks and if everything >> successful set the REMOTE_USER env variable. >> >> But for the subsequent requests from the same user (after the initial >> Authentication is successful) how can I bypass these resource intensive >> tasks because the user already been authenticated (but I need REMOTE_USER >> value for subsequent request >> > > I would use Apache::Session and store a cookie that says that this user > is authenticated. The session would include to be set for REMOTE_USER. > The user would only get the session cookie if they had successfully > authenticated. > > It should work fine and will likely solve your performance problem. > > Rob > > -- View this message in context: http://www.nabble.com/Session-Handling-Set-Session-attributes-tf3030824.html#a8421325 Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: Redirects?
Assuming your not re-using session variables, you might want to verify that your package names do not conflict and that your conditions for any redirects are not confused. I remember fighting this in a previous life. B On Wednesday 17 January 2007 08:24, Perrin Harkins wrote: > On Tue, 2007-01-16 at 16:45 -0800, Will Fould wrote: > > I have a strange issue with a particular script that sometimes (often) > > generates a 302 to another script without a clear reason why. > > Are you saying that you don't have any code in the script that generates > redirects, but they sometimes happen anyway? That would mean you're > really getting them from somewhere else, like an auth handler or > mod_dir. > > - Perrin
Re: Session Handling/Set Session attributes
On Jan 17, 2007, at 5:50 PM, Tracy12 wrote: What about the security measures if we store authenticated user information in a cookie, Cant we handle in the server session and and store it as a session variable. This would be much secure? you store a session id in a cookie you store the user info on the lan, mapped to the id in the cookie you can use checksum cookies and other stuff to mitigate cookie spoofing // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder | Web Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans | Collaborative Online Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: Session Handling/Set Session attributes
Well does this all mean there is limited features to do session handling on
mod_perl. Well I am new to mod_perl but in JAVA/Servlet you can do a simple
thing like this
request.getSession().setAttribute("my_remote_user",);
for subsequent requests we can retrieve this attribute and do what we want.
I expected similar session handleing feature availabe in mod_perl as this is
a common requirement.
"store the user info on the lan, mapped to the id in the cookie" is
something which we need to think, Isnt there a easy way to store information
on user session.
Other doubt that we have is Because the user successful in his first
Authentication, Isnt there a way to retrieve the remote_user variable in the
subsequent requests (I may be wrong as well all new to this).
Thanks
Jonathan Vanasco-5 wrote:
>
>
> On Jan 17, 2007, at 5:50 PM, Tracy12 wrote:
>
>>
>> What about the security measures if we store authenticated user
>> information
>> in a cookie,
>>
>> Cant we handle in the server session and and store it as a session
>> variable.
>> This would be much secure?
>
> you store a session id in a cookie
>
> you store the user info on the lan, mapped to the id in the cookie
>
> you can use checksum cookies and other stuff to mitigate cookie spoofing
>
>
>
>
>
> // Jonathan Vanasco
>
> | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - -
> | FindMeOn.com - The cure for Multiple Web Personality Disorder
> | Web Identity Management and 3D Social Networking
> | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - -
> | RoadSound.com - Tools For Bands, Stuff For Fans
> | Collaborative Online Management And Syndication Tools
> | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - -
>
>
>
>
--
View this message in context:
http://www.nabble.com/Session-Handling-Set-Session-attributes-tf3030824.html#a8422602
Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: Session Handling/Set Session attributes
On Wed, 2007-01-17 at 14:50 -0800, Tracy12 wrote: > What about the security measures if we store authenticated user information > in a cookie, > > Cant we handle in the server session and and store it as a session variable. > This would be much secure? Have you looked at the Apache::AuthCAS module on CPAN? http://search.cpan.org/dist/Apache-AuthCAS/ It seems to already support the use of session cookies. The various mod_cas modules that Google turns up also seem to support local caching of some kind. I don't mean to discourage you from writing your own if you want to learn mod_perl, but if you just want to get something working, using those might be faster. Regarding your earlier question about using basic auth with something like mod_cas, you can configure your 401 ErrorDocument to be a mod_perl handler which redirects to anything you want. So, I believe you could use mod_cas if you choose to. - Perrin
Re: Session Handling/Set Session attributes
On Wed, 2007-01-17 at 16:11 -0800, Tracy12 wrote: > Well does this all mean there is limited features to do session handling on > mod_perl. Concepts like sessions are not built into mod_perl. They are implemented separately by modules that you can find on CPAN, like Apache::Session, which was suggested to you earlier. My preferred module for sessions these days is CGI::Session, which also works with mod_perl. If you want to use sessions, you can read the documentation for these modules on http://search.cpan.org/. - Perrin
Re: Session Handling/Set Session attributes
Apache::AuthCAS module on CPAN does not support OPEN SSL also it creates database tables to store data, we tried it on Apache 2.2 with mod_perl 2.0 it failed. We need only a serviceValidate from CAS not other functions. mod_cas looks ok but does not supports Apache 2.2 We have almost finish our authentication module, infact it works, But only thing is we are working on how to cache things as I am dealing wiht the forum. If we know how to resolve this subsequent requests without doing the Authentication logic all over we are done. Thanks Perrin Harkins wrote: > > On Wed, 2007-01-17 at 14:50 -0800, Tracy12 wrote: >> What about the security measures if we store authenticated user >> information >> in a cookie, >> >> Cant we handle in the server session and and store it as a session >> variable. >> This would be much secure? > > Have you looked at the Apache::AuthCAS module on CPAN? > http://search.cpan.org/dist/Apache-AuthCAS/ > > It seems to already support the use of session cookies. > > The various mod_cas modules that Google turns up also seem to support > local caching of some kind. I don't mean to discourage you from writing > your own if you want to learn mod_perl, but if you just want to get > something working, using those might be faster. > > Regarding your earlier question about using basic auth with something > like mod_cas, you can configure your 401 ErrorDocument to be a mod_perl > handler which redirects to anything you want. So, I believe you could > use mod_cas if you choose to. > > - Perrin > > > -- View this message in context: http://www.nabble.com/Session-Handling-Set-Session-attributes-tf3030824.html#a8422921 Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: Session Handling/Set Session attributes
On Jan 17, 2007, at 7:11 PM, Tracy12 wrote:
Well does this all mean there is limited features to do session
handling on
mod_perl. Well I am new to mod_perl but in JAVA/Servlet you can do
a simple
thing like this
request.getSession().setAttribute("my_remote_user",authenticated
user>);
for subsequent requests we can retrieve this attribute and do what
we want.
I expected similar session handleing feature availabe in mod_perl
as this is
a common requirement.
"store the user info on the lan, mapped to the id in the cookie" is
something which we need to think, Isnt there a easy way to store
information
on user session.
Other doubt that we have is Because the user successful in his first
Authentication, Isnt there a way to retrieve the remote_user
variable in the
subsequent requests (I may be wrong as well all new to this).
you use Apache::Session or CGI::Session to do that transparently.
your java servelet example seems to be using a framework, while
mod_perl is a platform.
you might be wanting to use something like catalyst which can run on
modperl and has the facilities to do what you want built in.
session handling isn't built into mod_perl, because that would lock
people into a certain way. instead you use either Apache::Session or
CGI::Session, or one of the numerous variants.
They all use the same model:
session id comes from client cookie
session id loads / saves a session variable to your LAN. either on
the same machine in a file, or on a database on your local network
request.getSession().setAttribute("my_remote_user",authenticated
user>);
that is very likely just wrapping several functions in one line.
request.getSession() probably wraps a routine to get session id based
on some client cookie value
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
Re: Session Handling/Set Session attributes
CGI::Session looks like it gives a good abstraction. I used use CGI::Session; in my code and came up with the error failed to resolve handler `AuthCAS->authen_handler': Can't locate CGI/Session.pm in @ I am using fedora core 5 with Apache 2.2 with mod_perl 2.x Can I know how can I install the above module(CGI::Session) to my system. Thanks Perrin Harkins wrote: > > On Wed, 2007-01-17 at 16:11 -0800, Tracy12 wrote: >> Well does this all mean there is limited features to do session handling >> on >> mod_perl. > > Concepts like sessions are not built into mod_perl. They are > implemented separately by modules that you can find on CPAN, like > Apache::Session, which was suggested to you earlier. My preferred > module for sessions these days is CGI::Session, which also works with > mod_perl. > > If you want to use sessions, you can read the documentation for these > modules on http://search.cpan.org/. > > - Perrin > > > -- View this message in context: http://www.nabble.com/Session-Handling-Set-Session-attributes-tf3030824.html#a8423735 Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: Session Handling/Set Session attributes
Tracy12 wrote: Can I know how can I install the above module(CGI::Session) to my system. There is lots of good documentation about installing perl modules. You can read the perlmodinstall man page. You can pick up a good book like "Intermediate Perl." There is a discussion about CPAN modules in the Perl FAQ, available in the perlfaq man page or on the web here: http://perldoc.perl.org/perlfaq2.html#What-modules-and-extensions-are-available-for-Perl%3f--What-is-CPAN%3f--What-does-CPAN%2fsrc%2f...-mean%3f When you have general questions about perl that are not specific to mod_perl, a good place to ask is the perl-beginners mailing list: http://lists.cpan.org/showlist.cgi?name=beginners I know it's not always obvious which questions are about mod_perl and which are general perl questions. If you're not sure, it's fine to ask. - Perrin
Two failures in make test building mod_perl 2.0.3
-8<-- Start Bug Report 8<-- 1. Problem Description: Two failures in make test building mod_perl 2.0.3 2. Used Components and their Configuration: *** mod_perl version 2.03 *** using /tmp/mod_perl-2.0.3/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_AP_PREFIX => /www MP_CCOPTS => -march=pentiumpro MP_COMPAT_1X => 0 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 *** /www/bin/httpd -V Server version: Apache/2.2.3 Server built: Aug 9 2006 10:27:21 Server's Module Magic Number: 20051115:3 Server loaded: APR 1.2.2, APR-Util 1.2.2 Compiled using: APR 1.2.2, APR-Util 1.2.2 Architecture: 32-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_FLOCK_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/usr/local/apache2" -D SUEXEC_BIN="/usr/local/apache2/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" *** /usr/bin/ldd /www/bin/httpd /www/bin/httpd: libssl.so.4 => /usr/lib/libssl.so.4 (0x28113000) libcrypto.so.4 => /lib/libcrypto.so.4 (0x28142000) libm.so.4 => /lib/libm.so.4 (0x28239000) libaprutil-1.so.2 => /usr/local/apache2/lib/libaprutil-1.so.2 (0x2824f000) libdb41.so.1 => /usr/local/lib/libdb41.so.1 (0x28267000) libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x28303000) libapr-1.so.2 => /usr/local/apache2/lib/libapr-1.so.2 (0x28324000) libcrypt.so.3 => /lib/libcrypt.so.3 (0x2834a000) libpthread.so.2 => /usr/lib/libpthread.so.2 (0x28362000) libc.so.6 => /lib/libc.so.6 (0x28387000) *** (apr|apu)-config linking info -L/usr/local/apache2/lib -laprutil-1 -ldb41 -lexpat -L/usr/local/lib -L/usr/local/apache2/lib -lapr-1 -lcrypt -lpthread *** /usr/local/bin/perl -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=freebsd, osvers=6.0-release, archname=i386-freebsd-64int uname='freebsd mackenna1.securesites.net 6.0-release freebsd 6.0- release #19: wed sep 20 14:24:06 mdt 2006 [EMAIL PROTECTED]:usrsrcsysi386compilevkern i386 ' config_args='-Doptimize=-march=pentiumpro -des -Uusethreads - Duse64bitint' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno- strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/ include', optimize='-march=pentiumpro', cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict- aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include' ccversion='', gccversion='3.4.4 [FreeBSD] 20050518', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags ='-Wl,-E -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lgdbm -lm -lcrypt -lutil -lc perllibs=-lm -lcrypt -lutil -lc libc=, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under freebsd Compiled at Jan 17 2007 15:07:11 %ENV: PERL_LWP_USE_HTTP_10="1" @INC: /usr/local/lib/perl5/5.8.8/i386-freebsd-64int /usr/local/lib/perl5/5.8.8 /usr/local/lib/perl5/site_perl/5.8.8/i386-freebsd-64int /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl . *** Packages of interest status: Apache2: - Apache2::Request : - CGI: 3.25 ExtUtils::MakeMaker: 6.30 LWP: 5.805 mod_perl : - mod_perl2 : - 3. This is the core dump trace: (if you get a core dump): none This report was generated by t/REPORT on Thu Jan 18 07:21:59 2007 GMT. -
