Re: Re: CGI Session 'security' for in-house app.

It's not really the same problem in Perl as in other languages. TECO, for instance, doesn't have a nice set of CGI modules to choose from. Any language/library set will work better with particular methodlogies, and less well with others.

HTTP authentication does not, to my knowledge, facilitate expansion to session data management. This is also the reason for the expiration time. The short duration is simply based on the expected usage patterns. Not using any expiration time would allow the possibility - admittedly remote - of reuse (by regeneration) of the session key. It's simply a means to keep the database 'clean'.

Comment on Re: Re: CGI Session 'security' for in-house app.

Replies are listed 'Best First'.
Re: CGI Session 'security' for in-house app. by Abigail (Deacon) on Jul 06, 2001 at 01:34 UTC
It is the same problem, because the problem as stated didn't ask for which keystrokes to type but asked about the algorithm. The algorithm (as opposed to the implementation, of which 0% appeared in your question) remains the same, regardless of the language used to generate the HTML. You are right that HTTP authentication doesn't expand to session data management. Nor does it make coffee. However, your stated problem was "how to keep curious employees from entering data". And while creating sessions is one way of solving it, it doesn't mean you need sessions at all to solve your problem. If, beside keeping curious employees from entering data, you do need sessions, you should have asked about how to make sessions - and not mention the curious employees at all. After all, after solving the session problem, the curious employees have been taken care off. Not using any expiration time would allow the possibility - admittedly remote - of reuse (by regeneration) of the session key. But that's why you use HTTP level authentication.... Of course, if someone goes into the trouble of trying to regenerate a session key, would you still classify them as "curious employees stumbling upon the site entering data by accident"? I would classify them as "malicious hackers" (or "crackers" for slashdot types). -- Abigail	[reply]

Replies are listed 'Best First'.

Re: CGI Session 'security' for in-house app.
by Abigail (Deacon) on Jul 06, 2001 at 01:34 UTC

algorithm

You are right that HTTP authentication doesn't expand to session data management. Nor does it make coffee. However, your stated problem was "how to keep curious employees from entering data". And while creating sessions is one way of solving it, it doesn't mean you need sessions at all to solve your problem. If, beside keeping curious employees from entering data, you do need sessions, you should have asked about how to make sessions - and not mention the curious employees at all. After all, after solving the session problem, the curious employees have been taken care off.

Not using any expiration time would allow the possibility - admittedly remote - of reuse (by regeneration) of the session key.

But that's why you use HTTP level authentication....

Of course, if someone goes into the trouble of trying to regenerate a session key, would you still classify them as "curious employees stumbling upon the site entering data by accident"? *I* would classify them as "malicious hackers" (or "crackers" for slashdot types).

-- Abigail

[reply]