Using $ENV{'AUTH_USER'}, and (HTTP_PROXY_USER) and (REMOTE_USER) to check what is being pickde up as a user logs in

That's where the catch is. They are defined in Apache documentation, but because of vulnerabilities when programmers rely on them for security, they are usually not set, or not set by default. So you're probably doing a fine job of looking for them, they are just not there, or aren't there in the more recent versions. Try looking for other Apache CGI defined variables, one's that don't depend on who the user is, and that will tell you if your use of %ENV{} is working OK. If it is, then you know that it's just that those particular variables related to the user just aren't there, and it's not your fault.

There's more info on this, if you want, in the Apache updated.

By the way: The best I've been able to do when the user variables were not available was to identify the IP address that the connection was coming from, but I had fixed IP addresses to work with, and you may not be this lucky.

The %ENV hash is deeply magical, and is implemented in whatever mechanism your operating system uses to handle environment variables. Think of it as a tied variable.

In the case of Unix systems, environment variables are inherited by a child process in a fork(). VMS is a more extreme case, with %ENV corresponding to a combination of logical name tables and DCL symbol tables, see perlvms for the gory details.

In context:

In Windows, the environment is passed down by the parent process on creation of the child process. In this case, the parent process is the web server. %ENV simply accesses this environment and works without knowing the meaning of any variables in the environment. Perl simply works with whatever the web server provides. Any differences in the environments are caused by differences in the web servers and/or their configurations. That (not in Perl) is where you should be focusing your efforts.

By the way, AUTH_USER and HTTP_PROXY_USER are extentions to (i.e. not part of) the CGI standard.

From the docs:

ENVIRONMENT

Under CGI the Perl hash %ENV is magical in that it inherits environment variables from the parent process and will set them should a process spawn a child. However, with mod_perl we're in the parent process that would normally setup the common environment variables before spawning a CGI process. Therefore, mod_perl must feed these variables to %ENV directly. Normally, this does not happen until the response stage of a request when PerlHandler is called. If you wish to set variables that will be available before then, such as for a PerlAuthenHandler, you may use the PerlSetEnv configuration directive:

PerlSetEnv  SomeKey  SomeValue

You may also use the PerlPassEnv directive to pass an already existing environment variable to Perl's %ENV:

PerlPassEnv SomeKey

Thanks for the replies and wisdom.
1) no, I'm running IIS.
2) no, just standard Activestate install of perl


I'd already run a foreach on the hash to find what was available, and there is a LOT of stuff there, most of which matches the VBSCript variables, just that the three ways of finding the login id don't see anything.
HOwever, I'll continue the hunt, armed with new knowledge!

I'm sure you've done this, but did somebody check to see if these keys are present in the same mix of upper and lower case on both two platforms?

The reason I ask this is because hash keys are case sensitive, but the case of environment variables is not important to Windows, so Windows and Perl may have different ideas about "identical."

Just wondering, are you running this as CGI or as an ASP application using PerlScript? In the former case then as far as I know those variables ought to work, but just to be sure you may want to try creating a test script that does a little:

print join ' ', keys %ENV;
[download]

In the case of ASP, I'm not sure those environment variables get set. In that case you may have to use $Request->ServerVariables('whatever') to get the values. But I may be wrong.

I've had similar issues with a IIS/ActivePerl mix. One question: Are you running both as Applications? And what kind of AUTH are you running from IIS (Basic, Mixed, NTLM/Windows)?

I think you get the appropriate variables with an Application Instance running BASIC/only AUTH in IIS -- but I can't swear to it, it's totally anecdotal experience.

Does that help any?