Also note that URL parameters are not secured by TLS in HTTPS.
-- Dick
On 13-Oct-06, at 3:57 AM, Chris Drake wrote:
Hi All,
Just so everyone remembers: GET encoded http://; URLs usually
appear en-mass in public lists (from proxy cache logs). If you don't
want to POST data anyplace, remember to expect replay attacks
often.
Kind Regards,
Chris Drake
Friday, October 13, 2006, 7:48:31 PM, you wrote:
JH On 10/13/06, Martin Atkins [EMAIL PROTECTED] wrote:
True, even one single pass through parameter should do.
This causes the minor inconvenience that the RP will probably now
have
to implement its own parsing, rather than using the framework's
pre-supplied functions for dealing with urlencoded query strings.
Not a major deal, but I'd guess that this is where the idea to use
return_to args came from in the first place.
JH return_to arguments can only be trusted if they are taken from the
JH signed return_to parameter, which means parsing the signed
return_to
JH parameter anyway. So it's at least no worse.
JH It's better in that the parameters do not now appear twice in the
JH response (once double-encoded)
JH Example of a response with parameter in the return_to:
JH http://a.url/?drink=0xC0FFEE%21openid.return_to=http%3A//a.url/
%3Fdrink%3D0xC0FFEE%2521...
JH Example of a response with hypothetical openid.appdata field:
JH http://a.url/?openid.appdata=drink%3D0xC0FFEE%
21openid.return_to=http%3A//a.url/...
JH Josh
JH ___
JH specs mailing list
JH specs@openid.net
JH http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
