V2 tokens expire after 1 year.

[skoczen]

The token for one of the very first will instances (maybe the oldest living) just expired, rather unexpectedly. Everyone else's installs will also be expiring then, as time passes - it turns out hipchat has a (somewhat undocumented) one-year expiration on all V2 tokens.

I have an open issue with Hipchat on this, and am hoping to have a long-term fix so this never comes up again.

The short-term fix is to regenerate will's personal token, and update all of your instances and environments (I know, this is a complete pain. If you're not yet expired, I'd say wait for a more permanent solution.)

I'll keep this issue updated with information as I have it.

[skoczen]

Update from Hipchat:

You can obtain a long-lived "client token" over that connection. Every time will logs in and re-requests that token, it should reset the expiration, so theoretically that token won't expire as long as will is in regular use.

When you send the stanza over XMPP, also send along a oauth2_token="true" attribute (see docs here). The subsequent stanza should have an oauth2_token attribute containing your shiny new client token, which you can use on API v2. Also worth noting that token has a higher rate limit (500 over 5 minutes, instead of 100 over 5 minutes).

Will have to dig into how doable this is via sleekxmpp, but it's a great start.

If anyone else has free cycles, just ping on this issue and dive in. Help is welcome.

[skoczen]

Tried to get this in, but it's not so simple. Going back and forth with hipchat on this, more brains and smarts are welcome!

[quinox]

In the meantime perhaps Will can warn rooms about expiring tokens a few days before it happens?

[skoczen]

The challenge is that we don't know how old the token is, afaik. If you find a method that will let us verify a token's age and expiry reliably, I'm all in on that - the XMPP solution has been a nightmare.

[quinox]

I'll look into it this weekend.

If my search doesn't yield any results I can think of another easy solution: An optional variable in the default config that you can set with the expiration datetime with a comment explaining why it's there.

[brandonsturgeon]

@quinox Hi there!

It's been awhile. Did you ever find anything interesting that might help warn users about an expiring key?

[quinox]

It's been quite a while since I switched away from Hipchat to something else; if I recall correctly I only spent a little bit of time on it but didn't find anything useful.

[khanhzynga]

The one year expiry is pretty annoying as I rely on the API for my bots.

Trying the above method, I was able to construct a xmpp query: <iq to='conf.hipchat.com' type='get'><query xmlns='http://hipchat.com/protocol/auth'/></iq>

sent and got back a token: <iq from='conf.hipchat.com' id='3406' to='12345_12345@chat.hipchat.com/bot||proxy|pubproxy-b600.hipchat.com|5262' type='result' xmlns='jabber:client'><query xmlns='http://hipchat.com/protocol/auth'><token expiration='1496527056' ttl='86400'>QQfWVBnsUWLtnZW</token></query></iq>

However, when I tried to use the token on an API, it gave me an error: https://api.hipchat.com/v2/user/my@email.com?auth_token=QQfWVBnsUWLtnZW

{ "error": { "code": 401, "message": "Invalid OAuth session", "type": "Unauthorized" } }

Any help? Thanks

[skoczen]

@khanhzynga yeah, I think that's where everyone got stuck - hipchat has multiple competing auth and ID systems - it's crazy and really frustrating.

[skoczen]

So I'm closing this up, as it's all going to be made moot when Stride hits and HipChat is killed. This is still an issue, and it'd be possible to architect around it, but given that it doesn't seem like HipChat will be around in six months, I'm not sure the cost/benefit makes sense.

All - please reopen if you disagree!