knock Less aggressive rescue in define_current_entity

Hi,

Could the rescue on this line look for certain errors to rescue from instead of rescuing anything?

As I was trying to setup knock I had something like this in my User model to test the auth flow:

class User < ApplicationRecord
  def self.from_token_payload payload
    throw 'in here'
  end
end

I was very confused why this method was never being called. Through a long and frustrating process I realized the rescue was swallowing my throws.

If the rescue stays as is, maybe it could log a message? Just trying to help new users of the gem moving forward as I was quite baffled for a long period of time.

Thanks!

Nov 23 '16 17:11 johnmosesman

It seems like more than a few people have had issues where swallowing the error has made it very hard to figure out what is going on. You basically have to redefine define_current_entity_getter in your app to find the problem.

I'm happy to submit a PR. What do we think about just throwing the error here?

module Knock::Authenticable
  def define_current_entity_getter entity_class, getter_name
    unless self.respond_to?(getter_name)
      memoization_var_name = "@_#{getter_name}"
      self.class.send(:define_method, getter_name) do
      unless instance_variable_defined?(memoization_var_name)
        current =
          begin
            Knock::AuthToken.new(token: token).entity_for(entity_class)
          rescue => e
            throw e    # Throw instead of return nil
          end
      ...
    end
  end

Feb 25 '17 16:02 johnmosesman

I ran into the same issue today.

I'm not sure what the best approach would be, but sometimes it would be nice to be able to get some information out on why the authentication failed. I wrote a bit of a workaround to inspect the JWT again, when authentication fails to report at least some errors like signature failures etc.