in reply to Perl-based user manager/tracker for web sites?
Hello,
I am developing a Perl based system for a another project and I think just giving you a full dump of my code would not be helpful but I think I can begin to steer you in the correct path. Of course this is one way to do it, and I am sure many more people can help you but there is nothing for this on the web and I really need to write a web tutorial for the more advanced stuff. Check out OVIDS ( plug plug ) perl site to cover some of the security issues here.
First Assumption: You have a database engine or you can generate some sort of test files on your machine. I will refer to things as SQL for simplicty and I know that works.
Second my friend Bill N. helped me with this and he's on this system so all thanks goes to him.
Newuser reads the user agreement/info page. User clicks on submit Password/Username ect button. After validation ( another topic, CGI script then creates a new record called a LINKCODE ( or statecode or state object if your doing OOP like java servelets ) and it is stored in a table ( remember you could use a text file also ). That statecode has a random unique huge number as its primary key, and the fields in my case are UserID, CurrentPage, Time Expires and Other. UserID comes back from the validation function and I then place that in the new record and for the opening page I place in "main page" in Current Page. Other is used for other stuff that needs to be retained. Time Expires is Current Epoch Time + number of seconds to expiration. But thats another chapter. I then dynamically generate the page that they want to get to and replace a hidden field variable with the linkcode random number.
OK, NOW THAT THE PAGE IS GENERATED:
So now the user is looking at the page that was dynamaically generated and wants to do something else ( like submit a form or something ).
1>If its a SUBMIT BUTTON:
CGI script gets passed to server and Linkcode is sent as well. First thing script does is make sure that it is just a string of numbers ( 10 in my case ). It then checks to see if that code exists in the table. If it does not the linkcode expired or someone is trying to mess with your site and it pulls up a page of Time Expired LOG IN AGAIN!!!. If it finds the linkcode it reads what page it was on and goes down a if-else decision structure of if( $linkcode eq "GetUserInfo" )
it knows that it was the user info page and then goes to a function that looks for the CGI variables from the GetUserInfo page and processes them. This works for forms and submit buttons.
2>LINKS
Ok but thats only for forms what if you want people to click on a link or an image or something. If your limited to the above your out of luck. Put the linkcode in the link www.mysite.com/myscript.cgi?linkcode=1234567890 again dynamically. And when people click on the link CGI.PM will grab the linkcode and go down the decsion tree and generate the next page.
Ok now for Expiration,
Everytime your script runs before it proceses a linkcode it executes a query. It uses Epoch time ( The number of seconds since 1970 ) which you get by the time statement ( read your docs )and if time expired is less than current time it deletes the record. So when the system looks for a linkcode that has expired it has already been deleted by either the current script or someone elses request. This way you dont have to run a script that sleeps for 60 seconds and then runs the same query.
So that's how you lock people out after a set time.
As for an admin interface you can cause the two to have the same login and just have one of the options on login instead of generating the main screen for all users it generates a special admin screen. I have for my system a second account that has the grant and alter permissions that is not easily guessable. It STILL HAS FULL SECURITY THOUGH. But they have to find it even before they can hack it. So it's a double whammy. It also means that if the hack the obvious account yoursite.com. They can't go and look though BOTH your edit your admin code and get you SQL passwords and other goodies. So you at least can still fix things.
Look this is the beginning of an advanced topic in PERL, web interfacing, and web security. This is what I learned PERL for and I am glad I did. The system I decribed is the end of a year long part time project. And it took me a good three months to get ok at the language.
Also, remember I am just an apprentice at this language.
If you have questions I can be reached at patrick@panix.com, who run nothing but Unix boxes and are very cool and love perl.
Good Luck and God Speed,
Robert Patrick Anders
known here as Angel.
Edited Fri Oct 12 19:56:23 2001 (GMT), by footpad
(Added HTML formatting tags and corrected a couple of tiny tpyos.)
|
|---|