[Melbourne-pm] Web auth meth
scottp at dd.com.au
Wed Sep 10 16:12:58 PDT 2008
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
* 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
bank) - you have complete control.
> Consider a standard web form that asks for user name & password. It
> tends to have a target of a
> 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
> 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
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
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
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.
More information about the Melbourne-pm