Hey,
thinking out loud... what if the 401 response on the auth endpoint
returns one of the following
* WWW-Authenticate: Token .....
* WWW-Authenticate: X-AG-Token .....
* WWW-Authenticate: AG-Token .....
... something like that...
The request header to that 'login endpoint' could 'react' with something
like
Authorization: AG-Token token=adshjadshadsgjagsdjagdasdads
===> but that above would be Base64..... (I think...)
OR is the plan to continue sending user/password in plain text.
Marko recently said sending them in plain text makes it more obvious
that for a login (where you send your credentials), TLS is required -
with Base64 it may be less obvious.
Which I agree on ....
Any thoughts?
-Matthias
On Tue, Oct 2, 2012 at 3:18 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, Oct 2, 2012 at 3:14 PM, Kris Borchers <kris(a)redhat.com>
wrote:
> Ah, I see. Hmm, yeah I guess the more I think about it, 401 on auth endpoints and 403
on "Not Authorized" endpoints makes sense instead of 401. I am indifferent on
the header on 401 so if we want to add it that's fine, I'll still just be checking
for the 401.
>
> My next question would be, what value would we assign to the WWW-Authenticate header
for non-Basic auth?
it's also used for digest and Token (like OAuth) etc
WWW-Authenticate is not limited to basic
-M
>
> On Oct 2, 2012, at 8:04 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>> Hi,
>>
>> On Tue, Oct 2, 2012 at 2:37 PM, Kris Borchers <kris(a)redhat.com> wrote:
>>> To be honest, I don't remember the full discussion either but I am only
>>> concerned with 401 on the login endpoint. If we did 403 with
>>> WWW-Authenticate header, I would be ok with that. I think I remember
>>> fighting for 401 over 403 because I needed to know it was an auth error so
>>> if it's 403 and there is a WWW-Authenticate header, then I would know
it's
>>> an auth error.
>>
>> IMO WWW-Authenticate on 403 is wrong.
>>
>> However, WWW-Authenticate MUST be included on 401 (according to the RFC)
>>
>> Regarding endpoints:
>>
>> * 'service endpoint' (e.g. /projects, /tasks etc)
>> ==> I think I like what amazon does, they give back 403 with NO
>> WWW-Authenticate header, and tell you 'denied'. IMO that's correct
for
>> 'service endpoints', which are protected and you don't provide the
>> _valid_ token
>>
>> * login endpoint:
>> I think that 401 fits fine here, right ?
>> (which perhaps... should include the WWW-Authenticate on that 401)
>>
>>
>> NOTE: I don't want to change the current design, as it was already
>> discussed - but just raising some items, while doing a deeper dive on
>> 'auth', because of native iOS
>>
>> -Matthias
>>
>>>
>>> If that is the proper way, then I will make it work on the JS side. I am all
>>> for making the JS side "easier" but not at the expense of doing
things in a
>>> way people don't expect.
>>
>>
>>
>>
>>
>>
>>>
>>> Thoughts?
>>>
>>> On Oct 2, 2012, at 6:42 AM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
>>>
>>> For some reason that I don't remember now, we discussed about 401 x 403
when
>>> the REST authentication API was sent, people decided for 401.
>>>
>>> I'm not picky on it because this is easy to change and only related to
our
>>> TODO. We discussed about authentication methods like amazon s3 in the past
>>>
https://github.com/abstractj/aerogear-security/blob/deltaspike/README.md
>>>
>>> We have tons of changes to do now, my only concern at the current TODO app
>>> was to get it done to j1.
>>>
>>>
>>> --
>>> "The measure of a man is what he does with power" - Plato
>>> -
>>> @abstractj
>>> -
>>> Volenti Nihil Difficile
>>>
>>> On Tuesday, October 2, 2012 at 8:08 AM, Matthias Wessendorf wrote:
>>>
>>> Hi,
>>>
>>> I think they return 403 since they (like us) lack the WWW-Authenticate
>>> header.
>>>
>>> Which is required on 401:
>>>
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.47
>>>
>>> -M
>>>
>>> On Tue, Oct 2, 2012 at 12:56 PM, Matthias Wessendorf
<matzew(a)apache.org>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I noticed that with Amazon's S3 (for instance) they return 403 when
>>> you are not authorized. Not really sure, but forbidden (403) is
>>> perhaps fine when accessing a protected REST endpoint (versus 401) ?
>>>
>>> Thoughts?
>>>
>>> -Matthias
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog:
http://matthiaswessendorf.wordpress.com/
>>> sessions:
http://www.slideshare.net/mwessendorf
>>> twitter:
http://twitter.com/mwessendorf
>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog:
http://matthiaswessendorf.wordpress.com/
>>> sessions:
http://www.slideshare.net/mwessendorf
>>> twitter:
http://twitter.com/mwessendorf
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog:
http://matthiaswessendorf.wordpress.com/
>> sessions:
http://www.slideshare.net/mwessendorf
>> twitter:
http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf