Recommended strategy for permanently-connected API client in a network server (i.e. not an end-user device)

I feel as though I’m missing something here:

  • I have a continuing requirement to collect events from Cores calling Spark.publish(). The collector is in a data centre and not part of a web app with users. (It is, in effect, a cron job calling curl.)
  • The 90-day API token expiry makes sense for end-user devices: the user is right there, ask for a password if the token has expired.
  • This is not true for a non-end-user device/application (notably: a server of some sort which is also a client of the Spark API and which does not present a user-interface).
  • To date I’ve been setting calendar reminders to manually re-generate tokens, however this is far from ideal.
  • I had assumed that spark-cli dealt with this and finally got around to looking at spark-cli today but note that it only stores the token anyway.
  • So far as I can tell, the only way to do this is to store the username and password (which rather defeats much of the purpose of using tokens in the first place) and hand-code something to perform a login-and-generate-new-token operation more frequently than every 90 days.

Have I missed something? What is the recommended strategy for a permanent client in a non-end-user device?

While I am sure there are others more in the know than I am I’ll take a stab at it.

My understanding is that currently, there isn’t a really good way to solve your problem (yet). There has been talk of implementing custom key expiration. I imagine the final “solution” will be something like a dashboard for your keys. Some keys will have limited powers and never expire (like for your application) unless deleted while other keys will be just like they are now. Until Spark implements per-key permissions or at least allows for persistent keys I think your current method, while annoying, is the best.

In order to make your job a tiny bit easier it wouldn’t be hard to write a custom script, that when invoked, asked for your user details and automatically requested and saved a new key (via the API). That way you would only need to remind yourself to do the update and run the update script manually. You might already be doing this.

@harrisonhjones, perhaps @Dave has some thoughts on the key management implementation timeframe. :smile:

True, I figured he would probably know the schedule but he’s traveling this weekend I think. I’ll ping him on Monday if he doesn’t reply sooner.

Just to be clear: my post was pure speculation but it is based on what I see as a logical next step. @Dave will indeed know more.

1 Like

Heya @rolandturner,

Good questions! We’re working an a more complete oauth implementation that will support something called ‘refresh tokens,’ as well as allowing setting expiry dates for tokens when they’re created, and more granular access controls. We also have a beta running for a webhooks feature that will make it easier to collect published events, sparing you from the need to run a curl script on a cron job. :slight_smile:

tl;dr; lots of features coming that address your exact questions. :slight_smile:


1 Like