hipchat / hipchat-rb

HipChat HTTP API Wrapper in Ruby with Capistrano hooks
https://www.hipchat.com/docs/apiv2
MIT License
336 stars 172 forks source link

v1.6.0 Breaks OAuth #202

Closed baburdick closed 6 years ago

baburdick commented 7 years ago

Downgrading works around this issue:

Access denied to room `Deployments':
Response: {
  "error": {
    "code": 401,
    "message": "Invalid OAuth session",
    "type": "Unauthorized"
  }
}
~/.rvm/gems/ruby-2.2.4@my_service/gems/hipchat-1.6.0/lib/hipchat/errors.rb:52:in `response_code_to_exception_for'
~/.rvm/gems/ruby-2.2.4@my_service/gems/hipchat-1.6.0/lib/hipchat/room.rb:160:in `send'
~/.rvm/gems/ruby-2.2.4@my_service/gems/hipchat-1.6.0/lib/hipchat/capistrano/tasks/hipchat.rake:46:in `block in send_message'
~/.rvm/gems/ruby-2.2.4@my_service/gems/hipchat-1.6.0/lib/hipchat/capistrano/tasks/hipchat.rake:44:in `each'
~/.rvm/gems/ruby-2.2.4@my_service/gems/hipchat-1.6.0/lib/hipchat/capistrano/tasks/hipchat.rake:44:in `send_message'
~/.rvm/gems/ruby-2.2.4@my_service/gems/hipchat-1.6.0/lib/hipchat/capistrano/tasks/hipchat.rake:16:in `block (2 levels) in <top (required)>'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:250:in `call'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:250:in `block in execute'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:250:in `each'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:250:in `execute'
~/.rvm/gems/ruby-2.2.4@my_service/gems/airbrussh-1.3.0/lib/airbrussh/rake/context.rb:62:in `execute'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:194:in `block in invoke_with_call_chain'
~/.rvm/rubies/ruby-2.2.4/lib/ruby/2.2.0/monitor.rb:211:in `mon_synchronize'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:187:in `invoke_with_call_chain'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:180:in `invoke'
~/.rvm/gems/ruby-2.2.4@my_service/gems/capistrano-3.8.2/lib/capistrano/dsl/task_enhancements.rb:16:in `block in after'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:250:in `call'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:250:in `block in execute'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:250:in `each'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:250:in `execute'
~/.rvm/gems/ruby-2.2.4@my_service/gems/airbrussh-1.3.0/lib/airbrussh/rake/context.rb:62:in `execute'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:194:in `block in invoke_with_call_chain'
~/.rvm/rubies/ruby-2.2.4/lib/ruby/2.2.0/monitor.rb:211:in `mon_synchronize'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:187:in `invoke_with_call_chain'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/task.rb:180:in `invoke'
~/.rvm/gems/ruby-2.2.4@my_service/gems/capistrano-3.8.2/lib/capistrano/dsl.rb:26:in `invoke'
~/.rvm/gems/ruby-2.2.4@my_service/gems/capistrano-3.8.2/lib/capistrano/dsl/task_enhancements.rb:53:in `exit_deploy_because_of_exception'
~/.rvm/gems/ruby-2.2.4@my_service/gems/capistrano-3.8.2/lib/capistrano/application.rb:73:in `exit_because_of_exception'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/application.rb:188:in `rescue in standard_exception_handling'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/application.rb:178:in `standard_exception_handling'
~/.rvm/gems/ruby-2.2.4@my_service/gems/rake-12.0.0/lib/rake/application.rb:77:in `run'
~/.rvm/gems/ruby-2.2.4@my_service/gems/capistrano-3.8.2/lib/capistrano/application.rb:14:in `run'
~/.rvm/gems/ruby-2.2.4@my_service/gems/capistrano-3.8.2/bin/cap:3:in `<top (required)>'
~/.rvm/gems/ruby-2.2.4@my_service/bin/cap:23:in `load'
~/.rvm/gems/ruby-2.2.4@my_service/bin/cap:23:in `<main>'
~/.rvm/gems/ruby-2.2.4@my_service/bin/ruby_executable_hooks:15:in `eval'
~/.rvm/gems/ruby-2.2.4@my_service/bin/ruby_executable_hooks:15:in `<main>'
rberrelleza commented 7 years ago

Thanks for reporting this. I haven't been able to reproduce this by just using the hipchat client, so I'm wondering if this is related to the type of hipchat token that Capistrano is using.

Are you using a token from https://atlassian.hipchat.com/account/api, or from https://atlassian.hipchat.com/admin/api?

rberrelleza commented 7 years ago

I believe I know what's going on. On 1.6.0, we changed the default API version from v1 to v2 (https://github.com/hipchat/hipchat-rb/commit/2a8b6e0ced6ff12fdc86f2a130ec8f3cd033ee96). This is causing the Capistrano task to call the v2 APIs instead of the V1, which causes authentication issues.

Setting the api_version to v1 on your task should fix the authentication issue for you: set :hipchat_options, { :api_version => "v1" }

Could you let me know if this solves the issue for you? I'll update the release notes to make this more obvious.

pabse commented 7 years ago

This works for me. 👍

But how should we implement the v2 now? We are using the Capistrano Integration from the Hipchat Marketplace, but it only generates a v1 token. I can only generate personal v2 token. But this would result in a Hipchat message from the token owner saying "Z is deploying". Am I missing something?

baburdick commented 6 years ago

I was able to generate v2 Room tokens to solve our issues. It was a simple change that took a while to research. I did not try the workaround: set :hipchat_options, { :api_version => "v1" }. In the meantime, we just didn't upgrade.

This issue can be closed.

rberrelleza commented 6 years ago

This is by design. On 1.6.0 we switched the default api_version from v1 to v2. If you need to use a v1 token, then you should update your code to set the api_version, as described above.