MrForsythExeter has asked for the wisdom of the Perl Monks concerning the following question:

Hi Guys, Im having quite a big problem (in my eyes), I will try to explain it the best i can. I use CGI:SSI (autotie => 'STDOUT'); as the site im working with has a quite big HTML database with some SSI's in the HTML Code. The Reason i use CGI:SSI is becuase the browser will not process the scripts output for SSI with outit. The SSI im calling is another CGI script however this script is not able to read the cookies? This is where i am stuck. I use a standard sub to read all my cookies.. so i know its working. here it is just encase..
sub getcookie{ use Crypt::RC4; my $passphrase = "*****************"; my $cookiename = uc(shift); if($cookiename eq ""){ return 0 } my $usercookie = $query->cookie($cookiename); my %hashreturn; if($usercookie eq ''){ return 0 } $usercookie = RC4( $passphrase, $usercookie ); if ($usercookie){ my @tempcookie = split(':',$usercookie); foreach my $cookieinfo (@tempcookie){ $cookieinfo =~ /^(.*?)=(.*)/; my $value1 = $1; my $value2 = $2; $hashreturn{$value1} = $value2; } } return (1,%hashreturn); }
I have also tried printing the ENV but there is no cookie in there. I guess the simple question is can SSI calls to other CGI scripts access cookies. just incase you need to know the SSI call im doing is:
<!--#include virtual="http://www.*************.co.uk/cgi-bin/MDCompone +ntdisplay.pl?do=clientadvert&t=457&e=457&jobid=61" -->

Replies are listed 'Best First'.
Re: CGI:SSI cookies
by jdtoronto (Prior) on Jan 05, 2004 at 17:52 UTC
    I think you are expecting a little too much of a very simple technology.

    The browser has nothing to do with SSI, the reason you are using CGI::SSI is because the HTTP server will not parse output from a script for SSI directives.

    The SSI functionality will be totally dependent on the HTTP SERVER and how it is configured. If it is able to pass the HTTP header, for that is where the cookie is, (or the HTTP request object in Apache terms) to the called script, then yes. But I suspect this is not normally the case. In particular CGI::SSI is very general by nature and doesn't appear to support server dependent tricks. The author does suggest you look at mod_include and Apache::SSI. But I suspecrt the best way to handle this (and the most portable!) is to read the cookie in the wrapper script and pass its contents to the script providing the content to be included. The 'inner' script will always be sure of seeing the correct information.

    jdtoronto

•Re: CGI:SSI cookies
by merlyn (Sage) on Jan 05, 2004 at 18:01 UTC
    I'd be surprised if that ever worked for two reasons:
    1. SSI is never supposed to go "off box". You can include files using the server-side path, or URLs from the current server only.
    2. Even for URLs, the original environment is unlikely to be passed to the SSI, because the SSI is simply providing additional text to be included dynamically.
    I suggest you restructure your design. Incorporate the functionality of what would have been included directly into your CGI application instead.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      You are right, I am just going to have to write another sub to handle it, inman exec cgi maybe ok however I also need to pass some URL parameters which cannot be done with this SSI command as the script gets the same Query_String as the main script :-(.. Thanks for you help guys and keep up the good work.
        Just to the side... you may want to know that SSI is able to read cookies.. I have found out that it is a problem with IE.. just not sure what problem yet. I have tested the scripts on other computers running the same version of IE and they have worked with no problems. So I just need to work out what is going on with my install of IE.
Re: CGI:SSI cookies
by inman (Curate) on Jan 05, 2004 at 17:50 UTC
    I googled and found this: <!--#exec cgi="ssi.demo.cgi"--> from http://www.weijers.net/guide/ssi.shtml#exec. The CGI::SSI documentation for the exec function looks as though it might execute the included script with environment intact.

    I have no way of testing this so please reply if it all works out!