Developer Sign-In
Let your members sign in with GitHub, GitLab or Bitbucket — the accounts they already have, on the platforms they already use every day.
Invision Community ships sign-in handlers for Facebook, Google, Microsoft, LinkedIn, Apple and X. Excellent for a general community. Not much use if your members are developers.
Who this is for
- Software and open-source communities — support forums, plugin and mod communities, anywhere the conversation is about code.
- Homelab, self-hosting and sysadmin communities, where a GitHub account is more universal than a Facebook one.
- Companies running their own GitLab. A community that self-hosts its forum very often self-hosts its GitLab too, and this connects the two. Your instance address is a field on the settings screen.
- Game and modding communities whose members publish their work on one of these platforms already.
What it does
- Three providers, one application. Enable one, two or all three. Each is a separate sign-in button with its own credentials, and each can be turned on and off independently.
- Verified email addresses, carried across. This is the part that is fiddly to do by hand — see below.
- Avatars and names come across too, and you decide whether the provider's name is used or the member picks their own.
- Works alongside everything else. Passwords, existing social logins and any other handler carry on exactly as they are. A member can link a provider to an account they already have, from their account settings, and unlink it there just as easily.
- Self-hosted GitLab is supported properly, not as an afterthought — every address the handler uses is built from the instance you name.
The email problem, and why it is worth paying to skip
Invision Community includes a generic OAuth handler that can, in principle, be pointed at anything. The reason people give up on it for these three platforms is the email address.
| Platform | What actually happens |
|---|---|
| GitHub | The profile carries only the public address, and most developers keep theirs private — so it arrives empty. The real address needs a second request, a specific permission, and filtering down to the one that is both primary and confirmed. |
| Bitbucket | The profile carries no address at all. Same story: a second request, and permissions that have to be set on the application itself rather than asked for at sign-in. |
| GitLab | Straightforward — provided you ask for the right scope. |
Get this wrong and sign-in still appears to work. Members simply arrive with no email address and are asked to type one, which is exactly the friction you installed a one-click sign-in to remove.
An unverified address is never accepted. Only an address the provider itself confirms as belonging to the account holder is used. Anything less would let somebody register an account elsewhere against one of your members' addresses and land on their community account.
What it does not do
- It does not import repositories, issues or commits, and it does not post anything to your community.
- It does not sync organisations, teams or repository access to member groups.
- It does not replace your existing sign-in methods. It adds to them.
Requirements
- Invision Community 5.
- A free OAuth application on each platform you want to offer — a few minutes each, and the setup guide walks through all three with the exact values to paste.
- No cron job, no theme edit, and no third-party service beyond the platforms themselves.
You may only provide a review once you have downloaded the file.
There are no reviews to display.