Re: [whatwg] New HTML5 Form type

2011-10-27 Thread Robin Aaberg Garen
I very much encourage this idea.

I fret frequently when I see the unsupported features of the HTTP protocol
not being used because of missing support in browsers and servers. Like the
PUT and DELETE.  And this enchancement of the AUTH.

A more seamless integration of the HTTP AUTH to the client side of the HTTP
protocol as suggested in the letter in which I'm replying to would be great.
This is my humble oppinion as a young web-developer.

Best regards

Robin G. Aaberg
Last year student in Communication technology @ Bergen University College
Proud member of Communica.


On Sun, Oct 23, 2011 at 3:47 AM, Michael Herold
her...@physik.fu-berlin.dewrote:

 Hello,

 i want to discuss some thoughts on the html form element (see below).
 If somebody thinks this idea might be useful I would continue to check
 how a implementation of this feature would be possible and what the
 technical difficulties would be.

 I have no idea if there is a way to bring this to HTML5 or commit this
 in any other way to the W3C.

 Best wishes, Michael

  **Suggestion**
 Add a new possible value auth to the HTML form //method// attribute.
 If input elements named username/password are present they are used to
 authenticate. Otherwise the first input element is used as username and
 the first input[type=password] element is used as password.

 It may be useful to interact with the http-status as the browser needs a
 //nonce// for digest auth.

 The aim would be to create custom login and logout dialogs without
 JavaScript.

  **Thoughts regarding authentication**
 Today there are three common ways to authenticate using HTTP: GET,
 cookies, HTTP-Auth.

 **GET**
 Putting a session (+user) in the get.
 - copy+paste and visual access can steal login
 - have to depend on users ip to add a bit of security
 - supported by every browser
 - the website has to adjust every link for every user
 - the url gets unreadable

 **cookies**
 Putting a session (+user) in a cookie.
 - can be implemented with sufficient security
 - broken by standard (none standard SLD fix in every browser)
 - disabled or not supported by many clients for various reasons
 - leaves footsteps on hdd per definition

 **HTTP-Auth**
 Basic or Digest Access Auth
 - can be implemented with sufficient security
 - the right way to authenticate
 - the browser may give the user the full controle/overview over page
 logins
 - very simple to set up

  **Thoughts regarding HTML**
 By now the HTML(5) form element only supports two different values for
 the method attribute, namely get and post. As the abstract meaning
 of the method attribute -as far as i know- is not defined, one may
 suppose that this attribute defines the way how the form data are used
 for a HTTP request.

 If we take this definition, one may enhance the method element to other
 features of the HTTP protocol. These are some of the features that are
 used to shared data:
 - GET
 - POST
 - Auth
 - Cookies
 As cookies are working in the other direction, we may exclude them from
 our list for this purpose.




[whatwg] New HTML5 Form type

2011-10-22 Thread Michael Herold
Hello,

i want to discuss some thoughts on the html form element (see below).
If somebody thinks this idea might be useful I would continue to check
how a implementation of this feature would be possible and what the
technical difficulties would be.

I have no idea if there is a way to bring this to HTML5 or commit this
in any other way to the W3C.

Best wishes, Michael

 **Suggestion**
Add a new possible value auth to the HTML form //method// attribute.
If input elements named username/password are present they are used to
authenticate. Otherwise the first input element is used as username and
the first input[type=password] element is used as password.

It may be useful to interact with the http-status as the browser needs a
//nonce// for digest auth.

The aim would be to create custom login and logout dialogs without
JavaScript.

 **Thoughts regarding authentication**
Today there are three common ways to authenticate using HTTP: GET,
cookies, HTTP-Auth.

**GET**
Putting a session (+user) in the get.
- copy+paste and visual access can steal login
- have to depend on users ip to add a bit of security
- supported by every browser
- the website has to adjust every link for every user
- the url gets unreadable

**cookies**
Putting a session (+user) in a cookie.
- can be implemented with sufficient security
- broken by standard (none standard SLD fix in every browser)
- disabled or not supported by many clients for various reasons
- leaves footsteps on hdd per definition

**HTTP-Auth**
Basic or Digest Access Auth
- can be implemented with sufficient security
- the right way to authenticate
- the browser may give the user the full controle/overview over page
logins
- very simple to set up

 **Thoughts regarding HTML**
By now the HTML(5) form element only supports two different values for
the method attribute, namely get and post. As the abstract meaning
of the method attribute -as far as i know- is not defined, one may
suppose that this attribute defines the way how the form data are used
for a HTTP request.

If we take this definition, one may enhance the method element to other
features of the HTTP protocol. These are some of the features that are
used to shared data:
- GET
- POST
- Auth
- Cookies
As cookies are working in the other direction, we may exclude them from
our list for this purpose.