Java oauth-core library does not support "xoauth_*" parameters

Bmkaradia / oauth

Automatically exported from code.google.com/p/oauth

0 stars 0 forks source link

Java oauth-core library does not support "xoauth_*" parameters #108

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago

What steps will reproduce the problem?
1. Create a new OAuthMessage
2. Add 
3.

What is the expected output? What do you see instead?
I see the "standard" OAuth headers correctly serialized into the
Authorization header.  I need to also see any "xoauth_" values in there as
well.

What version of the product are you using? On what operating system?
20090121

Please provide any additional information below.
I have a forked version of the oauth-core library building locally that has
this very simple one line change, but think the community would benefit. 
For anyone using any xoauth_ parameters, this would remove quite a bit of
annoyance from using the library.

Original issue reported on code.google.com by justin.t...@gmail.com on 17 Jun 2009 at 5:27

GoogleCodeExporter commented 8 years ago

I intended this to be an enhancement, not a bug.

Original comment by justin.t...@gmail.com on 17 Jun 2009 at 5:28

GoogleCodeExporter commented 8 years ago

I'm reluctant to implement behavior that doesn't conform to the OAuth 
specification, 
which seems pretty clear: xoauth_ parameters should not be send in the 
Authorization 
header.  http://oauth.net/core/1.0/#consumer_req_param

Why do you need this?  Is there a service provider that requires it?

Original comment by jmkrist...@gmail.com on 18 Jun 2009 at 4:54

Added labels: Lib-Java, Type-Enhancement

GoogleCodeExporter commented 8 years ago

The spec *prohibits* sending custom parameters with the "oauth_" prefix (section
4.2), but allows SPs to require others. The use of "xoauth" (or "x-oauth") is an
emerging solution, though far from standard or agreed.  For me specifically, 
some of
Intuit's services require "xoauth_".

The values need to be passed in the Authorization header so they are signed 
along
with the other OAuth param values.

As you may be aware, there's also a discussion here:
http://wiki.opensocial.org/index.php?title=Gadgets.io_(v0.9)
http://wiki.oauth.net/Extensions

If you don't think it's right yet to support this in the library, ensuring that 
the
appropriate methods in the OAuthMessage class are public or protected will at 
least
mean we don't have fork the library source to support this.  That'd be a big 
help by
itself.

Original comment by justin.t...@gmail.com on 18 Jun 2009 at 4:06