Invalid OAuth Request on all PUT Requests #1

Closed
pushmatrix opened this Issue Apr 27, 2011 · 16 comments

Comments

Projects
None yet
6 participants

Whenever I try to do anything involving a PUT (update_customer, update_case, etc...) I get an Invalid OAuth Request. Authentication is working for all other actions I've tried (POST & GET). Have you experienced something similar?

Owner

chriswarren commented Apr 27, 2011

Yes, I've seen this too but haven't had a chance to investigate too much yet. It appears to be a bug in Simple OAuth (https://github.com/laserlemon/simple_oauth). I'm thinking it might be the variables being url encoded after the signature, resulting in things not matching up.

I'm hoping to take a look this week at getting it resolved, but if you have time before me feel free to check it out.

I'd love to help, but I'm not sure if I'm capable. Any update on this issue?

Owner

chriswarren commented May 11, 2011

I'm talking with the team at Assistly to track down the issue. Apparently it's also happening in some Python libraries.

It sounds like the solution may be to change the code to not add the post body to PUT requests, but I haven't had a chance to dig in to it yet. If anyone wants to take a look, that'd be awesome.

Any luck with this? We're going to start using this gem actively next week. We can do some work to fix it if needed, but it would be great if it was tracked down (since our team isn't nearly as familiar with the issue).

Owner

chriswarren commented May 18, 2011

Nothing so far. I'm waiting for some word from Assistly, as it may be a bug in their API. The suggestion above is most likely a temporary solution if it is something on their end.

As for implementing the temporary solution, unfortunately I've been swamped with other stuff between work and moving next week and haven't had any time to dig in to it. I'd be happy to communicate with someone on your team if they want to dig in and do some testing on it before things calm down for me and I have a chance to test it.

I think its a bug in simple_oauth, using the oauth gem seems to fix the problem. Kinda makes sense if the Python lib has a bug, the ruby port of it would also (simple_oauth).

Owner

chriswarren commented May 24, 2011

Awesome - do you have a fork I can pull in?

Owner

chriswarren commented Jul 15, 2011

This should now be resolved. Apologies for the delay, things have been very busy around here lately. Let me know if you run in to any troubles!

I'm still seeing this, what was the resolution?

Owner

chriswarren commented Oct 20, 2011

https://github.com/zencoder/assistly/commit/162a1c065d34cc8c6d43a96b98c928826dedad58 was the commit that addressed the issue. We had to monkeypatch faraday_middleware.

I'm using 0.2.6 and following the example and getting the exact same error. I'm running the below in irb having done gem install assistly All the read operations work fine and return real data, the update commands give:

MultiJson::DecodeError: 706: unexpected token at 'Invalid OAuth Request'
    from ~/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/json/common.rb:146:in `parse'
from ~/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/json/common.rb:146:in `parse'
from ~/.rvm/gems/ruby-1.9.2-p180/gems/multi_json-1.0.3/lib/multi_json/engines/json_gem.rb:13:in `decode'
from ~/.rvm/gems/ruby-1.9.2-p180/gems/multi_json-1.0.3/lib/multi_json.rb:65:in `decode'
from ~/.rvm/gems/ruby-1.9.2-p180/gems/faraday_middleware-0.7.0/lib/faraday/response/parse_json.rb:16:in `parse'
    ...

This is what I'm running in irb:

require "rubygems"
require "assistly"

Assistly.configure do |config|
  config.support_email = "support@mydomain.com"
  config.subdomain = "mydomain"
  config.consumer_key = "20 character string from 'Key' field"
  config.consumer_secret = "50 character string from 'Secret' field"
  config.oauth_token = "20 character string from 'Token' field"
  config.oauth_token_secret = "50 character string from 'Token Secret' field"
end

Assistly.case(234)
Assistly.update_case(234, :subject => "foo")

Assistly.customer(1234)
Assistly.update_customer(1234, :external_id => 427)

Any clues on what's wrong?

BTW, I did a downgrade to 0.2.4, removing faraday and faraday_middleware to see if the updated libraries were causing a regression and I get a different but similar error:

Assistly::Unauthorized: PUT https://mydomain.assistly.com/api/v1/cases/234.json: 401
from ~/.rvm/gems/ruby-1.9.2-p180/gems/assistly-0.2.4/lib/faraday/response/raise_http_4xx.rb:12:in `on_complete'
from ~/.rvm/gems/ruby-1.9.2-p180/gems/faraday-0.6.1/lib/faraday/response.rb:9:in `block in call'
Owner

chriswarren commented Oct 20, 2011

I'm not sure right now and unfortunately don't have time to test it right now. It looks similar to the issue we were having earlier, and while I can recreate it on a blank slate I can't get it to happen anywhere I'm using it in production.

Something about the PUT requests isn't right, probably in the signature, but I'd have to do more testing to figure it out. I've tried running without the monkeypatch and get the same error, so it looks like that's not helping now. I'll try to figure things out, but feel free to take a stab at it as well.

After reading your comment I pushed a new Gemfile with Assistly in it to production and it worked. It also works in rails console but not in irb. Our Gemfile is locked so it's probably some gem dependency that's causing the problem. If I get time I'll try and pin it down using the powers of methodical trial and error.

moiristo commented Feb 6, 2012

Had the very same issue (assistly 0.2.6, faraday 0.9.6, simple_oauth 0.1.5) and I found out that the 'Invalid OAuth Request' error should really be treated as 'Something went wrong' or 'I don't know what data you just sent me, so I won't permit it'. In my case the Authorization header turned out to be fine, only the form data itself was wrong. Therefore my suggestion for other developers is to start small, for example with a customer with just a name attribute, and then extend it piece by piece.

Owner

chriswarren commented Feb 8, 2012

Cool, thanks for the info. I'll take a look at this further when I have a chance.

On Monday, February 6, 2012 at 11:15 AM, Reinier de Lange wrote:

Had the very same issue (assistly 0.2.6, faraday 0.9.6, simple_oauth 0.1.5) and I found out that the 'Invalid OAuth Request' error should really be treated as 'Something went wrong' or 'I don't know what data you just sent me, so I won't permit it'. In my case the Authorization header turned out to be fine, only the form data itself was wrong. Therefore my suggestion for other developers is to start small, for example with a customer with just a name attribute, and then extend it piece by piece.


Reply to this email directly or view it on GitHub:
https://github.com/zencoder/assistly/issues/1#issuecomment-3834771

@chriswarren chriswarren pushed a commit that referenced this issue Feb 29, 2012

Robert Ross Merge pull request #1 from andrewpbrett/patch-1
assistly.com is now desk.com
ebdc430
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment