I'm sure I've done something awefull
Awefull, as in "I am full of awe" well yes, because, basically, you can't do that. The environment table is a simple hash of scalars, to put it in terms of Perl. You can't create references to hashes as values of environment variables. If you were brave and insisted on that approach, you could try $ENV{FOO} = "var=$var:foo=$foo:this=$this and then retrieve the information by first splitting on : and then splitting on =. Or regexps, whatever.
But even if that were possible, it still wouldn't help you very much, because setting environment variables in a web process does not mean that you are guaranteed that a given process x that dealt with the initial contact of client y will deal with that same client y in subsequent transactions. This is because of the stateless nature of the HTTP protocol. There is nothing in a client transaction (whether it be a GET, POST or whatever) that ties it to any other transaction either in the past or the future.
To store authentication data, you have to pass an unguessable (read: random) string of bytes back to the client that serves as a unique identifier, so that the next time they return to your site, you know that you have seen them before. The two simplest ways a client has of returning you this unique identifier is either as a cookie, or as a parameter on a POST or GET request.
If that doesn't make much sense, just holler, and I (or someone else) will elaborate (but the fact that you use a hash of hashes indicates that you are not a complete beginner).
btw, it's "environmental"
print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u'
| [reply]
[d/l] |
Thanks for the concern, but I have the state-based authentication all figured out. And just so you know, it is possible to add hashrefs to the %ENV. I've done it nested four levels deep with no problem.
PS: How did I spell "environmental" before?
| [reply] |
And just so you know, it is possible to add hashrefs to the %ENV.
Oops! That will break Perl's multi-platform portability.
%ENV is tied to the operating system's environment handling.
This will definitely break on VMS, as %ENV is implemented in logical name tables, which are strange beasts (to the non-VMS hacker).
| [reply] |
Just ugly in my opinion, not awful. If you're going to use a global variable to store your user object then you might as well make your own instead of using %ENV.
You don't mention using the object across HTTP calls, which is good because as grinder wrote, it wouldn't work anyway.
A module can access a variable in the main script/cgi file by using the $::variable_name notation, or you can fully qualify the name with $MAIN::variable_name. I like better to have a user object and pass it along to functions or to have the user object methods call the other modules functions/methods. Whatever rocks your boat, but leave %ENV alone if you can.
tstock | [reply] |
| [reply] |
If you're looking for a way to pass things like usernames, account numbers, etc. from page to page, Take a look at Apache::Session.
_______________
D
a
m
n
D
i
r
t
y
A
p
e
Home Node
|
Email
| [reply] |