Sure thing, we can make it happen.
We can't encode it in base64 or just reply with SHA-256, we just need to discuss and
see how it affects the bandwidth or the implementations on aerogear.auth.js.
I'm +1 on
- Request:
- Response:
Authorization: AG-Token=adshjadshadsgjagsdjagdasdads
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Tuesday, October 2, 2012 at 10:30 AM, Matthias Wessendorf wrote:
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
(mailto:matzew@apache.org)> wrote:
> On Tue, Oct 2, 2012 at 3:14 PM, Kris Borchers <kris(a)redhat.com
(mailto:kris@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
(mailto:matzew@apache.org)> wrote:
> >
> > > Hi,
> > >
> > > On Tue, Oct 2, 2012 at 2:37 PM, Kris Borchers <kris(a)redhat.com
(mailto:kris@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
(mailto:bruno@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 (mailto:matzew@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 (mailto:aerogear-dev@lists.jboss.org)
> > > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> > > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@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 (mailto:aerogear-dev@lists.jboss.org)
> > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> >
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@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
>
--
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 (mailto:aerogear-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/aerogear-dev