[Melbourne-pm] Web auth meth

Tim Hogard thogard at abnormal.com
Wed Sep 10 15:56:36 PDT 2008

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.  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.  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.

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.

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

Any comments on this?



More information about the Melbourne-pm mailing list