How to easy transfer parameters betwen html pages.

LiTinOveWeedle has asked for the wisdom of the Perl Monks concerning the following question:

Perl bless you, my brothers,
I want to found only idea how to do something to work. I am working on system which using hmtl pages with forms which are processed by perl script. I want to do this: Once user log into this system, each time he submit form, I want to call script with his user login information (maybe with input hidden field = username...) So as user browsing through .html pages system must still remember user login information.

Only one idea, which I founded, how to transfer user login information between pages through all system, is made index as .pl script which can call and view all .html pages dynamically, with some changes in source code (it can insert in form part hidden field with user login name.... ).

Second idea is make this with SSI but I dont know how to identificate user to insert right data into form fields which SSI insert....

If you know, how do this simlier, it help me so much.
Thanks and Perl be with you.

Li Tin O've Weedle
mad Tsort's philosopher

Comment on How to easy transfer parameters betwen html pages.

Replies are listed 'Best First'.
Re: How to easy transfer parameters betwen html pages. by Chady (Priest) on Mar 18, 2001 at 18:51 UTC
I know what you are talking about because I ran into that problem myself now that I'm re-designing my website The way that I worked it out is your first idea, although I'm not using logged in users.. so I have some comments about that: For security reasons try to avoid the fields inside the html pages, although it is hidden.. but people can see it... so you might not want to include secure information there. and unless all your navigation is done using buttons to POST the form, your links will contain all the data as GET strings. I think that the best way to do this is to use cookies; but then again you will have to make all your users enable cookies in their browsers, but I think that it is a more "secure" (?) way for it, so your users can specify if they want to stay always logged in, or not. You can insert the right SSI now using information provided by the client cookie. This might not be perfect, but I thought I'd share my idea. He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.	[reply]
(ar0n) Re: How to easy transfer parameters betwen html pages. by ar0n (Priest) on Mar 18, 2001 at 19:24 UTC
See Adding "state" to HTTP. [ar0n]	[reply]
Re: How to easy transfer parameters betwen html pages. by wardk (Deacon) on Mar 18, 2001 at 22:10 UTC
the method I have used a number of times for security handling is a combination of cookies and password/identifiers. It is not by any means industrial strength protection... User logs in via CGI validation if validated, CGI encrypts secret info, stores encrypted string in cookie, also save other non-scure stuff in clear unencrypted cookies, like an ID. every time user hits site, CGI nabs id and encrypted cookie, uses ID to get secret info (local source, user flat file, database, whatever), encrypts secret info (using same salt used in first encryption). compares new encrypted string against cookie version. if two encrypted strings match, user is allowed in, else bounce to login screen SSL would make all of the above much safer as the initial login would not be in the clear. good luck!	[reply]
Re: How to easy transfer parameters betwen html pages. by astanley (Beadle) on Mar 18, 2001 at 21:40 UTC
I agree with Chady that storing any secure information via hidden fields is not the best idea. Someone up to no good could use this as a way to brute force for other working login / passwords. The other option nobody has covered yet is to work with Sessions. I ran into this problem when designing a virtual host control panel for a client. The difference was though I couldn't use hidden fields as not all page navigation was through forms. What I did in the end was create a MySQL database that stored the information I wanted to save along with a unique session ID number. This session ID number is what I passed along through the pages and through the HREF navigation sections. Then for each loaded page I had the script check back into the database and retrieve the information stored for that particular session ID and verify it. You can make the session ID a long string of characters and numbers to make it hard for someone else to guess one. You must make sure that you remove the session ID's from the database promptly once the user has left the site, however, or you'll have a whole nother security problem with people trying to guess session ID's all day. I got around this by creating a timestamp field in the table and everytime the user went to a new page this field was updated to the new time. I then wrote a quick cron script to run every minute that would check the database for expired sessions (sessions that haven't updated the timestamp in say...5 minutes). Hope that helps. Adam	[reply]
Re: Re: How to easy transfer parameters betwen html pages. by merlyn (Sage) on Mar 18, 2001 at 22:15 UTC
My upcoming WebTechniques column (not yet in print, so not in the website) talks about "branding" a particular browser with a cookie, and then associating that cookie with a user for a time-limited period of time, with the association maintained server-side so there was no chance of spoofing the server. It's actually quite simple with File::Cache. Took about 40 lines of code. Maybe I'll post it as a snippet. -- Randal L. Schwartz, Perl hacker	[reply]
Re: How to easy transfer parameters betwen html pages. by Starky (Chaplain) on Mar 19, 2001 at 00:43 UTC
The way that almost all commercial-grade application servers do it is to create a unique string (e.g., based on a call to crypt() of a combination of the return value from time() and the user's IP address) and associate it with the user by an entry in, say, the session table in the database. Then that session string is attached either via a CGI parameter or a cookie. Forcing users to accept cookies is so common these days that you really won't lose traffic by storing the session information in a cookie. Since there is no private information stored in the session string, it really doesn't matter whether you use CGI parameters or cookies. Certainly avoid at all costs putting user information such as user name or password in CGI parameters. It's about as flagrant a security hole as there is. Might as well just put all the user names and passwords on the login page for reference. Hope this helps, -Me	[reply]