7:22 a.m.
So, having seem the plans around Basic and Digest auth for Android and iOS, I am wondering
if there is any need for that on JS. Typically that is handled by the browser and them the
server maintains the session so I would lean toward not needing anything specific in JS
for these types of auth. Input welcome.
Kris
10:38 a.m.
On Tue, May 21, 2013 at 07:22:30AM -0500, Kris Borchers wrote:
So, having seem the plans around Basic and Digest auth for Android
and
iOS, I am wondering if there is any need for that on JS. Typically
that is handled by the browser and them the server maintains the
session so I would lean toward not needing anything specific in JS for
these types of auth. Input welcome.
So how would I authenticate against a
digest-protected endpoint using
AeroGear-js? would it work OOTB?
--
qmx
10:52 a.m.
On May 21, 2013, at 10:38 AM, Douglas Campos <qmx(a)qmx.me> wrote:
On Tue, May 21, 2013 at 07:22:30AM -0500, Kris Borchers wrote:
> So, having seem the plans around Basic and Digest auth for Android and
> iOS, I am wondering if there is any need for that on JS. Typically
> that is handled by the browser and them the server maintains the
> session so I would lean toward not needing anything specific in JS for
> these types of auth. Input welcome.
So how would I authenticate against a digest-protected endpoint using
AeroGear-js? would it work OOTB?
I think I was confused. So are we talking about Basic/Digest auth of REST endpoints? If
so, then this is a whole different beast. As far as I know, I have to manually create the
headers and do the back and forth which doesn't sound fun but if it's something we
need, I will work it into the roadmap.
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:40 a.m.
Would be nice if we could include into the JS roadmap. Bonus points for making
developer's life easy.
Digest auth on JS looks really tricky, if we can make it easy, awesome.
Kris Borchers wrote:
On May 21, 2013, at 10:38 AM, Douglas Campos<qmx(a)qmx.me>
wrote:
> On Tue, May 21, 2013 at 07:22:30AM -0500, Kris Borchers wrote:
>> So, having seem the plans around Basic and Digest auth for Android and
>> iOS, I am wondering if there is any need for that on JS. Typically
>> that is handled by the browser and them the server maintains the
>> session so I would lean toward not needing anything specific in JS for
>> these types of auth. Input welcome.
> So how would I authenticate against a digest-protected endpoint using
> AeroGear-js? would it work OOTB?
I think I was confused. So are we talking about Basic/Digest auth of REST endpoints? If
so, then this is a whole different beast. As far as I know, I have to manually create the
headers and do the back and forth which doesn't sound fun but if it's something we
need, I will work it into the roadmap.
> --
> qmx
> _______________________________________________
> 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
8:44 a.m.
On 05/21/2013 08:22 AM, Kris Borchers wrote:
So, having seem the plans around Basic and Digest auth for Android
and iOS, I am wondering if there is any need for that on JS. Typically that is handled by
the browser and them the server maintains the session so I would lean toward not needing
anything specific in JS for these types of auth. Input welcome.
It may be useful is
someone tries to embed it in a Node container or
write a Windows 8 app, Gnome 3 extension, etc.
Kris
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:12 a.m.
OK, so I am going to try to spell out the workflow as I see it working in JS. I would
appreciate any feedback on whether or not this is crazy/wrong.
Create Basic or Digest authenticator
Must include a callback to be fired when a request to auth is received from server
Create pipe which uses this authenticator
Attempt read, save or remove on this pipe
Endpoint returns 401 with header indicating type of auth required
Need to research that this won't trigger the browser's native Basic/Digest auth
handling
Fire user supplied auth callback passing it a reference to a "login" method that
the user will pass the credentials collected in the auth callback
Use "login" method to construct appropriate response to server's 401
This is the fun part :-P
Server responds to auth attempt
Success - continue to process original read, write or remove
Error - trigger a user supplied auth failure callback
Thanks!
On May 22, 2013, at 8:44 AM, Summers Pittman <supittma(a)redhat.com> wrote:
On 05/21/2013 08:22 AM, Kris Borchers wrote:
> So, having seem the plans around Basic and Digest auth for Android and iOS, I am
wondering if there is any need for that on JS. Typically that is handled by the browser
and them the server maintains the session so I would lean toward not needing anything
specific in JS for these types of auth. Input welcome.
It may be useful is someone tries to embed it in a Node container or
write a Windows 8 app, Gnome 3 extension, etc.
>
> Kris
> _______________________________________________
> 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
9:41 a.m.
I guess my other question is are Android and iOS implementing this as a direct
authentication method? For example, would I create a Digest auth module and specifically
call login without actually requesting a resource first? I don't particularly see how
this would work but thought I would ask.
On May 22, 2013, at 9:12 AM, Kris Borchers <kris(a)redhat.com> wrote:
OK, so I am going to try to spell out the workflow as I see it
working in JS. I would appreciate any feedback on whether or not this is crazy/wrong.
Create Basic or Digest authenticator
Must include a callback to be fired when a request to auth is received from server
Create pipe which uses this authenticator
Attempt read, save or remove on this pipe
Endpoint returns 401 with header indicating type of auth required
Need to research that this won't trigger the browser's native Basic/Digest auth
handling
Fire user supplied auth callback passing it a reference to a "login" method
that the user will pass the credentials collected in the auth callback
Use "login" method to construct appropriate response to server's 401
This is the fun part :-P
Server responds to auth attempt
Success - continue to process original read, write or remove
Error - trigger a user supplied auth failure callback
Thanks!
On May 22, 2013, at 8:44 AM, Summers Pittman <supittma(a)redhat.com> wrote:
> On 05/21/2013 08:22 AM, Kris Borchers wrote:
>> So, having seem the plans around Basic and Digest auth for Android and iOS, I am
wondering if there is any need for that on JS. Typically that is handled by the browser
and them the server maintains the session so I would lean toward not needing anything
specific in JS for these types of auth. Input welcome.
> It may be useful is someone tries to embed it in a Node container or
> write a Windows 8 app, Gnome 3 extension, etc.
>>
>> Kris
>> _______________________________________________
>> 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
9:44 a.m.
On 05/22/2013 10:41 AM, Kris Borchers wrote:
I guess my other question is are Android and iOS implementing this as
a direct authentication method? For example, would I create a Digest
auth module and specifically call login without actually requesting a
resource first? I don't particularly see how this would work but
thought I would ask.
That is how it works at the moment. IN the case of basic on Android it
just caches the credentials. I havn't worked out how digest will do it
yet, but I am imagining it will reference a "login" url to get the
necessary headers from the 401.
On May 22, 2013, at 9:12 AM, Kris Borchers <kris(a)redhat.com
<mailto:kris@redhat.com>> wrote:
> OK, so I am going to try to spell out the workflow as I see it
> working in JS. I would appreciate any feedback on whether or not this
> is crazy/wrong.
>
> 1. Create Basic or Digest authenticator
> 1. Must include a callback to be fired when a request to auth is
> received from server
> 2. Create pipe which uses this authenticator
> 3. Attempt read, save or remove on this pipe
> 4. Endpoint returns 401 with header indicating type of auth required
> 1. Need to research that this won't trigger the browser's native
> Basic/Digest auth handling
> 5. Fire user supplied auth callback passing it a reference to a
> "login" method that the user will pass the credentials collected
> in the auth callback
> 6. Use "login" method to construct appropriate response to server's
401
> 1. This is the fun part :-P
> 7. Server responds to auth attempt
> 1. Success - continue to process original read, write or remove
> 2. Error - trigger a user supplied auth failure callback
>
>
> Thanks!
>
> On May 22, 2013, at 8:44 AM, Summers Pittman <supittma(a)redhat.com
> <mailto:supittma@redhat.com>> wrote:
>
>> On 05/21/2013 08:22 AM, Kris Borchers wrote:
>>> So, having seem the plans around Basic and Digest auth for Android
>>> and iOS, I am wondering if there is any need for that on JS.
>>> Typically that is handled by the browser and them the server
>>> maintains the session so I would lean toward not needing anything
>>> specific in JS for these types of auth. Input welcome.
>> It may be useful is someone tries to embed it in a Node container or
>> write a Windows 8 app, Gnome 3 extension, etc.
>>>
>>> Kris
>>> _______________________________________________
>>> 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:48 a.m.
On May 22, 2013, at 9:44 AM, Summers Pittman <supittma(a)redhat.com> wrote:
On 05/22/2013 10:41 AM, Kris Borchers wrote:
> I guess my other question is are Android and iOS implementing this as a direct
authentication method? For example, would I create a Digest auth module and specifically
call login without actually requesting a resource first? I don't particularly see how
this would work but thought I would ask.
>
That is how it works at the moment. IN the case of basic on Android it just caches the
credentials. I havn't worked out how digest will do it yet, but I am imagining it
will reference a "login" url to get the necessary headers from the 401.
Wouldn't this tie you to a server implementation which is not what we want. This
should work with any Basic or Digest auth system, right?
> On May 22, 2013, at 9:12 AM, Kris Borchers
<kris(a)redhat.com> wrote:
>
>> OK, so I am going to try to spell out the workflow as I see it working in JS. I
would appreciate any feedback on whether or not this is crazy/wrong.
>>
>> Create Basic or Digest authenticator
>> Must include a callback to be fired when a request to auth is received from
server
>> Create pipe which uses this authenticator
>> Attempt read, save or remove on this pipe
>> Endpoint returns 401 with header indicating type of auth required
>> Need to research that this won't trigger the browser's native
Basic/Digest auth handling
>> Fire user supplied auth callback passing it a reference to a "login"
method that the user will pass the credentials collected in the auth callback
>> Use "login" method to construct appropriate response to server's
401
>> This is the fun part :-P
>> Server responds to auth attempt
>> Success - continue to process original read, write or remove
>> Error - trigger a user supplied auth failure callback
>>
>> Thanks!
>>
>> On May 22, 2013, at 8:44 AM, Summers Pittman <supittma(a)redhat.com> wrote:
>>
>>> On 05/21/2013 08:22 AM, Kris Borchers wrote:
>>>> So, having seem the plans around Basic and Digest auth for Android and
iOS, I am wondering if there is any need for that on JS. Typically that is handled by the
browser and them the server maintains the session so I would lean toward not needing
anything specific in JS for these types of auth. Input welcome.
>>> It may be useful is someone tries to embed it in a Node container or
>>> write a Windows 8 app, Gnome 3 extension, etc.
>>>>
>>>> Kris
>>>> _______________________________________________
>>>> 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
>
>
>
> _______________________________________________
> 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
10:01 a.m.
On 05/22/2013 10:48 AM, Kris Borchers wrote:
On May 22, 2013, at 9:44 AM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
> On 05/22/2013 10:41 AM, Kris Borchers wrote:
>> I guess my other question is are Android and iOS implementing this
>> as a direct authentication method? For example, would I create a
>> Digest auth module and specifically call login without actually
>> requesting a resource first? I don't particularly see how this would
>> work but thought I would ask.
>>
> That is how it works at the moment. IN the case of basic on Android
> it just caches the credentials. I havn't worked out how digest will
> do it yet, but I am imagining it will reference a "login" url to get
> the necessary headers from the 401.
Wouldn't this tie you to a server implementation which is not what we
want. This should work with any Basic or Digest auth system, right?
It wouldn't
tie us to a particular server implementation, but it would
be weird since digest wants to be a retry with authentication after a
failure like a refresh token does.
>> On May 22, 2013, at 9:12 AM, Kris Borchers <kris(a)redhat.com
>> <mailto:kris@redhat.com>> wrote:
>>
>>> OK, so I am going to try to spell out the workflow as I see it
>>> working in JS. I would appreciate any feedback on whether or not
>>> this is crazy/wrong.
>>>
>>> 1. Create Basic or Digest authenticator
>>> 1. Must include a callback to be fired when a request to auth
>>> is received from server
>>> 2. Create pipe which uses this authenticator
>>> 3. Attempt read, save or remove on this pipe
>>> 4. Endpoint returns 401 with header indicating type of auth required
>>> 1. Need to research that this won't trigger the browser's
>>> native Basic/Digest auth handling
>>> 5. Fire user supplied auth callback passing it a reference to a
>>> "login" method that the user will pass the credentials
>>> collected in the auth callback
>>> 6. Use "login" method to construct appropriate response to
>>> server's 401
>>> 1. This is the fun part :-P
>>> 7. Server responds to auth attempt
>>> 1. Success - continue to process original read, write or remove
>>> 2. Error - trigger a user supplied auth failure callback
>>>
>>>
>>> Thanks!
>>>
>>> On May 22, 2013, at 8:44 AM, Summers Pittman <supittma(a)redhat.com
>>> <mailto:supittma@redhat.com>> wrote:
>>>
>>>> On 05/21/2013 08:22 AM, Kris Borchers wrote:
>>>>> So, having seem the plans around Basic and Digest auth for
>>>>> Android and iOS, I am wondering if there is any need for that on
>>>>> JS. Typically that is handled by the browser and them the server
>>>>> maintains the session so I would lean toward not needing anything
>>>>> specific in JS for these types of auth. Input welcome.
>>>> It may be useful is someone tries to embed it in a Node container or
>>>> write a Windows 8 app, Gnome 3 extension, etc.
>>>>>
>>>>> Kris
>>>>> _______________________________________________
>>>>> 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
>>
>>
>>
>> _______________________________________________
>> 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 <mailto:aerogear-dev@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
9:43 a.m.
On 05/22/2013 10:12 AM, Kris Borchers wrote:
OK, so I am going to try to spell out the workflow as I see it
working
in JS. I would appreciate any feedback on whether or not this is
crazy/wrong.
1. Create Basic or Digest authenticator
1. Must include a callback to be fired when a request to auth is
received from server
2. Create pipe which uses this authenticator
3. Attempt read, save or remove on this pipe
4. Endpoint returns 401 with header indicating type of auth required
1. Need to research that this won't trigger the browser's native
Basic/Digest auth handling
5. Fire user supplied auth callback passing it a reference to a
"login" method that the user will pass the credentials collected
in the auth callback
6. Use "login" method to construct appropriate response to server's 401
1. This is the fun part :-P
In the Android version, login is called by the developer, not by the
framework. This "primes" the authenticator which then provides whatever
tokens/headers/parameters/etc that the pipe will need to authenticate
the request.
This may have to be changed in the future to support multiple login flows.
1. Server responds to auth attempt
1. Success - continue to process original read, write or remove
2. Error - trigger a user supplied auth failure callback
Thanks!
On May 22, 2013, at 8:44 AM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
> On 05/21/2013 08:22 AM, Kris Borchers wrote:
>> So, having seem the plans around Basic and Digest auth for Android
>> and iOS, I am wondering if there is any need for that on JS.
>> Typically that is handled by the browser and them the server
>> maintains the session so I would lean toward not needing anything
>> specific in JS for these types of auth. Input welcome.
> It may be useful is someone tries to embed it in a Node container or
> write a Windows 8 app, Gnome 3 extension, etc.
>>
>> Kris
>> _______________________________________________
>> 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
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:47 a.m.
On May 22, 2013, at 9:43 AM, Summers Pittman <supittma(a)redhat.com> wrote:
On 05/22/2013 10:12 AM, Kris Borchers wrote:
> OK, so I am going to try to spell out the workflow as I see it working in JS. I would
appreciate any feedback on whether or not this is crazy/wrong.
>
> Create Basic or Digest authenticator
> Must include a callback to be fired when a request to auth is received from server
> Create pipe which uses this authenticator
> Attempt read, save or remove on this pipe
> Endpoint returns 401 with header indicating type of auth required
> Need to research that this won't trigger the browser's native Basic/Digest
auth handling
> Fire user supplied auth callback passing it a reference to a "login" method
that the user will pass the credentials collected in the auth callback
> Use "login" method to construct appropriate response to server's 401
> This is the fun part :-P
In the Android version, login is called by the developer, not by the framework. This
"primes" the authenticator which then provides whatever
tokens/headers/parameters/etc that the pipe will need to authenticate the request.
Sorry, I may not have been clear here. The developer would be calling the login method
with my implementation too. Inside the callback they provide, their callback will be
passed the login method which they would then call.
This may have to be changed in the future to support multiple login flows.
> Server responds to auth attempt
> Success - continue to process original read, write or remove
> Error - trigger a user supplied auth failure callback
>
> Thanks!
>
> On May 22, 2013, at 8:44 AM, Summers Pittman <supittma(a)redhat.com> wrote:
>
>> On 05/21/2013 08:22 AM, Kris Borchers wrote:
>>> So, having seem the plans around Basic and Digest auth for Android and iOS, I
am wondering if there is any need for that on JS. Typically that is handled by the browser
and them the server maintains the session so I would lean toward not needing anything
specific in JS for these types of auth. Input welcome.
>> It may be useful is someone tries to embed it in a Node container or
>> write a Windows 8 app, Gnome 3 extension, etc.
>>>
>>> Kris
>>> _______________________________________________
>>> 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:39 a.m.
On May 22, 2013, at 5:43 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 05/22/2013 10:12 AM, Kris Borchers wrote:
> OK, so I am going to try to spell out the workflow as I see it working in JS. I would
appreciate any feedback on whether or not this is crazy/wrong.
>
> Create Basic or Digest authenticator
> Must include a callback to be fired when a request to auth is received from server
> Create pipe which uses this authenticator
> Attempt read, save or remove on this pipe
> Endpoint returns 401 with header indicating type of auth required
> Need to research that this won't trigger the browser's native Basic/Digest
auth handling
> Fire user supplied auth callback passing it a reference to a "login" method
that the user will pass the credentials collected in the auth callback
> Use "login" method to construct appropriate response to server's 401
> This is the fun part :-P
In the Android version, login is called by the developer, not by the framework. This
"primes" the authenticator which then provides whatever
tokens/headers/parameters/etc that the pipe will need to authenticate the request.
same with iOS with an HttpBasic/Digest authentication module. Upon 'login',
credentials are 'cached' using a build-in system provided object (no http
request). When a request is made which requires authentication, the system checks first to
see if credentials exists in its store(which we cached earlier with 'login') and
if found it authenticates the session. Similar, when 'logout' is called, we remove
the cached credentials from the system.
for this particular context, the authentication module mechanism we have, fitted nicely
in filling the credential information to the system store, which uses them for
authentication (and hopefully enough
Thanks
Christos
This may have to be changed in the future to support multiple login
flows.
> Server responds to auth attempt
> Success - continue to process original read, write or remove
> Error - trigger a user supplied auth failure callback
>
> Thanks!
>
> On May 22, 2013, at 8:44 AM, Summers Pittman <supittma(a)redhat.com> wrote:
>
>> On 05/21/2013 08:22 AM, Kris Borchers wrote:
>>> So, having seem the plans around Basic and Digest auth for Android and iOS, I
am wondering if there is any need for that on JS. Typically that is handled by the browser
and them the server maintains the session so I would lean toward not needing anything
specific in JS for these types of auth. Input welcome.
>> It may be useful is someone tries to embed it in a Node container or
>> write a Windows 8 app, Gnome 3 extension, etc.
>>>
>>> Kris
>>> _______________________________________________
>>> 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:52 a.m.
On May 22, 2013, at 10:39 AM, Christos Vasilakis <cvasilak(a)gmail.com> wrote:
On May 22, 2013, at 5:43 PM, Summers Pittman <supittma(a)redhat.com> wrote:
> On 05/22/2013 10:12 AM, Kris Borchers wrote:
>> OK, so I am going to try to spell out the workflow as I see it working in JS. I
would appreciate any feedback on whether or not this is crazy/wrong.
>>
>> Create Basic or Digest authenticator
>> Must include a callback to be fired when a request to auth is received from
server
>> Create pipe which uses this authenticator
>> Attempt read, save or remove on this pipe
>> Endpoint returns 401 with header indicating type of auth required
>> Need to research that this won't trigger the browser's native
Basic/Digest auth handling
>> Fire user supplied auth callback passing it a reference to a "login"
method that the user will pass the credentials collected in the auth callback
>> Use "login" method to construct appropriate response to server's
401
>> This is the fun part :-P
> In the Android version, login is called by the developer, not by the framework. This
"primes" the authenticator which then provides whatever
tokens/headers/parameters/etc that the pipe will need to authenticate the request.
>
same with iOS with an HttpBasic/Digest authentication module. Upon 'login',
credentials are 'cached' using a build-in system provided object (no http
request). When a request is made which requires authentication, the system checks first to
see if credentials exists in its store(which we cached earlier with 'login') and
if found it authenticates the session. Similar, when 'logout' is called, we remove
the cached credentials from the system.
This brings up a good point. If the browser doesn't do the caching for us in JS then I
am not sure we can pursue this. I do not feel comfortable doing any sort of credential
caching in JS as that is just asking for trouble.
for this particular context, the authentication module mechanism we have, fitted nicely
in filling the credential information to the system store, which uses them for
authentication (and hopefully enough
Thanks
Christos
> This may have to be changed in the future to support multiple login flows.
>> Server responds to auth attempt
>> Success - continue to process original read, write or remove
>> Error - trigger a user supplied auth failure callback
>>
>> Thanks!
>>
>> On May 22, 2013, at 8:44 AM, Summers Pittman <supittma(a)redhat.com> wrote:
>>
>>> On 05/21/2013 08:22 AM, Kris Borchers wrote:
>>>> So, having seem the plans around Basic and Digest auth for Android and
iOS, I am wondering if there is any need for that on JS. Typically that is handled by the
browser and them the server maintains the session so I would lean toward not needing
anything specific in JS for these types of auth. Input welcome.
>>> It may be useful is someone tries to embed it in a Node container or
>>> write a Windows 8 app, Gnome 3 extension, etc.
>>>>
>>>> Kris
>>>> _______________________________________________
>>>> 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
>
> _______________________________________________
> 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
7:06 p.m.
This will also put Basic/Digest authentication out of reach for the Cordova
apps as well right?
Can anything be done for Cordova apps? I can see wrapping iOS/Android
implementations as Cordova plugins as one solution but something pure JS
may feel better.
--
Gorkem
--
Gorkem
On Wed, May 22, 2013 at 11:52 AM, Kris Borchers <kris(a)redhat.com> wrote:
On May 22, 2013, at 10:39 AM, Christos Vasilakis <cvasilak(a)gmail.com>
wrote:
On May 22, 2013, at 5:43 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 05/22/2013 10:12 AM, Kris Borchers wrote:
OK, so I am going to try to spell out the workflow as I see it working in
JS. I would appreciate any feedback on whether or not this is crazy/wrong.
1. Create Basic or Digest authenticator
1. Must include a callback to be fired when a request to auth is
received from server
2. Create pipe which uses this authenticator
3. Attempt read, save or remove on this pipe
4. Endpoint returns 401 with header indicating type of auth required
1. Need to research that this won't trigger the browser's native
Basic/Digest auth handling
5. Fire user supplied auth callback passing it a reference to a
"login" method that the user will pass the credentials collected in the
auth callback
6. Use "login" method to construct appropriate response to server's 401
1. This is the fun part :-P
In the Android version, login is called by the developer, not by the
framework. This "primes" the authenticator which then provides whatever
tokens/headers/parameters/etc that the pipe will need to authenticate the
request.
same with iOS with an HttpBasic/Digest authentication module. Upon
'login', credentials are 'cached' using a build-in system provided
object
(no http request). When a request is made which requires authentication,
the system checks first to see if credentials exists in its store(which we
cached earlier with 'login') and if found it authenticates the session.
Similar, when 'logout' is called, we remove the cached credentials from the
system.
This brings up a good point. If the browser doesn't do the caching for us
in JS then I am not sure we can pursue this. I do not feel comfortable
doing any sort of credential caching in JS as that is just asking for
trouble.
for this particular context, the authentication module mechanism we have,
fitted nicely in filling the credential information to the system store,
which uses them for authentication (and hopefully enough
Thanks
Christos
This may have to be changed in the future to support multiple login flows.
1. Server responds to auth attempt
1. Success - continue to process original read, write or remove
2. Error - trigger a user supplied auth failure callback
Thanks!
On May 22, 2013, at 8:44 AM, Summers Pittman <supittma(a)redhat.com> wrote:
On 05/21/2013 08:22 AM, Kris Borchers wrote:
So, having seem the plans around Basic and Digest auth for Android and
iOS, I am wondering if there is any need for that on JS. Typically that is
handled by the browser and them the server maintains the session so I would
lean toward not needing anything specific in JS for these types of auth.
Input welcome.
It may be useful is someone tries to embed it in a Node container or
write a Windows 8 app, Gnome 3 extension, etc.
Kris
_______________________________________________
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
listaerogear-dev@lists.jboss.orghttps://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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:22 a.m.
Looks good. I'm just wondering if we could start our "Auth"
specification to the client side. Wdyt?
I'd like to have JS, iOS and Android on the same page.
Kris Borchers wrote:
OK, so I am going to try to spell out the workflow as I see it
working
in JS. I would appreciate any feedback on whether or not this is
crazy/wrong.
1. Create Basic or Digest authenticator
1. Must include a callback to be fired when a request to auth is
received from server
2. Create pipe which uses this authenticator
3. Attempt read, save or remove on this pipe
4. Endpoint returns 401 with header indicating type of auth required
1. Need to research that this won't trigger the browser's native
Basic/Digest auth handling
5. Fire user supplied auth callback passing it a reference to a "login"
method that the user will pass the credentials collected in the auth
callback
6. Use "login" method to construct appropriate response to server's 401
1. This is the fun part :-P
7. Server responds to auth attempt
1. Success - continue to process original read, write or remove
2. Error - trigger a user supplied auth failure callback
Thanks!
4003
days inactive
4007
days old
15 comments
7 participants
participants (7)
-
Bruno Oliveira -
Christos Vasilakis -
Douglas Campos -
Gorkem Ercan -
Kris Borchers -
Kris Borchers -
Summers Pittman