4 ms·

That will only work if every page contains a login form. Many websites prefer to put the login form on its own page. Introducing new input elements and HTML se

by kijin 13y ago

That will only work if every page contains a login form. Many websites prefer to put the login form on its own page. Introducing new input elements and HTML semantics will also require a lot of code to be rewritten, whereas a custom header can be implemented with a one-liner that you put in your .htaccess or webserver config file, or a turnkey plugin for most content management systems. The goal is to produce something that can be grafted onto virtually every existing website with the absolute least amount of code change.

StavrosK 13y ago
I don't see how adding one to three lines of HTML is harder than adding a custom header, and I certainly don't know what you mean by "will require a lot of code to be rewritten". You stick it in your templates. If anything, a custom header is worse because it's too separated from the actual URL. I can't automatically update that file if I change the login URL, but I can if it's in the template.
- da_n 13y ago
  You wouldn't need to have the header point to a log in page though, you would just have the server handle the post request sent from the browser (or plugin).
  - StavrosK 13y ago
    Yeah, by "login URL" I mean the URL that handles the POST, the one that's in the header.
    - da_n 13y ago
      Right I see what you're saying, looks like I misread the article a bit. For me it would be an ideal implementation if there could also be some callback functionality, that way it doesn't just have to redirect to a login url the logic can be handled natively (wrong password > try again, success > reload page etc). Even better, instead of pointing to a login page, you could specify a different auth scheme and just point to a JSON or XML file with the various field etc. Whichever way, it isn't going to be utterly trivial I will agree on that.
- kijin 13y ago
  At the very least, you might need to edit the script that handles the POST request, in addition to the login form template. We're programmers so it sounds trivial to us. But it's already way too much for everyone else, because the average website owner will not spend any time trying to locate the POST request handler in the spaghetti PHP that his nephew wrote 5 years ago (and who knows what else will break if he edits that file). I think a common login interface is important enough that we can't wait for the majority of websites to fix even a few of lines of code. (Does WordPress even allow plugins to modify the field names on the login page? It certainly allows them to add custom headers.) Copying and pasting a "Header add" one-liner in your .htaccess file requires 10x less programming skill and carries 10x less risk than rummaging around in a bowl of pasta, so it's much more likely to see widespread adoption. We could even open a service that crawls a given website and suggests reasonable values to put in their .htaccess files, for people who want the shiny new Login button to work in their websites. I also don't see how it would be any more difficult for experienced programmers to update a header than it would be to update a template.

by kijin 13y ago

StavrosK 13y ago

I don't see how adding one to three lines of HTML is harder than adding a custom header, and I certainly don't know what you mean by "will require a lot of code to be rewritten". You stick it in your templates. If anything, a custom header is worse because it's too separated from the actual URL. I can't automatically update that file if I change the login URL, but I can if it's in the template.

da_n 13y ago
You wouldn't need to have the header point to a log in page though, you would just have the server handle the post request sent from the browser (or plugin).
- StavrosK 13y ago
  Yeah, by "login URL" I mean the URL that handles the POST, the one that's in the header.
  - da_n 13y ago
    Right I see what you're saying, looks like I misread the article a bit. For me it would be an ideal implementation if there could also be some callback functionality, that way it doesn't just have to redirect to a login url the logic can be handled natively (wrong password > try again, success > reload page etc). Even better, instead of pointing to a login page, you could specify a different auth scheme and just point to a JSON or XML file with the various field etc. Whichever way, it isn't going to be utterly trivial I will agree on that.
kijin 13y ago
At the very least, you might need to edit the script that handles the POST request, in addition to the login form template. We're programmers so it sounds trivial to us. But it's already way too much for everyone else, because the average website owner will not spend any time trying to locate the POST request handler in the spaghetti PHP that his nephew wrote 5 years ago (and who knows what else will break if he edits that file). I think a common login interface is important enough that we can't wait for the majority of websites to fix even a few of lines of code. (Does WordPress even allow plugins to modify the field names on the login page? It certainly allows them to add custom headers.) Copying and pasting a "Header add" one-liner in your .htaccess file requires 10x less programming skill and carries 10x less risk than rummaging around in a bowl of pasta, so it's much more likely to see widespread adoption. We could even open a service that crawls a given website and suggests reasonable values to put in their .htaccess files, for people who want the shiny new Login button to work in their websites. I also don't see how it would be any more difficult for experienced programmers to update a header than it would be to update a template.