> From: Brian Eaton <bea...@google.com>
> HTTP/1.1 302 Moved Temporarily
> Location: http://www.thirdparty.com/rpc_relay.html#access_token=12345
>
> rpc_relay.html is highly cached in the browser, so instead of
> incurring hundreds of ms to fetch a file, the data lands in the
> third-party.com javascript in under a millisecond.
I see your point, but let me try to eliminate the call to rpc_relay.html at
all.
After all, the ultimate goal is not to receive an access token, but a resource
protected by that token. If there are mistakes in the suggestion below, please
let me know what they are.
Let us assume that the response contains this instead of the Location header:
<HTML>
<HEAD>
<script>
function process(token, url) {
document.params.setAttribute("method", "POST");
document.params.setAttribute("action", url);
document.params.submit();
}
</script>
</HEAD>
<BODY
onload="process(document.params.access_token.value,document.params.url.value)">
<form name="params">
<input type="hidden" name="access_token" value="12345"/>
<input type="hidden" name="url"
value="http://resourceserver.com/protected_resource.html"/>
</form>
</BODY>
</HTML>
Access token will be sent directly to the service provider. There is no need to
call rpc_relay.html. There is no need to call that complicated cross domain
communication logic described at FB. There is no need to create cookies.
You can do Ajax as well:
<HTML>
<HEAD>
<script>
function process(token, url) {
xmlhttp=new XMLHttpRequest();
params ="access_token="+token+"&....";
xmlhttp.open("POST", url, true);
xmlhttp.onreadystatechange = ...
xmlhttp.send(params);
}
</script>
</HEAD>
...
Is there anything wrong with either of these approaches?
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
