Would it be possible to specify OAuth 1.1 based on the latest I-D and
release it before the I-D has been approved to be an I-S?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
OAuth group.
To post to this group,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/18/09 8:36 AM, Hannes Tydén wrote:
Would it be possible to specify OAuth 1.1 based on the latest I-D and
release it before the I-D has been approved to be an I-S?
I leave that to folks from oauth.net. My preference as co-chair of the
Oauth WG
[mailto:oa...@googlegroups.com] On Behalf
Of Hannes Tydén
Sent: Wednesday, September 16, 2009 5:31 PM
To: OAuth
Subject: [oauth] Re: Signing PUT request
On Sep 17, 1:12 am, Hans Granqvist h...@granqvist.com wrote:
seems to leave PUT requests with form-encoded name/value pairs in a
bad
On Sep 17, 9:55 am, Eran Hammer-Lahav e...@hueniverse.com wrote:
OAuth Core 1.0 (or a) does *not* include PUT body parameters in the signature
base string. That is a bug which I already fixed a while back in the very
first I-D:
Thank you for your clarification. But is this just a draft and
On Sep 17, 9:55 am, Eran Hammer-Lahav e...@hueniverse.com wrote:
OAuth Core 1.0 (or a) does *not* include PUT body parameters in the signature
base string. That is a bug which I already fixed a while back in the very
first I-D:
Re-reading you post made me realize that this _is_ a bug is in
Message-
From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
Of Hannes Tydén
Sent: Thursday, September 17, 2009 3:24 AM
To: OAuth
Subject: [oauth] Re: Signing PUT request
On Sep 17, 9:55 am, Eran Hammer-Lahav e...@hueniverse.com wrote:
OAuth Core 1.0 (or a) does
Too bad very few people actually bother to read the IETF drafts and provide
feedback. For the record, I had to restrain myself in that last sentence from
using offensive language.
There is no indication @ http://oauth.net/documentation/ that one is
supposed to read and discuss IETF drafts
John,
Do we have the support for this extension in the oauth java library?
On Sep 16, 12:23 am, John Kristian jmkrist...@gmail.com wrote:
No, the signature base string doesn't contain parameters from the body
of a PUT request.
There is an extension to protect request
You can implement body hashing on top of the Java library, but the
library doesn't implement it.
On Sep 16, 1:06 pm, Monis monisiq...@gmail.com wrote:
Do we have the support for this extension in the oauth java library?
--~--~-~--~~~---~--~~
You received this
We're going live with some new PUT-based APIs. The body is not name/value
pairs and thus not application/x-www-form-urlencoded.
Can anybody shed some light on the status of
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/oauth-bodyhash.html
and how it relates to OAuth main spec?
Has
BTW, this sentence in
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/oauth-bodyhash.html#when_to_include
# OAuth Consumers MUST NOT include an oauth_body_hash parameter on
requests with form-encoded request bodies.
seems to leave PUT requests with form-encoded name/value pairs in a
On Wed, Sep 16, 2009 at 4:06 PM, Hans Granqvist h...@granqvist.com wrote:
We're going live with some new PUT-based APIs. The body is not name/value
pairs and thus not application/x-www-form-urlencoded.
Can anybody shed some light on the status of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/16/09 6:31 PM, Hannes Tydén wrote:
On Sep 17, 1:12 am, Hans Granqvist h...@granqvist.com wrote:
seems to leave PUT requests with form-encoded name/value pairs in a
bad spot, not covered by the core spec (which only deals with POSTs),
nor
No, the signature base string doesn't contain parameters from the body
of a PUT request.
There is an extension to protect request bodies.
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/oauth-bodyhash.html
On Sep 15, 8:29 am, Hannes Tydén han...@soundcloud.com wrote:
When I do a POST
The OAuth Request Body Hash enables integrity checking on HTTP
request bodies with content types other than application/x-www-form-
urlencoded.
My PUT requests have content type application/x-www-form-urlencoded
and I can't see why they should be treated differently than POST
requests, though
15 matches
Mail list logo
