Using matterircd with Gitlab authentication

[chhitz]

I have enabled Mattermost (v1.3) that was installed with my Gitlab instance. It is set-up to use Gitlab for login. From matterircd (v0.2) I get the following error:

2016-01-27 09:48:22.590 DEBUG -> :mattermost!mattermost@service PRIVMSG chitz :Please sign in using gitlab

How can I get matterircd to work in this setup?

[ghost]

I'm also interested in this, but I doubt that it is possible at the moment without any modifications. My first guess is that it would require modification of mattermost itself, and not matterircd.

[42wim]

Not possible for now, I think mattermost only allows 1 oauth sign-in (gitlab or github) (and I guess this patch needs to be merged also mattermost/mattermost#1938 before matterircd can use oauth)

My knowledge about oauth is very limited though. Smarter people are always welcome to help out :)

[nnewman]

I've been playing around with both mattermost and matterircd for a few weeks now and i'm just getting around to OAuth. It's something that I'm interested in trying to implement for matterircd, but my knowledge of Go up to this point is limited. I'm wondering, if you were to go about implementing support for OAuth, if you had any suggestions as to how you would approach it?

Thanks! And also thank you for making matterircd, its been very useful in convincing my colleagues to give mattermost a try, as a platform.

[dwest-galois]

I would also like to make a feature request for this. The Omnibus version of Mattermost only supports Gitlab SSO via Oauth, which is not usable by IRC clients such as irssi. One alternative I have found is to allow users to convert their account authentication from Gitlab SSO to Email/Password. Then they are able to use standard usernames and passwords to authenticate with their IRC clients. That is not a viable large scale solution since it fragments the authentication for users and makes administration more difficult. If matterircd could support Oauth, then that would be the preferable solution. Otherwise, Mattermost Omnibus would need to either support LDAP authentication separately or maybe even reuse the Gitlab LDAP configuration since it is already present in the gitlab.rb file.

[Feandil]

Could you support at least setting the auth token manually? (e.g. using https://github.com/mattermost/platform/blob/master/model/client.go#L1282)

(It's rather easy to obtain one, e.g. from the cookie in your web-browser and should work)

[42wim]

@Feandil great idea, I got it working. Commit coming up soon.

[42wim]

@Feandil Ok, rebuild from master, and you should be able to login by
/msg mattermost LOGIN <server> <team> <login> MMAUTHTOKEN=yourtoken
Let me know if it works, thanks.

[Feandil]

Thanks, login seems to work like a charm here :)

However, I just hit a bug I think:

2016-05-24 13:29:24.724 CRITICAL websocket: close 1006 (abnormal closure): unexpected EOF
DEBU[2016-05-24T13:29:24+02:00] trying login ${team_name} ${username} $(server}  module=matterclient
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x20 pc=0x5f196b]

Could there be an error in the automatic login part ? (the '$' part was replaced by me)

[42wim]

I've updated master to show a bit more debug information, can you reproduce ?
And can you also paste the full trace after panic ? thanks

[trou]

MMAUTHTOKEN=yourtoken would be very nice to have in 0.5. Would you consider it backporting it ?

[42wim]

@trou no sorry, older versions of mattermost have security problems. You should upgrade to mattermost 3.x (https://about.mattermost.com/security-updates/)

[Feandil]

Sorry, I have not been able to reproduce the bug so far. Please ignore my previous comment and sorry for the noise

[kerhac]

It is also possible to use the mattermost Personal Access Token instead of the session token. The Personal Access Token does not expire.

[TC01]

It is also possible to use the mattermost Personal Access Token instead of the session token. The Personal Access Token does not expire.

If I am reading the documentation correctly, though, only mattermost admins get those by default and they have to explicitly enable them for non-admin users. I don't think this is really a workable replacement for the gitlab tokens.

It is not clear to me why this is an admin-only feature that is off by default though.

[ltning]

If the reasoning here is that it's not enabled by default, then I think personal access tokens should still be the value to use. I don't know if there is a technical reason not to use them. Determining the MMAUTHTOKEN is not entirely trivial, and it's surely not something you can expect most people to figure out.

A big reason to use the PATs is that they can be revoked or disabled if lost or compromised.

If either approach can be used, then I'd like to see both. My 2 cents :)

[TC01]

Sure, I agree it would definitely be nice to support both. My point was just that switching to only use the personal access tokens would be bad-- since not all users can necessarily create them.

[tobast]

Hello,
Is there any progress on integrating personal access tokens? I'm interested in using this, and I might consider implementing it if the maintainer is fine with it and if no one is working on it yet.

[kerhac]

@tobast It is already possible to use the personal access token instead of the mmauthtoken.

/msg mattermost LOGIN <server> <team> <login> MMAUTHTOKEN=<personal access token>

[tobast]

@kerhac Awesome, thank you! One fewer thing to hack before having a working Mattermost setup :)

[strigazi]

@kerhac With the actual MMAUTHTOKEN I can connect, but with a personal gitlab access token I can't.
I get: : Invalid or expired session, please login again.,
Any advice?

Update:
Oh, I see, it is the mattermost personal access token that the admin must enable and then users consume.
https://docs.mattermost.com/developer/personal-access-tokens.html

[jasonblais]

Hey @42wim and others.

Reading through this thread, it sounds like the current workarounds for GitLab login on matterircd include:

1. Copying the MMTOKEN cookie from the webapp, which is not trivial to do.
2. Creating a personal access token, which is only enabled for admins by default.

The reason we enabled personal access tokens for admins only is that these tokens were primarily intended to be used for integrations. We have bot accounts in the near term roadmap which would largely overtake the use case for personal access tokens for integrations.

That said, this second use case I'm reading about is interesting and not something we had in mind.

Are there other approaches or capabilities that Mattermost could better support GitLab (and other non-email logins) on matterircd? Or are personal access tokens the only way to go?

[42wim]

Closing this, added to the FAQ in the readme