homepage Welcome to WebmasterWorld Guest from 54.234.2.88
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / Perl Server Side CGI Scripting
Forum Library, Charter, Moderators: coopster & jatar k & phranque

Perl Server Side CGI Scripting Forum

    
question on login/logout
Terrysun




msg:3892590
 1:55 am on Apr 15, 2009 (gmt 0)

Hey, guys
I am trying to write a login/logout part for my project, after user login, they can do something on their authentication area, and i need to check if they have logged in or logged out, if they logged out or haven't done anything for a long time, they will redirect to login page. For user authentication, i need to get user name and passwrod pair from MySQL DB and check.... my questions are:

1. what can i do to check if user still validated b4 they want to do something on their authentication area.

2. For user authentication, should i write a CGI to access MySQL DB directly, or using any modules (like i found mod_auth_Mysql, seems it's useful,i am not sure) to do authentication without accessing DB directly. Which way is better? what's difference?

Thanks!

 

MichaelBluejay




msg:3894222
 1:50 am on Apr 17, 2009 (gmt 0)

(1) This kind of problem is exactly what cookies are for. Once a user has successfully logged in (you've checked their form input against the database), set a cookie in their browser.

The cookie (name/value) pair should be (username/secret code), where the secret code is some 10-character or so code you created when the user registered, and which you stored in that user's record in your database. Every time the user runs any script, the script reads the cookie, and checks the database to make sure the user & secret code match.

(2) I'm not sure what you're asking here. I have users log in with a simple HTML form, then have a CGI script that checks their input against what's in the database (and sets a cookie if their input matches the database).

rocknbil




msg:3895194
 3:07 pm on Apr 18, 2009 (gmt 0)

1. what can i do to check if user still validated b4 they want to do something on their authentication area.

On every request to this script, authorize.

-- first look for and read the cookie, see previous. There should be at least two cookie values, user id and password (and you could do a third for the session id.)
-- if cookies are not present, look for form input values of user name and password.
if neither are present, return to log in screen.
-- if the cookie is present, the user id should be the numeric ID of the record; take this and the input values of the cookie set for password and compare against what you get from the database for password (see below.)
-- if the cookie is NOT present and the form values are present, you will be looking up not the record ID, but either the login name or email address and password, but also get the numeric record ID at this time. If this is found and validates, you now set the cookies using the record ID and the user password value (see below!) and next time it validates it will be using the cookie and won't need form values.

See important notes after #2 . . . .

2. For user authentication, should i write a CGI to access MySQL DB directly, or using any modules

I've always used the DBI module, there may be others but have never needed anything else. On any system with mySQL, it's always been in place, but you can install it via command line with: cpan DBI

About authentication: I'm by no means a "Security expert" but authenticating with passwords, whether you use a plain text or formal database, can take two "basic" forms.

The first, and probably easiest, is something you only want to do for low security, non-sensitive information. Do not do this if the login services are paid or contains any sensitive information.

On register, you create a record containing a unique numeric "user id," optionally a "login name," and email address, and a plain text password. There is only one reason you would ever do this: to allow a simple "retrieve password" function. If someone enters only the login name/email, you write a program that looks it up and emails them the login info. This has security vulnerabilities all over it, so it's very important you don't do this for anything serious. It's sufficient for say, portions of your portfolio you want to hide from the general public. Customer info, email addresses, no, not sufficient.

Only when the convenience of "retrieve password" is more important than security, which is rare.

The other is that you never store the password in plain text. A simple method (but not completely secure, Google md5 security) is when you initially input the password, you create an md5 hash of the password, and store it's resulting value. When the user logs in next time, you can a) use Javascript to immediately create an md5 so that what gets submitted is NOT the clear text of the password but it's md5 equivalent, or b) go ahead and submit a clear text password, but do so only over https, and when submitted, your perl script creates the md5 before storing the password.

When you set the cookie, you will set the md5 hash, or better yet, an md5 of the md5. :-)

You can't "decrypt" the md5. All you can do is compare one md5 against another:

testme -> md5 = 3skaffglgf56ffdkgdf

database -> 3skaffglgf56ffdkgdf

So in this scenario, you lose the retrieve password capability. This is fine. What you do is have a function that resets the password to something random and emails the end user the new password with instructions to reset it again after first login.

These are not "high security" methods and I'm posting them to lure better programmers into discussing their approaches. :-) It's been discussed that md5 is not all that secure, and is (relatively) easily broken by brute force attacks and there are more robust encryption methods. But for you as a beginner, it's easily accessible (part of the perl distro) and these provide a good foundation for you to start looking at a solid way to create a semi-secure login.

A last note on cookies themselves: Always make them expire, except in scenario 1, or make it an option to "remember me." The second is not a "great" idea . . . but sometimes user convenience wins out over security.

Terrysun




msg:3896137
 2:42 pm on Apr 20, 2009 (gmt 0)

thanks guys for giving me such detailed answer~~ and i can keep moving on my project. :-) As i move on, a new program just came out :-). After login, different content will show up for different users, that means i have to output dynamic content, i don't want to put the HTML code into my CGI script (it is suck!, u think so?). I done some search and found that HTML::Template can handle that, but i think that it is not easy to maintain the code and if i have lots of pages, i got lots of template files (>.<). Is there any better way to output dynamic content? (sorry to bore you guys if it is a stupid question)

crevier




msg:3902347
 1:22 pm on Apr 28, 2009 (gmt 0)

Just putting in my two cents that rocknbil's response is fantastic. It provides a great foundation on the basics of handling user authentication. Thanks!

chorny




msg:3912935
 8:45 pm on May 13, 2009 (gmt 0)

Any good framework like CGI::Application or Catalyst will have this already implemented.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / Perl Server Side CGI Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved