Just remember that dashes are problematic for JavaScript, since oauth_token
is a valid variable name, but oauth-token is not. So unless you're sure this
will never be a problem, +1 to underscores everywhere. I know HTTP headers
normally use dash, but if you want to use dashes for headers and unders
010 at 3:35 PM, Joseph Smarr wrote:
> Let me try to offer some of those "logical, positive statements in favour
> of the technical merits of JSON over the original format choice" for those
> that aren't familiar or haven't gleaned them from the thread thus far:
&
wrote:
> On 10/05/2010 15:56, Dick Hardt wrote:
> >
> > On 2010-05-10, at 1:11 AM, Pid wrote:
> >
> >> On 10/05/2010 07:57, Joseph Smarr wrote:
> >>>> 1. Server Response Format
> >>>
> >>> I vote for B, though I could live wi
> 1. Server Response Format
I vote for B, though I could live with C. (A would make me sad though)
We've had a healthy and reasonable debate about the trade-offs here, but I
think the main counterargument for requiring JSON support is that it's not
quite yet a "no-brainer" to have JSON support in
I'm hearing a lot of confusion on this thread.
Evan-of course when attributes are sent *on-the-url* then they get parsed
automatically by the HTTP stack, but we're talking about the response body,
which every OAuth 1.0 library I've seen writes their own (usually buggy)
parser for, and that's where
I also vote for #3. I think our field experience has shown that a) lack of a
standard place to stick scope info in access token requests leads to
per-provider inconsistencies that further complicate libraries, b) lots of
providers do want to offer scoped access tokens (and show the list of scopes
b
Any way to get a pretty xml2rfc-style HTML output (like we use for OAuth
1.0), or is that too fluffy for the hardcore IETF types? :) Thanks, js
On Thu, Apr 29, 2010 at 5:42 PM, Eran Hammer-Lahav wrote:
> To anyone with published documented pointing to previous versions of the
> spec -
>
> Please
I agree we need JSON formatting for all the currently url-encoded responses,
but not for the requests, since that stuff will be handled by normal web
servers. That's all you were saying right? We still need a proposed format
for the JSON, but my strawman would just be take all the key/value pairs
r
a requirement for the response.
> While it might be easier for environments with JSON libraries, it's
> drastically more complex for environments (like embedded hardware)
> which doesn't support JSON. And writing basic form encoded parsing
> code really isn't that hard – especially
In my experience, a frequent source of bugs/frustration for developers
implementing OAuth 1.0 was the fact that we have multiple "tokens" that are
easy to mix up and use in the wrong place. For instance, when I helped Dave
Winer debug his implementation (see
http://josephsmarr.com/2009/02/17/implem
Just to add some more context from experience, this "two users getting mixed
together" problem happens a lot in practice, esp. when you have a mix of
server-side and client-side auth. For instance, we saw this in our Facebook
Connect integration in Plaxo--normally the user connects and Plaxo stores
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 wrote:
&g
+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
+1 to nailing down how to pass scopes, as Eran suggests (I think
space-delimited URLs is best, but that's a detail). Having implemented OAuth
with probably a dozen different providers (while at Plaxo), scopes were
always one of those things that just didn't fit cleanly into my libraries
and abstrac
I'm normally no fan of namespaces or other forms of needless complexity, and
it's true that PoCo dropped the pdata_ prefixes to all its query parameters
that we'd originally proposed, but I do think there's something helpful and
and clear about oauth_ because it makes it so clear which parameters a
15 matches
Mail list logo
