| Thread Previous • Date Previous • Date Next • Thread Next |
Its really up to you where you want to query the oa_client. Once the OA backend has requested and given you an access token, subsequent calls to retrieve statuses from oa_client will have negligible overhead (In fact, even re-instantiating a new OnlineAccountClient object on every query will have negligible overhead as its actually the OA backend that caches the token).Therefore, the easiest, stateless way to do this is to simply construct a new OnlineAccountClient object everywhere you need the token (as shown in the API example). This way it doesn’t matter what state your scope is in / was in, and you’ll always guarantee an up-to-date token. The OnlineAccountClient class was designed to construct and destruct efficiently for this very purpose.
I did not appreciate this. I had thought each construction of an OnlineAccountClient would hit the oauth server again, so I was trying to do my own caching. But it looks like I needn't do that. I'll make the change an instantiate a new client each time I need it. I assume this will also protect me from expiring tokens?
Not sure I understand what you mean “start up in an arbitrary state”. The scope will simply start again from fresh (i.e. a fresh process is started).
I had been assuming that the scope would always run a query first, so my authentication check is only on the query. But if the dash is displaying the results of a query and the scope is killed and restarted, the first action it takes might be a preview. This is just another reason to not try to cache the credentials but to create a new client for each request.
So yeah, wherever in your code you could expect an authentication failure, you’ll need to handle it there and then. I’m not sure I understand what you mean by anywhere though. Can you give me an example of a point where you could get an authenticating failure that would leave you in an unrecoverable state?
One example: On my previews, I have several actions that trigger a call to the server. What should I do when that call fails? I'm not in a position to add any UI elements here, so I don't see how to prompt the user to log in again.
However, if I construct a new OnlineAccountsClient for each of these calls, I shouldn't have to worry about tokens timing out (right?), so the only failure mode would be the online accounts backend being unable to authenticate. But the backend has obviously already authenticated at least once, since I was able to get to a preview page. They only ways I can get into this state are if the remote server goes down (in which case I can't do anything about it) or if the user removes their online account in the middle of using my scope (in which case they deserve brokenness.)
If you do want to pass a single oa_client object around (instead of reconstructing a new one every time you need it), what you should be able to do is simply call oa_clinet->refresh_service_statuses() when your token is no longer valid (401 returned). This should refresh the held token so that the next time you call get_service_statuses() you’ll receive the new one.... Does that sound more like what you need?
That's what I'd need with my current approach. But you've already convinced me that my current approach is wrong. :)
Thanks for the detailed answers, Robert
| Thread Previous • Date Previous • Date Next • Thread Next |
