Argh. I can't get my head around the logic behnd authentication someone to use a script.

I currently have a sub called &check_credentials; at the top of my script which is called before any other thing happens. This basicaly checks to see if you've got a cookie. If not, returns you to an error page.

However, I can't ever login now because it alwasys takes me to the error_sub because I don't have my cookies.

Argh :-\

How do others make sure that a user is authenticated at every page he or she visits? But keeping overheads down? In my authentication sub it only checks to see if a cookie exists - I don't want to make a database connection to verify the cookie as this would have to be done for every single page loaded. Is this OK?

Cheers

- wil

Can you make some sort of session system? Otherwise you would just use the one connection on the login page that sets a cookie.

Do a query, select username from USERTABLE where username='$username' and password='password'

a result means they placed the correct login details in. Set a cookie with the username in it as the value. If the cookie exists they are logged in, and you can get information about them on each page if you want cause you have there username in the cookie.

A session system is usually a good option...
Cheers,
Michael Bray

Yeah, what I do now is when the user logs in it sets the username and password to the cookie.

But because it checks for a cookie before an subroutine executes in the script, it produces an error and never displays the login page - because there haven't been any cookies set the first time you visit?

- wil

The way I do it is I set a cookie when someone logs in containing a non-encrypted username and an encryted password. It expires in two hours.

Then I have a module to do the authentication. On the pages that only member should be able to access I do:

my $REC = Module->auth;

This check the cookie and compares it to the user record in the database. Doing this once per page is not going to slow things down. If the user is valid auth() return the user record as a hashref so I can send $REC to my template parser and put corresponding tags in my templates like: Welcome <%Username%> ....if they aren't authenticated they are taken to an error page with:


This works nicely. When the cookie expires they are logged out.

Thanks for the reply. Does that mean you make a call to my $REC = Module->auth; at the top of every sub?

I was trying to avoid this by putting this once at the very top of my script but then encountered errors for people that weren't logged in but were trying to.

- wil

Why set the password in the cookie?


Thats just non sense writing there - but something along those lines written into a perl sub routine and then placed on the top of each page should work?
Cheers,
Michael Bray

Sorry - didn't see paul had replied. i started the reply during an ad on tv and finished it during the next ad break. paul's method is probably better... but why not set the cookie to expire in 2 hours and not do a check on each page in the DB?
Cheers,
Michael Bray

I'm not writing the password now, I realised that was a bad idea. I just write their username and a 0 or 1 to indictate if they are logged in or logged out.

I'm doing something very similar (but very simple now). At the top of each page there is a call to &check_credentials; and then in check_credentials there is simple code:


The cookies do expire in 2 hours, anyway.

- wil

My method leads me to the question.. Can someone set a false cookie? In other words, my cookie looks like this:


Now would it be possible for someone to write that exact script on their own server and set a cookie for a different server? Ugh, I'm not very good with my English.

Is it possible to set a cookie for a server other than the server the script executed on. If so, it would be very easy to pass my system, right?

- wil

>>but why not set the cookie to expire in 2 hours and not do a check on each page in the DB?
<<

Because anyone could then create a fake cookie and gain access. By setting the username/password in the cookie I can make sure they are really allowed to access the members area.

Module->auth is like 10 lines of code so calling it isn't going to make any real impact on execution speeds. It isn't needed in routines producing welcome pages and pages that non-members can access, it is only needed at the top of routines producing member pages.

To check a cookie and select a record from mysql takes milliseconds so it isn't going to be noticed and gives greater security.

Yeah, but if you're running a busy site, with each page calling a MySQL call to checj authentication then you're looking at big overheads?

- wil

Yeah - I didn't think about people faking the cookies. I use PHP's built in sessions. They are stored on the server so I don't need to worry about people faking them.

Store username and password in the cookie and do a check on each page - or better yet, use sessions :)
Cheers,
Michael Bray

>>Yeah, but if you're running a busy site, with each page calling a MySQL call to checj authentication then you're looking at big overheads? <<

Not at all. One query is almost negligable....take GossamerForum as an example.....127 queries alone for the main page and thousands and thousands of hits per day.

Jeepers, why so many queries for the GT forum?! :-)

OK. So can a cookie be faked? Can I set a cookie for a server that is not mine or not from where the cookie orignated?

- wil

Is there a similar session thingy in Perl? Or I guess I would have to make a seshion table in a database? But I'd still need cookies for that..

- wil

>>So can a cookie be faked?<<

Easily. Alex posted some code a while back to do it. So with my method faking a cookie would be useless as you'd still need to know the username/password and encryption seed to be authenticated.

Ok it was 108, take a look:

http://www.gossamer-threads.com/...h_string=127;#174277

So mine can easily be faked. All you need is to know someone's username. :-(

I hate this.

- wil

Paul,

Just because GForum had 127 queries does *NOT* make it good practice. 127 queries puts a huge load on a program like MySQL - a busy forum could potentially have a few simultaneous people load the main page. Imagine MySQL getting 400 queries all of a sudden, even if they are simple queries the sheer number is going to cause problems.

You should aim to minimise the total ammount of SQL queries per page to reduce load and produce fast pages. I was talking in another thread somewhere about each query adding up - and optimising code etc and how one 10th of a second etc does make a difference. Think about having that ammount of queries, plus loading up all the code, plus processing all the code etc - it is going to be quite slow.

Cheers,
Michael Bray

Hmm. I wonder why there are so many queries on the main page. I can only cound around 70 queries needed (to extract information from the database, such as description and titles, last post, usernames).

BTW: Is the detach thread moderator option done yet? :-)

- wil

>>Is the detach thread moderator option done yet?<<

Yup.

>>Just because GForum had 127 queries does *NOT* make it good practice. 127 queries puts a huge load on a program like MySQL<<

Take a look at the link I pasted for Wil where Alex comments about the speed of mysql.

Im obviously not suggesting someone use 127 queries unless they need to :)

However...one query, selecting one row from mysql to authenticate someone, has benefits that outway adding 0.001s to the execution time

Yeah I know that :) I like to make optimised code - but I am realistic with things like that. Saying 127 queries is not good practice was a general statement rather then for this specific case.
Cheers,
Michael Bray

And to add to this post, GT is on a dedicated server. If you're on a virtual server, it is best to reduce the amount of queries in your scripts, so that you do not abuse hosting company's TOAs.
========================================
Buh Bye!

Cheers,
Me

TOA? You mean TOS?

- wil