Validate that credentials are set before calling get, post, etc.

[oma]

This happens rarely, very rarely. it does seem sporadic. This is the ruby code
Pusher.get("/channels/presence-oma.presentations.1", info: :user_count)[:user_count]
It happened once before too, back then I changed the channel name, restarted the rails app, hit reload and got the same error. Right now, I've just been idle for a long time. Yeah, I know I'm not helping much... See stacktrace:

TypeError - no implicit conversion of nil into String:
  signature (0.1.7) lib/signature.rb:173:in `signature'
  signature (0.1.7) lib/signature.rb:53:in `sign'
  pusher (0.11.3) lib/pusher/request.rb:20:in `initialize'
  pusher (0.11.3) lib/pusher/resource.rb:29:in `create_request'
  pusher (0.11.3) lib/pusher/resource.rb:9:in `get'
  pusher (0.11.3) lib/pusher/client.rb:107:in `get'
  /Users/oma/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/forwardable.rb:171:in `get'
  app/models/presentations/presentation.rb:37:in `student_count'

pusher 0.11.3
ruby 2.0.0
rails 4.0.0

[mloughran]

The stacktrace indicates that the Pusher.secret is nil. The credentials are validated when using channel objects but not when using get (search for ConfigurationError), this is a bug.

The fact that Pusher.secret is nil is a bug in your code however - maybe something is awry with initialisation?

[mloughran]

I've renamed this issue from "Pusher.get("/channels/#{channel}", info: :user_count)[:user_count] nil-pointer bug" to "Validate that credentials are set before calling get, post, etc."

[oma]

Thanks, sounds like a better name :) I'm not sure how Pusher.secret can be set to nil. We are not using Puser in any wierd way, other than that we are using presence channels and auth.

[shedd]

It would be helpful to have a friendly error message here. Ran into the same error and it was because we didn't have the configuration value set in our staging environment. Would have saved time to validate this and print a logical error message.

[ahmetabdi]

👍 @shedd

[hovsater]

I've addressed this issue in #76. This now ensures proper configuration is in place before actually executing the given request.

[zimbatm]

Fixed in master