Apache-ASP

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    ASP scripts, but they are still fairly static. As of version .09, includes
    may have dynamic runtime execution, as subroutines compiled into the
    global.asa namespace. The first way to invoke includes dynamically is

     <!--#include file=filename.inc args=@args-->

    If @args is specified, Apache::ASP knows to execute the include at runtime
    instead of inlining it directly into the compiled code of the script. It
    does this by compiling the script at runtime as a subroutine, and 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.

  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.

  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

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 :)

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.

  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:

     <% 
        # "cross site scripting bug" prevention
        my $sanitized_url = 
            $Server->HTMLEncode($Response->QueryString('OffSiteUrl'));
     %>
     <html>
     <head>
     <meta http-equiv=refresh content='0;URL=<%=$sanitized_url%>'>
     </head>

README  view on Meta::CPAN

            --enable-module=so \
            --disable-rule=EXPAT

                           ^^^^^

        keywords: segmentation fault, segfault seg fault

    Why do variables retain their values between requests?
        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

    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

    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.

    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.

  Sessions
    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;

    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.

    How can I use $Session to store a $dbh database handle ?
        You cannot use $Session to store a $dbh handle. This can be awkward for
        those coming from the IIS/NT world, where you could store just about
        anything in $Session, but this boils down to a difference between
        threads vs. processes.



( run in 1.069 second using v1.01-cache-2.11-cpan-39bf76dae61 )