in the same way as BASIC authorization headers are added to requests
based on the associated realm, a Oauth library could automatically add
tokens based in the realm obtained from WWW-Authenticate response
header.
Regards,
Torsten.
Am 07.05.2010 um 07:51 schrieb Luke Shepard <[email protected]>:
It's not really up to the client. If https://api.example.com/pr?access_token=loin21op
redirects to https://api.otherapi.com/somethingelse?access_token=loin21op
, then I just need to follow the redirect - no decisions to be made
by the client. Many low-level HTTP libraries will just do this
automatically. There are already facilities to warn if you try to
redirect from an https url to an http one.
I think the difference between your cookie example and OAuth token
is that cookies are automatically sent on every request, so there
have to be rules about when they are automatically appended. OAuth
access tokens aren't the same thing - they are explicitly added by
developers on each request, so we don't need to overspecify rules in
the protocol that should be handled by developers.
On May 6, 2010, at 10:35 PM, David Recordon wrote:
Why wouldn't the client send the token with the new request? If I'm
trying to access https://api.example.com/pr?access_token=loin21op
and I get a 301 response, I'll need to follow that if I want any
chance of accessing the protected resource.
Maybe we're saying the same thing?
On Thu, May 6, 2010 at 10:21 PM, Manger, James H <[email protected]
> wrote:
How should an OAuth client app behave when it gets an HTTP redirect
on requesting a protected resource?
Similarly, how should it behave when it follows any other link in a
response?
Obviously it should make a new request to the URI in the redirect
or link — that is normal HTTP and hypertext behaviour.
The question is does the token get sent with the new request?
I think the spec needs to provide an answer, even if it isn’t my s
uggestion of an “sites” list when a token is issued.
--
James Manger
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
<ATT00001..txt>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
