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