4 ms·

You make valid points, but I think that some of them could be addressed to improve the current situation. 1. Allow the server to dictate to the browser some cu

by rgejman 16y ago

You make valid points, but I think that some of them could be addressed to improve the current situation. 1. Allow the server to dictate to the browser some customizations of the dialog box. For instance, the server could instruct the browser where "Forgot Password" or "Forgot Username" links should point. In their absence, the browser does not present those links. The same could be done for "logout" links that can appear somewhere in the browser toolbar if you're logged in (see #2). 2. Just like session information, basic authentication information must be sent from the browser to the server every time a resource is requested. State is trivial to manage: if the server returns 401, the user is not logged in. If the server returns a 200-series response, then the browser knows that the username/password work and can display a modified url, as someone suggested, ala "http://rgejman@news.ycombinator.com/resource. http://rgejman@news.ycombinator.com/resource. The browser continues to show this as long as the last page visited gave a 200-series response. Changing who is logged in thus becomes trivial: click on the username in the url and you get the option to login as another user. This prompts the browser to refresh the current page with the new basic auth info, etc. You can still track state using sessions, but now you have nice separation of functions. Basic auth is used for managing authentication and sessions are used for tracking state. Much more elegant this way IMO. 3. Digest auth is a nice security win only insofar as you don't have to transfer passwords, but I agree that SSL is really the way to go. Why can't you do SSL + basic auth? 4. Multi-factor auth is a good point, but not insolvable. It needs some hard thinking to do well, but it could be done in an elegant way. I can elaborate if you're interested. 5. I think web forms have a lot of problems, most notably the lack of standardization. My parents often have trouble locating the login/registration/logout pages on websites—and I have seen many others with the same problem. Allowing this to be handled by the browser would lower the learning curve for many people and allow them to use a variety of websites without difficulty.

tptacek 16y ago
This is a thoughtful comment, and I modded it up, but I can't resist saying this: your proposals basically suggest that we accept a lowest-common-denominator CRUD-app style login model and then bake it into the browser. We'd do that, freezing out any innovation or flexibility in login design, in order to... catch up to where we already are with forms. There are definitely crappy login forms. So what? If an app can't clear the usability hurdle of getting people logged in, it's certainly not going to clear the (even harder) hurdles of "doing something useful for the user". In the end, many hundreds of millions of logins happen by all sorts of users every day. Lack of login-page standards doesn't seem like a real problem.
- rgejman 16y ago
  Your first point is excellent. But I'll raise you one. What if a login/logout cycle were made generic and could include several steps. The server says "401. You've got to login. I need a %username% and %password% and then I'm going to ask you one more thing." The browser asks the user for the username/password and then hits up the server with the response. If the authentication of u/p is successful it says "display this HTML doc and send me the result for final validation." That sort of a model could work for both standard username/password setups and multiple-factor authentication. It's standard, flexible, predictable and you never have to search for it on an unfamiliar website. As for your second point: there are plenty of websites that are difficult to login to even though they are used by millions. Try Citibank for one particularly bad example.
user24 16y ago
> Allowing this to be handled by the browser would lower the learning curve for many people and allow them to use a variety of websites without difficulty. I agree that it would make it easier to use, but so would allowing the browser to handle site search, and comment posting, and link presentation... Where do you draw the line?

by rgejman 16y ago

tptacek 16y ago

This is a thoughtful comment, and I modded it up, but I can't resist saying this: your proposals basically suggest that we accept a lowest-common-denominator CRUD-app style login model and then bake it into the browser. We'd do that, freezing out any innovation or flexibility in login design, in order to... catch up to where we already are with forms. There are definitely crappy login forms. So what? If an app can't clear the usability hurdle of getting people logged in, it's certainly not going to clear the (even harder) hurdles of "doing something useful for the user". In the end, many hundreds of millions of logins happen by all sorts of users every day. Lack of login-page standards doesn't seem like a real problem.

rgejman 16y ago
Your first point is excellent. But I'll raise you one. What if a login/logout cycle were made generic and could include several steps. The server says "401. You've got to login. I need a %username% and %password% and then I'm going to ask you one more thing." The browser asks the user for the username/password and then hits up the server with the response. If the authentication of u/p is successful it says "display this HTML doc and send me the result for final validation." That sort of a model could work for both standard username/password setups and multiple-factor authentication. It's standard, flexible, predictable and you never have to search for it on an unfamiliar website. As for your second point: there are plenty of websites that are difficult to login to even though they are used by millions. Try Citibank for one particularly bad example.

user24 16y ago

> Allowing this to be handled by the browser would lower the learning curve for many people and allow them to use a variety of websites without difficulty. I agree that it would make it easier to use, but so would allowing the browser to handle site search, and comment posting, and link presentation... Where do you draw the line?