How about encoding requests as well. The request json blob could be then URL encoded and added to the endpoint/callback URL with a parameter like "oauth_json_request". This would solve the prefix/collision problem.
Marius On Tue, Apr 20, 2010 at 9:27 AM, Joseph Smarr <jsm...@gmail.com> wrote: > ...and of course by "request format", I mean "response format". :) > BTW, note that the "trailing newline problem" with url-encoding is > particularly pernicious because a) it messes up the signature, and b) you > often can't see it when you print out your variables, so everything looks ok > and yet the signature is garbled. I've seen this multiple times, and IMO > that alone is reason enough to get rid of this serialization format in favor > of something more robust and widely implemented like JSON. > > On Tue, Apr 20, 2010 at 9:24 AM, Joseph Smarr <jsm...@gmail.com> wrote: >> >> +1 to including JSON format, and perhaps making it the required format. In >> my experience helping numerous developers debug their OAuth implementations, >> url-encoding/decoding was often a source of bugs, since a) the libraries are >> usually hand-built, b) url-encoding is known to be funky/inconsistent wrt + >> vs. %20 and other such things, and c) it's very sensitive to things like a >> trailing newline at the end of the response, which can easily be tokenized >> as part of the the last value (since the normal implementations just split >> on & and =). In contrast, I've never heard of any problems parsing JSON, nor >> any encoding/decoding bugs related to working with JSON in other APIs >> (something I *cannot* say about XML, which is way more finicky about >> requiring its values to be properly encoded or escaped in CDATA etc.; I've >> also seen way more inconsistency in support of XML parsers and their output >> formats, whereas JSON always works exactly the same way and always "just >> works"). >> So in conclusion, url-encoding has caused a lot of pain in OAuth 1.0, and >> JSON is already widely supported (presumably including by most APIs that >> you're building OAuth support to be able to access!), so I think it would >> simplify the spec and increase ease/success of development to use JSON as a >> request format. In fact, I think I'd like to push for it to be the >> default/required format, given the positive attributes above. Does anyone >> object, and if so, why? >> Thanks, js >> >> On Tue, Apr 20, 2010 at 8:10 AM, Eran Hammer-Lahav <e...@hueniverse.com> >> wrote: >>> >>> There seems to be support for this idea with some concerns about >>> complexity. Someone needs to propose text for this including defining the >>> request parameter and schema of the various reply formats. >>> >>> EHL >>> >>> > -----Original Message----- >>> > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] >>> > Sent: Monday, April 19, 2010 4:48 AM >>> > To: Eran Hammer-Lahav >>> > Cc: Dick Hardt; OAuth WG >>> > Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON >>> > >>> > >>> > > We can also offer both and define a client request parameter (as long >>> > > as the server is required to make at least one format available). >>> > >>> > +1 on this >>> > >>> > regards, >>> > Torsten. >>> > >>> > > >>> > > EHL >>> > > >>> > >> -----Original Message----- >>> > >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >>> > >> Behalf Of Dick Hardt >>> > >> Sent: Sunday, April 18, 2010 9:30 PM >>> > >> To: OAuth WG >>> > >> Subject: [OAUTH-WG] application/x-www-form-urlencoded vs JSON >>> > >> >>> > >> The AS token endpoint response is encoded as application/x-www-form- >>> > >> urlencoded >>> > >> >>> > >> While this reuses a well known and understood encoding standard, it >>> > >> is uncommon for a client to receive a message encoded like this. >>> > >> Most >>> > >> server responses are encoded as XML or JSON. Libraries are NOT >>> > >> reedily available to parse application/x-www-form-urlencoded results >>> > >> as this is something that is typically done in the web servers >>> > >> framework. While parsing the name value pairs and URL un-encoding >>> > >> them is not hard, many developers have been caught just splitting >>> > >> the >>> > parameters and forgetting to URL decode the token. >>> > >> Since the token is opaque and may contain characters that are >>> > >> escaped, it is a difficult bug to detect. >>> > >> >>> > >> Potential options: >>> > >> >>> > >> 1) Do nothing, developers should read the specs and do the right >>> > >> thing. >>> > >> >>> > >> 2) Require that all parameters are URL safe so that there is no >>> > >> encoding issue. >>> > >> >>> > >> 3) Return results as JSON, and recommend that parameters be URL >>> > >> safe. >>> > >> >>> > >> -- Dick >>> > >> _______________________________________________ >>> > >> OAuth mailing list >>> > >> OAuth@ietf.org >>> > >> https://www.ietf.org/mailman/listinfo/oauth >>> > > _______________________________________________ >>> > > OAuth mailing list >>> > > OAuth@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/oauth >>> > > >>> > >>> > >>> > >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
