hipchat: add oauth support

[sean@…]

It doesn't seem (unless I'm missing it) that the hipchat protocol implements oauth:

	if (strcmp(acc->prpl->name, "hipchat") == 0) {
		set_setstr(&acc->set, "server", "chat.hipchat.com");
	} else {
		set_add(&acc->set, "oauth", "false", set_eval_oauth, acc);

		/* this reuses set_eval_oauth, which clears the password */
		set_add(&acc->set, "anonymous", "false", set_eval_oauth, acc);
	}

It appears that the if statement checks for hipchat, then skips setting the oauth. I'm willing to help implement / test this with some guidance :-)

[dx]

Oh hi smf!

Back when I implemented this, oauth only existed as something that provided you tokens *after* password login, to access api stuff (the oauth2_token="true" attribute)

This new thing seems to be nicely documented in ​https://docs.atlassian.com/hipchat.xmpp/latest/xmpp/auth.html

Oddly it doesn't document the hipchat-style plain auth that we use, and which looks very similar to this one. The older docs do have that:

​https://ecosystem.atlassian.net/wiki/display/HCDEV/HipChat+XMPP+Protocol+Documentation#HipChatXMPPProtocolDocumentation-Authentication

[anonymous]

Yeah, we're going through some (extremely annoying) internal changes about auth (SAML if you're wondering). I figured a good place to start would be the OAuth dance but I see that the struct is hardcoded to google.

[dx]

Yeah, there used to be more options (msn and facebook xmpp, both dead), with google as the fallback (since it can handle any domain). Since there's no standard way to negotiate those parameters and it's all out of band, there's no option but to hardcode. It's fine.

So uh I take back the thing about "nicely documented". The XMPP docs mention how to feed it the token, but not how to get it. The queries to get tokens seem to be meant for getting an oauth2 token for api access after password auth.

Personal access tokens exist, but that's not quite what one would expect from an oauth flow.

Is the ​installation flow the only reasonable way to get tokens / client ids? Looks ugly. The server-side flow won't work, the client side flow still requires interacting with some web page but it's like three steps for the first time auth. It makes personal access tokens look good.

The "User token" section of the following page seems to describe a reasonable way to get oauth tokens:

​https://developer.atlassian.com/hipchat/guide/hipchat-rest-api/api-access-tokens

Except for the part where we can't just register an application to get that "oauth id", like every other service allows us to do. It seems to expect us to do the installation flow even for that case.

Found this support answer: ​https://answers.atlassian.com/questions/32989448/writing-hipchat-client-hipchat-authentication

Rich Manalang Dec 17, 2015

This is currently not possible. The flow you described with the com.atlassian.hipchat.win-clients oauth id is used internally inside our new desktop and mobile clients. The only other way to obtain an access token via a 3-legged oauth flow is to create an add-on that you have to require a HipChat customer to install. Our OAuth tokens are scoped by group. We don't have allow global tokens. Sorry about that.

Welp.

And yeah, the desktop client accesses this url:

https://www.hipchat.com/users/authorize?
response_type=code&
client_name=com.atlassian.hipchat.lin-clients&
scope=view_group%20view_messages%20admin_room%20view_room%20send_message%20send_notification%20manage_rooms&
redirect_uri=hipchat://hipchat.com/authorized&
state=0.0542556

Fancy. Looks exactly like what I wanted out of this. But even if I wanted to use that, it's useless with that redirect_uri.

(BTW, the bitlbee website has a generic oauth2 redirect_uri handler at ​https://bitlbee.org/main.php/oauth2.html?code=etc - but ideally that website shouldn't be an intermediary for anything. Google for example has a special redirect uri, urn:ietf:wg:oauth:2.0:oob, that shows a textbox without redirecting)

This looks awful. I really wanted to help you here, but this doesn't look like it can work.

Well, other than telling the user to enter a personal access token. After reading all these things, those look like the best thing ever.

[sean@…]

(hipchat) (fistshake)

My will for using HipChat is already dangerously close to zero. This tomfoolery from HipChat almost seals the deal for me.

[dx]

Well I went ahead and did it anyway, asking for personal access tokens like this:

Open this URL and generate a token with 'View Group' and 'Send Message' scopes: ​https://hipchat.com/account/api

It's rough but it works. For self hosted instances just pick the equivalent url instead of that one.

​https://github.com/bitlbee/bitlbee/commit/67ea361f9f8b2a197e8e52055e4d779a36a876f5

Rather unusual for me to be this motivated to implement a whole new feature. Figuring out the source of this motivation is left as an exercise for the reader.

[sean@…]

Woah! You are a gentleman and a scholar! If you're in the Bay Area, belak and I will buy you many drinks!

[dx]

<3

BTW, the docs didn't mention that the send_message scope is required, and in some situations admin_room, manage_rooms and admin_group might be needed too. As far as I can see, bitlbee doesn't implement any of the features that require those scopes (/kick is close, but nope). I could be wrong, please test.

The docs also have the wrong base64 encoded payload in the example, but that's nitpicking.

[sean@…]

I will let the hipchat team know! :-)

[dx]

And now it's merged to master.