My gut instinct is to store the user identity in a file
associated with a number. When the questionnaire has been
validated, delete the line that contains the translation.
This of course requires that the adminstrator of the script
is scrupulous and does not view the file that associates
number to user. This is a simple way to handle it, and may
or may not be feasible in a RL situation, but you've already
said it's for a class, so in lieu of cookies, that's another
option. This is known as storing persistent data, and while
it's not exactly the cookbook way, it's under the same idea.
(ie - read this to mean, go reread the Perl Cookbook aka the
Ram)
As for your questionN -> N. You could duplicate the data from
CGI.pm and set it up so that:
Update: The code here is flawed, see Re: Re: Re: Urgent help needed by inexperienced programmers to understand why.
@params = $q->param(); # assuming using OO style of CGI.pm
foreach $val @params
{
if ($val =~ /^question(.+)/)
{ $$1 = $q->param($val); }
}
and now they are accesible via just N, well $N to be fair.
Stick around, and you may see better answers. Remember
this is just what first came to my mind.
ALL HAIL BRAK!!! | [reply]
[d/l] |
foreach $val @params
{
if ($val =~ /^question(\d+)/)
{ $questions[$1] = $q->param($val); }
}
which'd give you the question vals in an array, indexed by
N but ... that's only slightly better. Overwrites if N is in
there twice, etc.
a | [reply]
[d/l] |
I'd never do it that way. I was just providing a method
that would meet spec. There's not even a reason to do what
you're suggesting since it's duplication of data (ie -
memory issues). But, some caveats to your code. We don't
know if N will be integer. We presume it will be, but what
about cases 1a, 1b, 1c?
Furthermore, my code has that problem in the case where
$1 = 1. in which case you're evaluating ${$1} -> $1 -> 1;
My answer was to generally push these guys in the
direction proper, and your reply shows why my initial thought
of stripping question from N is bad. I hadn't seen that before a,
thanks.
It appears that a lot of people use the ID number, since
it appeared on another post as magic cookie. I left a lot
of my answer open ended since this is a group project for
school, and I think they should be forced to use their heads
a little. You are correct about the ID being stored on the
questionnaire page, but I figured that it was obvious.
ALL HAIL BRAK!!!
| [reply] |
...can't just tag it on the end of the URL as plain text when passing it between scripts, cos we are required to keep the user identity secure.
I don't know how specific your assignment is, but my suggestion would be to do something like this, if you can:
(Mostly static page w/ form for user name and password, and code to display an error message if one is specified.)
-->
(Script which tests user/pass, and either redirects to first page with login error, or displays questionaire form, with user/pass as hidden vars.)
-->
(Script which again tests user/pass, redirecting to page one on error, verifies validity of questionaire answers, redirecting to page 2 on error, and (if all is well) logs answers, etc.)
Security Issues:
1) Serve this with SSL if possible. Otherwise you're transmitting password data in clear text over the network. If you don't have access to a secure server, this method is no worse than any other (short of a java app implementing PKI, which would probably be a bit overboard ;)
2) Pages containing passwords may remain in browser cache. There are various ways to solve this. The easiest would probably be to have the page which recieves the form submission from the login page set a temporary cookie containing the user/pass data, instead of passing it around in hidden form variables. The validation page would then simply test for an appropriate user/pass from the cookie, instead of from the form.
Another option is the use of a "magic cookie" number. (NOT the same thing as a browser cookie, don't get confused). A "magic cookie" is a random number (long enough to be unguessable) that the server generates when it validates your login. The number is then tied to your identity in a file (or DB, or some more esoteric method of storing data) on the server. The magic cookie is then passed back to the browser in the hidden form variables, instead of the user/pass. The validation script gets the magic cookie, and compares it to the file to find the user. The advantage of this method is magic cookies can be timed out, so If I steal the number from your browser's cache an hour or two after you've used it, it's no longer valid, and I can't impersonate you.
--
Ryan Koppenhaver, Aspiring Perl Hacker
"I ask for so little. Just fear me, love me, do as I say and I will be your slave."
| [reply] |