[Melbourne-pm] Web auth meth

[Scott Penrose]

Good morning Tim,

On 11/09/2008, at 8:56 AM, Tim Hogard wrote:

>
> Hi perl mongers,
>
> I'm about to start a new project that is somewhat largish in scope  
> and part of the workflow design we have involves using forms to  
> login.  That in its self is about as earth shattering as the LHC but  
> the discussion turned into what framework we intend to use and how  
> we are going do the user authentication.

Are you using Apache?

If YES - then there is only one answer. Use Apache authentication  
modules. Under no circumstance use authentication modules built into  
frameworks.

Why?

* Now you can use any framework.
* You can mix frameworks, even using basic CGI in some places
* You can authenticate static pages
* It is faster
* More reliable
* FAR more secure

The last is the most important - none of your code is run before  
authentication is done. PHP often gets a bad wrap on security, but it  
is not PHP that is at fault, 9 times out of 10 it is just the  
programmer forgot to check some authentication.

And don't fall into the old trap of "But apache can only do Basic  
Auth" - Apache can do any auth !

>  It seems to be that every web browser on the planet know about  
> Basic Auth and most know about Digest Auth and Digest Auth seems to  
> be about secure as anything when used with SSL.

Actually there is no point in using digest auth with SSL. Digest auth  
is useful for non-SSL connections.

But personally I would be using a cookie.

> So why reinvent a session logging system when there doesn't appear  
> to be a need?  So I've been asking around looking for why some of  
> the more complex systems are used.  The biggest reason cited so far  
> is "You can't make a nice looking login form"... hmmmm.... I think  
> thats not entirely true.

Actually it is true for Digest and Basic auth. You have no control on  
that login form - you must use the Browser Built in. But remember it  
is just like using Email login, or FTP login - it is up to the  
application.

If you use cookies (like 99% of the most popular sites, including your  
bank) - you have complete control.

> Consider a standard web form that asks for user name & password.  It  
> tends to have a target of a
> url but if thats a javascript that request http://$username:$pass@mysite/hidden.gif 
>  and then
> goes to the a page (that requires basic or digest auth) then all the  
> user sees it the page and never sees the ugly browser based login  
> window.  The advantages of this type of login scheme include the  
> browser keeping track of the user credentials in as secure of a way  
> as it can, users without javascript can still login (entering their  
> details twice), pages can be deep bookmarked,  scripts using wget  
> and its clones can all get at any content, it works with users  
> behind bad proxies where every request can come from a different IP  
> address, scripts can be written in anything and static pages only  
> need a core web server.

Unfortunately that is insecure. You are now logging the clear text  
username and password in browser history and maybe worse.

But also you will hit some technical issues. For example, browsers  
hate having their name/password changed. Try logging in with basic  
auth (digest is the same, it is just how it is encoded) and then  
change user with the method you mentioned above (just type in the URL.

It will either not change at all, or in some browsers will ask you to  
login again from scratch, or in some will ask you if you want to  
switch users.

And there is no logout.

> The disadvantages seem to be every framework doesn't want to work  
> this way.

One of the great features of moving the auth into Apache is that it  
works with all frameworks.

I really HATE frameworks inventing their own authentication. Or worse  
still, applications all doing their own. There is no need, it is just  
that most people don't realise you can do it separately.

That being said, you may need to write a tiny module (usually a couple  
of lines at most) to allow the framework to detect the user already  
logged in. Most frameworks (e.g. Catalyst) already have this built in.

There is one area unfortunately that you often have to do in your own  
code. And that is access control.

I would encourage you to write your access control modules in Apache  
too - but you can't always do that. For example, the access control  
might be dependent on the data you are reading. Think of a simple  
access control which says that this user can't read any file with the  
word 'poo' in it. Or it may just be too much overhead to access the  
database to work out if they can access this URL. But for the most  
part - e.g. Admin vs Normal user - do the access controls in Apache too.

BTW. When I say Apache - I still mean Perl - just a different mod_perl  
handler.

If you need help or more information, I have written quite a few of  
these - just give me a buzz.

Also - I will be keen on hearing which framework you use. I have moved  
away from frameworks for my recent applications. The main reason for  
this is that most of the intelligence and work is now in Javascript,  
so that the backend access is just some simple business rules  
accessing database or similar and returning AJAX. The reasons for  
frameworks such as "Dispatch" I find easier to handle in Apache  
config. Returning AJAX is a one line code via JSON module.

Scott