view release on metacpan or  search on metacpan

ASP.pm  view on Meta::CPAN

caching it for future invocations.  Then the compiled
subroutine is executed and has @args passed into its
as arguments.

This is still might be too static for some, as @args
is still hardcoded into the ASP script, so finally,
one may execute an include at runtime by utilizing
this API extension

   $Response->Include("filename.inc", @args);

which is a direct translation of the dynamic include above.

Although inline includes should be a little faster,
runtime dynamic includes represent great potential
savings in httpd memory, as includes are shared
between scripts keeping the size of each script
to a minimum.  This can often be significant saving
if much of the formatting occurs in an included 
header of a www page.

By default, all includes will be inlined unless
called with an args parameter.  However, if you
want all your includes to be compiled as subs and 
dynamically executed at runtime, turn the DynamicIncludes
config option on as documented above.

=head2 Apache::SSI for mod_perl 1.3.x only

One of the things missing above is the 

 <!--#include virtual=filename.cgi-->

tag.  This and many other SSI code extensions are available
by filtering Apache::ASP output through Apache::SSI via
the Apache::Filter and the Filter config options, available in mod_perl 1.3.x / Apache 1.3.x.
Unfortunately this functionality is not available with mod_perl 2 / Apache 2.

For more information on how to wire Apache::ASP and Apache::SSI
together, please see the Filter config option documented
above.  Also please see Apache::SSI for further information
on the capabilities it offers.

=head2 SSI with mod_filter in Apache 2

Apache 2 offers chained filters.  It may be possible to chain filters to
Apache::ASP output through mod_filter for SSI processing:

  http://httpd.apache.org/docs/2.1/mod/mod_filter.html

=head1 EXAMPLES

Use with Apache.  Copy the ./site/eg directory from the ASP installation 
to your Apache document tree and try it out!  You have to put 
"AllowOverride All" in your <Directory> config section to let the 
.htaccess file in the ./site/eg installation directory do its work.  

IMPORTANT (FAQ): Make sure that the web server has write access to 
that directory.  Usually a 

 chmod -R 0777 eg

will do the trick :)

=head1 SESSIONS

Cookies are used by default for user $Session support ( see OBJECTS ).  
In order to track a web user and associate server side data 
with that client, the web server sets, and the web client returns 
a 32 byte session id identifier cookie.  This implementation 
is very secure and  may be used in secure HTTPS transactions, 
and made stronger with SecureSession, HTTPOnlySession and
ParanoidSession settings (see CONFIG ).

However good cookies are for this kind of persistent
state management between HTTP requests, they have long 
been under fire for security risks associated with
JavaScript security exploits and privacy abuse by 
large data tracking companies. 

Because of these reasons, web users will sometimes turn off
their cookies, rendering normal ASP session implementations
powerless, resulting in a new $Session generated every request.
This is not good for ASP style sessions.

=head2 Cookieless Sessions

 *** See WARNING Below ***

So we now have more ways to track sessions with the 
SessionQuery* CONFIG settings, that allow a web developer 
to embed the session id in URL query strings when use 
of cookies is denied.  The implementations work such that
if a user has cookies turned on, then cookies will be 
used, but for those users with cookies turned off,
the session ids will be parsed into document URLs.

The first and easiest method that a web developer may use 
to implement cookieless sessions are with SessionQueryParse*
directives which enable Apache::ASP to the parse the session id
into document URLs on the fly.  Because this is resource
inefficient, there is also the SessionQuery* directives
that may be used with the $Server->URL($url,\%params) method to 
generate custom URLs with the session id in its query string.

To see an example of these cookieless sessions in action, 
check out the ./site/eg/session_query_parse.asp example.

 *** WARNING ***

If you do use these methods, then be VERY CAREFUL
of linking offsite from a page that was accessed with a 
session id in a query string.  This is because this session
id will show up in the HTTP_REFERER logs of the linked to 
site, and a malicious hacker could use this information to
compromise the security of your site's $Sessions, even if 
these are run under a secure web server.  

In order to shake a session id off an HTTP_REFERER for a link 
taking a user offsite, you must point that link to a redirect 
page that will redirect a user, like so:

ASP.pm  view on Meta::CPAN

Unless scoped by my() or local(), perl variables in mod_perl
are treated as globals, and values set may persist from one 
request to another. This can be seen in as simple a script
as this:

  <HTML><BODY>
    $counter++;
    $Response->Write("<BR>Counter: $counter");
  </BODY></HTML>

The value for $counter++ will remain between requests.
Generally use of globals in this way is a BAD IDEA,
and you can spare yourself many headaches if do 
"use strict" perl programming which forces you to 
explicity declare globals like:

  use vars qw($counter);

You can make all your Apache::ASP scripts strict by
default by setting:

  PerlSetVar UseStrict 1

=item Apache errors on the PerlHandler or PerlModule directives ?

You get an error message like this:

 Invalid command 'PerlModule', perhaps mis-spelled or defined by a 
 module not included in the server configuration.

You do not have mod_perl correctly installed for Apache.  The PerlHandler
and PerlModule directives in Apache *.conf files are extensions enabled by mod_perl
and will not work if mod_perl is not correctly installed.

Common user errors are not doing a 'make install' for mod_perl, which 
installs the perl side of mod_perl, and not starting the right httpd
after building it.  The latter often occurs when you have an old apache
server without mod_perl, and you have built a new one without copying
over to its proper location.

To get mod_perl, go to http://perl.apache.org

=item Error: no request object (Apache=SCALAR(0x???????):)

Your Apache + mod_perl build is not working properly, 
and is likely a RedHat Linux RPM DSO build.  Make sure
you statically build your Apache + mod_perl httpd,
recompiled fresh from the sources.

=item I am getting a tie or MLDBM / state error message, what do I do?

Make sure the web server or you have write access to the eg directory,
or to the directory specified as Global in the config you are using.
Default for Global is the directory the script is in (e.g. '.'), but should
be set to some directory not under the www server document root,
for security reasons, on a production site.

Usually a 

 chmod -R -0777 eg

will take care of the write access issue for initial testing purposes.

Failing write access being the problem, try upgrading your version
of Data::Dumper and MLDBM, which are the modules used to write the 
state files.

=head2 Sessions

=item How can I use $Session to store complex data structures.

Very carefully.  Please read the $Session documentation in 
the OBJECTS section.  You can store very complex objects
in $Session, but you have to understand the limits, and 
the syntax that must be used to make this happen.

In particular, stay away from statements that that have 
more than one level of indirection on the left side of
an assignment like:

  BAD: $Session->{complex}{object} = $data;

=item How can I keep search engine spiders from killing the session manager?

If you want to disallow session creation for certain non web 
browser user agents, like search engine spiders, you can use a mod_perl
PerlInitHandler like this to set configuration variables at runtime:

 # put the following code into httpd.conf and stop/start apache server
 PerlInitHandler My::InitHandler

 <Perl>

  package My::InitHandler;
  use Apache;

  sub handler {
    my $r = shift; # get the Apache request object

    # if not a Mozilla User Agent, then disable sessions explicitly
    unless($r->headers_in('User-Agent') =~ /^Mozilla/) {
       $r->dir_config('AllowSessionState', 'Off');
    }

    return 200; # return OK mod_perl status code
  }

  1;

 </Perl>

This will configure your environment before Apache::ASP executes
and sees the configuration settings.  You can use the mod_perl
API in this way to configure Apache::ASP at runtime.

Note that the Session Manager is very robust on its own, and denial
of service attacks of the types that spiders and other web bots 
normally execute are not likely to affect the Session Manager significantly.

=item How can I use $Session to store a $dbh database handle ?