Brian,
I think, it's not so much about browsers written in Python, as about automation
(crawler) that somebody might want to use. Also, since Python user agent works
this way, we might have others user agents like that, e.g. did anyone check all
obscure browsers on smart phones?
Returning to our discussion about necessity of passing access_token in URL's
fragment, I've read both your proposal for changing v.9 and the current v.10,
but still don't understand why we need access_token in a fragment.
I think, a safer solution would be to return an access token in a response
form,
not in Location header. This way, we'll avoid problems with user agents that
David Stanek described and prevent browsers from storing tokens in a browser's
history.
In sense of efficiency, I don't think that we'll loose much. We might even
eliminate two last steps. If you're still concerned about caching pages in a
browser, it's a known problem for any sensitive pages and it can be resolved,
e.g. by adding HTTP headers in response: Pragma:No-cache and
Cache-Control:no-cache.
Here is how JSP that generates access token can look like:
form.jsp
-----------------------------------------------------------
<HTML>
<HEAD>
<%
response.addHeader("Pragma", "No-cache");
response.addHeader("Cache-Control", "no-cache");
String token = "123"; // It could be more complicated of course
%>
<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="<%=token%>"/>
http://localhost:8080/resource.jsp"/>
</form>
</BODY>
</HTML>
resource.jsp in this example will take the request with access_token, verify it
and send a response with the requested resource back to the browser. In the
example below it just prints out the request (with access_token in it).
It means that after modified step C, you'll have just one more step that takes
URL from the form and POST the form to that URL. Ajax might work as well. No
need in passing access token in a fragment.
resource.jsp that I've used for testing (it simply prints the request coming
from form.jsp):
<HTML>
<HEAD>
<%
String input ="";
try {
java.io.BufferedReader reader = request.getReader();
String line = reader.readLine();
while (line != null) {
input += line + "\n";
line = reader.readLine();
}
}
catch (Exception ex) {
}
%>
<script>
</script>
</HEAD>
<BODY>
<%=input%>
</BODY>
</HTML>
________________________________
From: Brian Eaton <bea...@google.com>
To: David Stanek <dsta...@dstanek.com>
Cc: o...@gryb.info; oauth@ietf.org
Sent: Mon, August 2, 2010 8:31:56 PM
Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?
On Mon, Aug 2, 2010 at 6:15 PM, David Stanek <dsta...@dstanek.com> wrote:
I just verified that the Python urllib client does send the fragment to the
server. I've created a patch and will be created a bug on the Python tracker.
Cool, but this doesn't seem relevant to the user-agent profile. Market
penetration of browsers written in python is limited.
Does anyone know what RFC actually talks about not sending the fragment? I've
seen 3986 where it explains that a fragment isn't really a part of the URI, but
it's doesn't specifically say that the client should not send it to the server.
No idea. This might be one of those things that all the browsers implement,
but
has never been fully specified.
There are a few notes on referers in the browsersec
wiki: http://code.google.com/p/browsersec/wiki/Part1
Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
