>I don't see any security problem from this, but it's a bit
>strange. Are you trying to accomodate some legacy code?
>There aren't many reasons to use local anymore.

I'm not sure what you see as strange: the use of globals in general, or the use of local ?

Regardless:

Q1. Why am I using globals at all; aren't globals evil ?

A1. The code in question is part of some authentication/access control logic which runs structurally identical code in both CGI and mod_perl environments. This means that there's only one code base to make fixes in, add features to, review for security issues, etc. (And that's a GoodThing(tm)).

To simplify the task of writing the code in a mod_perl/CGI independent fashion, I make certain data available via a small number of globals. (There may be a cleaner solution, but I couldn't see one at the time I was writing it).

So globals may be evil, but in this case, they simplified things sufficiently that I'm happy to live with the shame and debasement of my soul.

Q2. Why are globals localized ?

A2. Because globals are potentially evil, in that if one isn't too careful, in the wrong environment, (mod_perl perhaps) their contents may persist for longer than one would wish (and perhaps expose usernames, cookies, etc to another handler). So to mitigate this problem, they've been localized to the dynamic scope of the handler routine, and thus we can (I hope) rely on Perl to undef them at the end of the handler (but leaving them usefully available while the handler is executing)

Does that help ?

Steve Collyer