Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

User authentication

by Siddartha (Curate)
on Jul 24, 2001 at 18:52 UTC ( [id://99353]=perlquestion: print w/replies, xml ) Need Help??

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

Hi, I am looking for a basic user authentication script that uses cookies.

I have been using Perl for a while now, but still there is a lot to know.

I was thinking of using a crypt() function and check if the entered password is the same as the password in some file. That seems quite easy and straightforward. My problem is that I want to store a cookie, so people don't need to log in the whole time.

I have no idea what to store in the cookie. Just the username? And what about when it expires?

I would love a few examples, like what Perlmonks stores in the cookie. It looks like the Username and an encrypted password.

Is that secure?

I have been searching on the web, and it is scary the crap people try to disguise as password scripts, with the password hardcoded into the script etc.

-Siddartha

Replies are listed 'Best First'.
Re: User authentication
by mikeB (Friar) on Jul 24, 2001 at 19:11 UTC
    Check out merlyn's Web Techniques column # 61 (May 2001) "Basic Cookie Management". It covers the write and wrong ways to use cookies, along with some sample code. The Merlyn Technique Viewer will format this article for you with the code and source interleaved for easy comprehension.
      Thanks

      I had a look and it seems to have everything I need. Will need to think about it a bit, but it doesn't seem like to much of a problem.

      -Siddartha

Re: User authentication
by sifukurt (Hermit) on Jul 24, 2001 at 20:57 UTC
    Personally, unless security is of absolutely no concern, I wouldn't suggest using cookies. Here's an example of what I've done in the past, from a previous node entitled Administration Ignorance

    While I'd be the first to admit that this method is a bit more complicated than cookies, it has enough advantages that I think it is probably worth the little bit of extra programming.
      I just read your referenced node, and I must say, bravo. That seems a pretty simple and very complete way of authenticating some one. I'm going to try that on my next site. Thanks.


      Anyway, no drug, not even alcohol, causes the fundamental ills of society. If we're looking for the source of our troubles, we shouldn't test people for drugs, we should test them for stupidity, ignorance, greed and love of power.

      --P. J. O'Rourke
Re: User authentication
by Snuggle (Friar) on Jul 24, 2001 at 19:51 UTC
    On the few semi-secure (nothing too sensitive) sites that I have worked on, we have always stored the username and crypto password in a session based cookie. This cookie would be persistant for the session only by not setting the expires cookie variable. We would also set a longer term cookie with the username a some simple preferences, so on login the page would display as set by the user. If any changes were to be made, the user would log in and subsequent pages would look for and authenticate the session cookie.

    This allows the user to have "off the cuff" preferences available but includes persistant access after login.

    Hope this helps
    Anyway, no drug, not even alcohol, causes the fundamental ills of society. If we're looking for the source of our troubles, we shouldn't test people for drugs, we should test them for stupidity, ignorance, greed and love of power.

    --P. J. O'Rourke
      Yes this does help.

      It seems to be the best way for this particular case.

      thanks

      Siddartha

Re: User authentication
by traveler (Parson) on Jul 24, 2001 at 21:34 UTC
    This is a somewhat different scenario than merlin's technique as referenced by mikeB above. I have slightly different needs than his column solves.

    What I have done is to send a cookie on initial login that is an MD5 encoding of some information. This gives a random-looking number. I enter that cookie with any related information such as username and browser type into a database. You could use mySQL or whatever. I had to use a commercial Win2K database because it already was part of the project.

    When I retrieve the cookie I can then look up the cookie value in the database to see if the user is allowed to access the site or some portion thereof (I can also retrieve any other user information from the db such as browser type). My db allows multiple cookies per user so a user can log in from different locations and have a "profile" associated with each. In addition I store an expiry time in the db because user accounts on the system expire after a while. I set the cookie expiry time to just exceed the account expiry time in the database. That way the cookie is not saved longer than the account is good.
    --traveler

      Interesting. That's very similar to what I did for a recent small web site. The only real difference is that instead of using a cookie, the hash is kept in a hidden input field on each screen. This works as long as the screen-to-screen transitions are form based (rather than links), and has the advantage that it doesn't rely on user/browser acceptance of cookies.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://99353]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2024-03-29 12:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found