#1265 closed enhancement (fixed)

hipchat: add oauth support

Reported by: sean@… Owned by:
Priority: normal Milestone:
Component: Unspecified / other Version: devel
Keywords: Cc:
IRC client+version: Client-independent Operating System: Linux
OS version/distro: ubuntu


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", "");
	} 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 :-)

Attachments (0)

Change History (9)

comment:1 Changed at 2016-08-29T23:28:20Z by 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

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:

comment:2 Changed at 2016-08-30T00:17:15Z by 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.

comment:3 Changed at 2016-08-30T05:54:07Z by 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:

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:

Rich Manalang Dec 17, 2015

This is currently not possible. The flow you described with the 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.


And yeah, the desktop client accesses this url:

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 - 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.

comment:4 Changed at 2016-08-30T06:32:21Z by sean@…

(hipchat) (fistshake)

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

comment:5 Changed at 2016-08-30T20:58:43Z by 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:

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

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.

comment:6 Changed at 2016-08-30T21:38:45Z by sean@…

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

comment:7 Changed at 2016-08-30T22:39:36Z by dx


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.

comment:8 Changed at 2016-09-02T20:50:12Z by sean@…

I will let the hipchat team know! :-)

comment:9 Changed at 2016-09-21T03:14:04Z by dx

Resolution: fixed
Status: newclosed

And now it's merged to master.

Modify Ticket

as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.