When token auto-refreshed, how does client know?

[marknadig]

I'm trying to work through how a user would detect that a requested failed initially due to an expired token and a successful refresh took place, providing a new access_token and refresh_token that the client may want to save. Any thoughts?

My current approach is to subclass session and override refresh_token to save off new tokens after calling super. I didn't know if there was a better pattern for some how passing this in the config; e.g. a proc or...

[bcoe]

I wonder if we should just make auto-refresh a configuration setting in the client. Then we could simply raise the 401, and the application using ruby-box can perform the refresh, save the token, and retry the operation itself (seems like a bit of architectural overhead, to try to pass in a proc or block).

[marknadig]

I'm trying to visualize what this looks like. Making it an option is the most flexible. However, having to wrap all calls w/ begin/rescue would be a pain. I would just subclass session and override the request method for the rescue behavior - so either way I'm subclassing session to handle this.

Just kicking around idea... config could include, instead of a block, on object that supports the refresh_token method and default is self.

[bcoe]

Finishing up my work day right now, but I plan on hacking a lot this weekend; let's hammer out some gists, and figure out something that feels slick 👍

[marknadig]

cool - not sure if the wife will let me turn on the computer this weekend, but I'll try to.

[cburnette]

Because every API call could be coming with different tokens we will need to figure out a way to notify per call that a certain token was refreshed. Something like an event with old tokens/new tokens. I am mostly familiar with .net so I'm not sure how idiomatic Ruby would handle such a thing. Because the Box tokens cycle every few hours this is a very important feature. And because every single call could result in a new token for a particular user we need to get this right.

Chad

Sent from my iPhone

On Mar 7, 2014, at 6:43 PM, Mark Nadig notifications@github.com wrote:

cool - not sure if the wife will let me turn on the computer this weekend, but I'll try to.

—
Reply to this email directly or view it on GitHub.

[cburnette]

I just started working at Box a few months ago, by the way. I spent the last year at a Ruby on Rails based startup. Just a little background. Hoping to help out on this project.

Chad

Sent from my iPhone

On Mar 7, 2014, at 6:43 PM, Mark Nadig notifications@github.com wrote:

cool - not sure if the wife will let me turn on the computer this weekend, but I'll try to.

—
Reply to this email directly or view it on GitHub.

[bcoe]

What if we do something like this:

module RubyBox
  class Session
    attr_accessor access_token

    # block to execute after a successful
    # refresh of the access token.
    def after_refresh(&block)
      @after_refresh = block
    end

    def request
      if response.code == 401
        refresh_token(@refresh_token)
        yield(@after_refresh) if after_refresh
      end
    end
end

Someone using ruby-box could then use the access token accessor, and the block, to update a database entry when a refresh occurs.

[marknadig]

@bcoe that would mean I would have to

client_id = '…'
client_secret = '…'
ut = MyTokenTable.find(…)

session = RubyBoxSession.new({
  client_id: client_id,
  client_secret: client_secret, 
  access_token: ut.access_token,
  refresh_token: ut.refresh_token
})

session.after_refresh { |new_token| 
  ut.refresh_token = new_token
  ut.save!
}

I think we need to yield the new token in the request method as well.

Or, this is what I think it looks like if we pass it in as part of the config:

session = RubyBoxSession.new({
  client_id: client_id,
  client_secret: client_secret, 
  access_token: ut.access_token,
  refresh_token: ut.refresh_token,
  after_refresh: Proc.new(|new_token| ut.refresh_token = new_token; ut.save}
})

and the body of RubyBox::Session.request is pretty much the same - again, yielding the new token.

[marknadig]

Instead of blocks/procs, I had thought it more appropriate to define a TokenManager role that handles getting access_token, refresh_token and tokens_changed; e.g.

def MyTokenManager
  def initialize(user)
     @token = MyTokenTable.find(user)
  end
  def access_token
    @token.access_token
  end
  def refresh_token
    @token.refresh_token
  end
  def tokens_changed(new_access_token, new_refresh_token)
    @token.new_access_token
    @token.refresh_token = new_refresh_token
    @token.save!
  end
end

session = RubyBoxSession.new({
  client_id: client_id,
  client_secret: client_secret, 
  token_manager: MyTokenManager.new(user)
})

I think this makes the intent more clear.

[bcoe]

I like the simplicity of a block, but the TokenManager approach seems reasonable too; thoughts @cburnette.

[marknadig]

And, for what it is worth - subclassing Session and overriding refresh_token works :)

[bcoe]

@marknadig maybe updating the documentation, and demonstrating this subclassing trick would be sufficient.

[marknadig]

Sounds good - I can take a crack at it if that helps.

[bcoe]

That would help, maybe add a new section:

Storing Refreshed Access Tokens