Wil,

Back to your original point. I would recommend not storing any login information in client cookies. What I do is the following:

1) Create a client cookie upon successfully logging in. The cookie contains the following info:

a) Domain
b) UserID (not username or password)
c) Expiration info (3 hours)

2) When the user logins successfully (which is a simple check of the User table by username and password), the Session table is propegated with the following info:

a) SessionID (randomized)
b) UserID (from the Users table)
c) Date and Time Created

3) Then in each script, there is a sub call to the "authentication" subroutine in one of the Module files, which checks the UserID in the cookie file against the UserID in the session table.

The above logic is a combination of what GT Links SQL (v.1.X) offers and also from jerrysu who wrote a code hack for modify.cgi awhile back for Links SQL v.1.13. I modified his code hack to only store the UserID rather than Username that he used in his code hack.


========================================
Buh Bye!

Cheers,
Me

Nope...Terms of Agreement (TOA)
========================================
Buh Bye!

Cheers,
Me

Just a quick note,

If you want to not use cookies at all you can pass the Session_ID around on each link / form which eliminates the need to set a cookie. A small percentage of people are weird and do not accept cookies - if you want to eliminate as many client-side problems are possible this may be an option you want to look into.
Cheers,
Michael Bray

>>I would recommend not storing any login information in client cookies.<<

If it is encrypted it is not a problem whatsoever. In order to hack the site you'd still need to know the username and password and encryption seed as I mentioned to Wil .

So I'd say thats more secure than checking a UserID against mysql.

Thanks...forgot to mention that in my revised authentication sub, I do have a check to see if the cookie doesn't exist and I do use the SessionID as another check across the scripts...to eliminate client cookie problems.

Forgot to mention that....
========================================
Buh Bye!

Cheers,
Me

Good point...however, encrypted or not, I prefer NOT to store login information in cookies...yes, encryption helps, but not 100% fool-proof.

Thanks for your input, but I respectively disagree with your approach...the beauty of Perl and other programming languages is its level of flexibility to allow different approaches...some better than others, but to be honest, I think that both of our approaches are secure in their own realm, but it is a philosophical difference in our approaches...so, there is no need to argue or belabor this point further.

And I was simply providing Wil with additional food for thought.

========================================
Buh Bye!

Cheers,
Me

Thanks for the food. I'll much on both and see where I come up with.

Cheers

- wil

>>so, there is no need to argue or belabor this point further. <<

Theres no harm in a healthy discussion and everyone providing different ideas. No-one is arguing which is good.

>>the beauty of Perl and other programming languages is its level of flexibility to allow different approaches<<

Exactly. It's personal preference and if we have different ways of approaching something theres no harm in that - it makes the world a better place.

Correct...And I noticed that you edited your post. I think it is more secure to check a field/column that is not used in the login form at all, thus using the UserID. Your comment about checking for the UserID not being secure in MySQL is not correct, IMHO.

Again, both of our approaches _are secure and thus Wil can choose which method best suits his needs. Stating that my approach is "not secure in MySQL" is not correct, IMHO.

As always, Paul, I think that we view things quite differently in the world and I am learning to become accustomed to you always questioning and disagreeing with my statements. Neither of our viewpoints are necessarily right or wrong, but you see black, while I see white. I think it chalks up to more than personality differences.

I look forward to our continued "friendly" disagreements about everything since we can never see eye to eye on anything.

Have a great day.
========================================
Buh Bye!

Cheers,
Me

The only thing I edited was to change ID to UserID in my post above. Anyway its not important.

>>I am learning to become accustomed to you always questioning and disagreeing with my statements<<

Ouch, thats a little harsh. I think you summed it up with:

I think that we view things quite differently in the world

....and it wouldn't be surprising as we are on opposite sites of the world with different religions etc....but that shouldn't be an excuse to disagree about everything.

>>I look forward to our continued "friendly" disagreements about everything since we can never see eye to eye on anything.
<<

I'd like to think there wouldn't be any more arguments and we could just accept our differences.
I've seen a nicer side of you in this thread....I'd like to see more.

Damn I sound like some kind of peace maker

And I would love to see you more respectively disagree with me rather than belitting me like you have had a tendency of doing. Yes, accepting our differences without belitting or berating each other would be nice, Paul, now wouldn't it? I am willing to give it a shot if you are...

I wasn't being harsh, just being honest, which BTW is my worst trait, because I don't mince words and don't sugar coat..not my style. Yea, you can attract more bees with honey than vinegar, yada yada yada...and on the Net, my "sarcasim" is often mistaken for being condescending, which is not my intent.

Anyway, I will continue to make an effort to be more patient with your posts, which I can always count on including disagreeing remarks about anything that I post.

Good bye.

========================================
Buh Bye!

Cheers,
Me

This thread brings a tear to my eye ;-))

- wil

Removed after a rethink.

Hi,

I would recommend one of the following:

1. Easy way:

Set a cookie with username=username, password=crypt(password). At the top of your script before anything else, make sure you have the cookie, and that there exists a user and password that match.

2. Better way:

You'll need a sessions table that looks like:

username char(50),
session char(50) not null primary key,
session_time int,

When a user logs in, generate a random session string, and insert it along with the value time(), and the username into the sessions table. Then return a cookie with session=$session that you just generated.

Each request, do a SELECT username FROM sessions WHERE session = ?, and check that the session they pass in is valid.

You also need to remove old sessions using:

DELETE FROM sessions WHERE session_time < $time

where $time is time() - 3600 for 1 hour sessions. This has the advantadge that you control how long sessions last, not the browser, and does not store any infromation about the user on the clients machine.

As for SQL queries, don't be afraid about using them. If you have a properly optimized query, the time it takes to execute is negligble. You want your SQL server to do the hard work, that's what it is there for.

Cheers,

Alex
--
Gossamer Threads Inc.

Thanks for the reply, Alex. Your second option is the route I'm currently going down, thank you all for your input.

The only thing that really got me was that I needed to check for Authentication at the beginning of every sub. I really wanted to do this check once at the very top of my script so that it occurred whenever the script was called. The problem with this was that people who had never logged in would never be able to, and that's where it really hit me.

Thanks for the side note about SQL. I've heard a few people tell me that lately. ie, it's best to let the SQL server do the work rather than figure out a way to do it in Perl. If you can do it in SQL, do it, like increment numbers etc. This is supposedly faster?

Rgds

- wil