in reply to mod_perl: globals and security question

That looks great to me, since local will restore the value even if handler exits due to an exception (die). My only concern would be threads. I don't know how Perl shares variables between threads, and I don't know how mod_perl works in a multi-threaded Apache.

By the way, you can save yourself some typing by using our. The following code is equivalent to your code, but saves you from typing "NS::" every time you reference these variables:

our (
    $IP_address,
    %params,
    %cookies
);

sub handler
{
    my $r = shift;

    local (
        $IP_address,
        %params,
        %cookies
    );

    .
    .
    $IP_address = $r->connection()->remote_ip();
    .
    .
}

[download]

Replies are listed 'Best First'.
Re^2: mod_perl: globals and security question
by scollyer (Sexton) on Oct 12, 2005 at 15:11 UTC
    >That looks great to me, since local will restore the value
    >even if handler exits due to an exception (die).

    That's what I'd hope, but I feel the need to get the reassurance that it won't fail mysteriously in mod_perl land.

    >By the way, you can save yourself some typing by using our.

    Right. Two comments.

    1. I know about our and tend to use it exclusively these days, but at the time I wrote that code, I was too set in my old-fashioned ways.

    2. Although our can save a bit of typing, it also masks the fact that, say, IP_address, *is* global, and I'm not yet convinced that that's always a good idea. At least if someone sees a package identifier at the start of a variable, they know for sure that globals are being used, and can factor in the potential long-range effects of altering those variables. In short, if you're going to be Evil, then it may be a good idea to trumpet the fact, rather than hide it away.

    Steve Collyer

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom