Again I have to apologise for this not strictly being a CGI/Perl question, but it is related to some extent.

I asked a question some time ago about using AUTH_NAME as a means to login a user into a database application automatically. More specifically, I asked if it was possible to get the AUTH password as well, and I was told it wasn't.

That's fair enough, but it's quite possible to use a small database to get the users password and log them in, in much the same way as cookies do.

Anyway, my question is, would using this method put more of an overhead on the server than using say cookies? Obviously cookies are the standard way of doing things, but isn't this a simple alternative, as well as adding extra security?

Not only that, but it makes it easier to boot an abusive user as well, since you don't have to build a checking routine for *everything* that's protected by this method, for instance subroutines that aren't related to the users permissions on the database. If they don't have their username and password, server-based authentication won't let them at *any* part of the directory contents.

So the basic question is: Will this method of protection add more of a load on the server than more traditional methods? Note that in some cases, such as a portal site, this method will be used throughout the entire site, excluding the registration subroutines.

Thanks,
adam

For a reasonable amount of users, server based authentication will be the quickest and easiest way to provide authentication.

It will also be pretty inflexible. Passing a session id via url or cookie will allow you to do a lot more interesting and custom features..

Cheers,

Alex

>For a reasonable amount of users, server
>based authentication will be the quickest
>and easiest way to provide authentication.
>
What would you consider a reasonable amount of users Alex? Are you talking thousands, tens of thousands, millions? When does it *become* better to use cookies, or does it? The first instance will be a mall or auction application, running quite a few storefronts and categorised products that I think will be quite popular. I think that the server based authentication will not only simplify the process for users and sellers, since all of the users (and sellers) details can be stored in the database, but will give a little more confidence to users browsing the site. Kind of a cross between a portal and a shopping mall, if you will.

>It will also be pretty inflexible. Passing a
>session id via url or cookie will allow you
>to do a lot more interesting and custom
>features..
>
Fair point, but can't the db script that verifies and logs in the user generate a session id to be passed into the url in the process? I'm not trying to sound cynical here, it's a genuine question.

Thanks Alex,
adam

It really depends on what you are doing. If you just want to keep people out, then server based authentication works well and is quick and easy to setup. But if you need to track a lot of user information (say in a member site), then you might as well just build the security into the program. Why have the extra overhead of server based authentication, as well as the overhead of maintaining two user lists.

Cheers,

Alex