Has anyone succesfully validated the signature passed to your server through opensocial.Container.get().makeRequest()?

Do you know which which parameters are being encoded - all of them, or just the ones starting with oauth / opensocial? Do they need to be utf8 encoded/decoded? How does the key factor in?

We've started by using the same code to authenticate that we use to (succesfully) send requests to Myspace, but the results don't match up, and we've already tried a large number of combinations trying to figure it out.

Please respond if you've gotten this to work. If you could post code (in any language), that would be fantastic.

Thanks,

David 

We're having the same issues.  We can't generate a matching digest -- one that matches the oauth_signature passed in the request.  I've been trying to get a successful authentication all yesterday.

I'm fairly confident that our implementation of the HMAC-SHA1 authentication algorithm is correct.  Since firstly, we are verifying our results using the 'text', 'key' and 'digest' shown in the OAuth specs at:

http://oauth.net/core/1.0/#encoding_parameters 

 (One of the posters in this forum suggested doing this, great suggestion btw)

And second, we have implemented the HMAC-SHA1 algorithm in 2 different ways and resultant digests from both agreed with one another.

Assuming there are no bugs with Myspace's HMAC-SHA1 implementation,  this leaves 2 possibilities for why authentication continues to fail.  Either we are not generating the correct 'key' or we are not generating the 'text' correctly.  

* This is how we create the key:

We get the key by going to the "My Apps" in the developer console,  then click on "Edit Details" on our app, and finally we grab the 32-character string in the "Security Key" field.  We finally append an ampersand "&" to the end of this security key.  If you're "security key" looks like this: "fa0f82dea01f430d91897811b102d9b" then the actual key looks like : "fa0f82dea01f430d91897811b102d9b&"

Is this correct? 

* We generate the 'text' by following this spec:

 http://developer.myspace.com/community/RestfulAPIs/authentication.aspx

And it looks like this: 

GET&http%3A%2F%2F64.14.197.45%3A8085%2Fluke%2Fopensocial%2FCREATE_MAP&oauth_consumer_key%3Dhttp%253A%252F%252Fwww.myspace.com%252F350524073%26oauth_nonce%3D633409375350983265%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1205340735%26oauth_token%3D%26oauth_version%3D1.0%26opensocial_owner_id%3D349923765%26opensocial_viewer_id%3D349923765%26ownerId%3D349923765%26ownerType%3DMYSPACE

(NOTE: the oauth_signature and realm are the ONLY excluded request string parameters.  The other parameters are alphabetically ordered by param name, and then are individually URL encoded. The entire concatenated parameter string as a whole is then URL encoded again. )

The base string is made up of three sections that are separated by ampersands as such:

(http method in caps) &(URL encoded request url excluding the query string)&(URL encoded, ordered param list)

Finally when comparing the oauth_signature to our digests we Base64 encode OUR digests.  You could conversely Base64 DECODE the oauth_signature.

Upon doing this  OUR digest is different from that passed in the oauth_signature.

Any assistance would be greatly appreciated. 

I've gotten this working in python (http://code.google.com/p/myspace-python/).  The only issue I ran into when implementing it was that at first I was only generating my digest against the uri + parameters.  Once I started including the full url (http://.....) my digest matched up.  One person reported that myspace deviated by including empty parameters (key, but no value) in the url when generating their digest, but the oauth library (python one anyways) excluded those.
 

We just use the same signature method we use for sending requests to the REST server (which work), but we don't know the exact params & format needed, and not sure about what do do with method, etc, so it fails. We tried a bunch of different things, and none return the right key...

David 

 Eric,

 I don't know python, so maybe I'm missing something, but I glanced through your code, and I'm not seeing a validation method. Are you sure you don't mean requests to the REST server?

We aren't having trouble making requests to Myspace, we're having trouble validating requests coming FROM myspace.

If I'm just not seeing it, could you point out where in the code you do this? 

David 

I've been able to successfully do this in perl.. but I encountered one problem where MySpace doesn't follow the spec... if your URL has a tilde ~ character, MySpace will calculate an incorrect signature because it encodes the tilde as %7E in the base string it uses to generate the signature. If in your implementation you correctly exclude the tilde from uri escaping (OAuth Core 1.0 spec section 5.1) then the signatures won't match.

Other than that, as long as you normalise the parameters (all of the parameters) for the base string according to the spec it should work fine. Let me know if you need more details.

David,

take a look at 'verify_request' at line 169 of apps.py (http://code.google.com/p/myspace-python/source/browse/trunk/myspace/app.py)

It relies heavily on the python oauth client (from http://oauth.net/code/), but they have very similar implementations for various languages.  I made a few minor patches to their oauth client which is include in my code base (http://code.google.com/p/myspace-python/source/browse/trunk/myspace/oauth/oauth.py)

Hey guys I found OUR problem, you may be experiencing the same issue if you receive consumer requests to a PORT other than 80 or 443!  The Myspace Developer Platform has a bug in their implementation of PORT scrubbing in the build out of base strings.  

Essentially they are removing ALL PORT numbers when scrubbing the request URL.  Thus if you receive proxied opensocial makeRequests() to something like:

http://example.com:8080/path

When calculating the base string for the signature, MDP is cutting the PORT and only using: 

http://example.com/path

According to OAuth spec 9.1.2. ( http://oauth.net/core/1.0/#anchor14 ) they should ONLY remove PORT numbers 80 and 443 (this is to eliminate redundancy since these port numbers are implied by the HTTP/HTTPS and will usually NOT show up in a request) while other port identifiers MUST remain in the string.  Currently they are removing ALL port identifiers.

According to OAuth spec 9.1.2: 

"The Service Provider SHOULD document the form of URL used in the Signature Base String to avoid ambiguity due to URL normalization. Unless specified, URL scheme and authority MUST be lowercase and include the port number; http default port 80 and https default port 443 MUST be excluded."

We now have a working request authenticator.   Thanks all.

Eric,

Oops, did'nt see that part. Thanks a lot - we'll see if we can get it to work. I think our issue was the lack of url. 

David 

anyone seen or know how to fix the issue below? I am using  oauth.py to verify makerequest.

Thank-you in advance!

Traceback (most recent call last):
  File "/base/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 501, in __call__
    handler.post(*groups)
  File "/base/data/home/apps/myapp/1.17/opensocial/myspace/myspace.py", line 130, in post
    signed = verify_oAuthRequest(self.request)
  File "/base/data/home/apps/myapp/1.17/opensocial/myspace/verify.py", line 25, in verify_oAuthRequest
    return verify_oAuthRequestHelper(MYSPACE_KEY, MYSPACE_SECRET, request.method, url, params)
  File "/base/data/home/apps/myapp/1.17/opensocial/myspace/verify.py", line 44, in verify_oAuthRequestHelper
    oauth_request, MockConsumer(secret), oauth.OAuthToken('', ''))
  File "/base/data/home/apps/myapp/1.17/oauth.py", line 502, in build_signature
    escape(oauth_request.get_normalized_parameters()).replace("%255CU", "%25"),
  File "/base/data/home/apps/myapp/1.17/oauth.py", line 163, in get_normalized_parameters
    key_values = params.items()
  File "/base/python_lib/versions/1/webob/multidict.py", line 400, in items
    k, v in self.multi.iteritems()]
  File "/base/python_lib/versions/1/webob/multidict.py", line 296, in _decode_value
    value = value.decode(self.encoding, self.errors)
  File "/base/python_dist/lib/python2.5/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2665' in position 17: ordinal not in range(128)