Testing and troubleshooting - Google, GitHub, and Facebook
Testing the integration
Open the login screen in a private window and check that every enabled provider's button is visible. Sign in with it on a test account, confirm you return to the panel logged in, and - if the account has two-factor verification on - that the panel asked for the second factor. Also test registration: a new account created through a provider that verifies addresses should get access to the panel right away, with no e-mail verification screen.
Common problems
A provider's button does not appear on the login screen
A provider is visible only when its switch is on and both OAuth keys are set in the platform settings. A missing key and a switched-off provider give exactly the same result - no button, no error message, because from a visitor's point of view the provider simply does not exist. Visiting its address directly ends in 404, not 403.
DockRay asks for a password after trying to log in with Facebook
That is intended behaviour, not a bug. Facebook does not guarantee a confirmed e-mail address, so DockRay never attaches a Facebook login to an existing account by e-mail alone - otherwise creating a profile there with someone else's address would be enough to walk into their account. Whoever owns an existing account under that address has to sign in with a password (or via Google or GitHub, if linked there) and only then deliberately connect the Facebook login from the panel, where that option exists.
Login fails with a missing e-mail address error
This happens when the provider profile has no visible address - for instance, GitHub with the address hidden in privacy settings, or Facebook with no confirmed address on the profile. DockRay never creates an account without an e-mail address, since such an account would have no path to a password reset or to notifications. The fix lives on the provider's side: reveal or add an address in the account settings there.
The provider console reports a redirect URI mismatch
The Redirect URI entered in the provider's console must match exactly what the DockRay panel shows in the platform settings. The most common cause of a mismatch is a typo, a missing HTTPS scheme, or an address entered for a different environment than the one you are actually testing login from.
An account does not log in despite correct authentication at the provider
The provider only proves identity - access is decided by the account status in DockRay. A deactivated user cannot log in by any route, including through a provider that correctly confirmed who they are.
Still not working
Work through the troubleshooting checklist, and if that does not help, write to us. Include the project name, the integration version and roughly when you ran the test: it shortens the way to an answer.