2013-06-20 01:28:48 +02:00
|
|
|
<?php
|
|
|
|
|
2015-01-02 05:27:45 +01:00
|
|
|
final class PhabricatorAuthSetupCheck extends PhabricatorSetupCheck {
|
2013-06-20 01:28:48 +02:00
|
|
|
|
2015-02-10 21:53:00 +01:00
|
|
|
public function getDefaultGroup() {
|
|
|
|
return self::GROUP_IMPORTANT;
|
|
|
|
}
|
|
|
|
|
2013-06-20 01:28:48 +02:00
|
|
|
protected function executeChecks() {
|
Don't actually construct auth providers when checking for their existence
Summary:
A user reported this stack trace:
http://pastebin.com/6auGbZsE
...on this GitHub issue:
https://github.com/facebook/phabricator/issues/389#issuecomment-36612511
The problem is similar to the original report, but not identical. In this case, we're following a sequence of steps like:
- Run setup checks.
- Check for enabled providers, in order to raise "no providers configured yet" warning.
- Try to generate login/redirect URIs.
- Build the request.
- Set the default base URI.
- Run normal code.
Since we try to generate URIs before we provide a default, this fatals. Instead, don't try to build objects.
An alternative fix might be to try to set defaults earlier, but we depend on some config and on building the Request in order to be able to figure out if a request is HTTP or HTTPS right now. We could assume one, or guess, or use protocol-relative URIs (`///host.com`), but I think this fix is a little cleaner overall. If we keep hitting similar stuff, we could look into alternate fixes.
We could also set some kind of "setup mode" flag and make `getURI()` if it's called during setup mode to detect these during testing. I'd like to hit one more of these before doing that, though.
Test Plan: Reproduced the issue, applied the patch, verified this fixes it.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D8395
2014-03-05 01:11:28 +01:00
|
|
|
// NOTE: We're not actually building these providers. Building providers
|
|
|
|
// can require additional configuration to be present (e.g., to build
|
|
|
|
// redirect and login URIs using `phabricator.base-uri`) and it won't
|
|
|
|
// necessarily be available when running setup checks.
|
|
|
|
|
|
|
|
// Since this check is only meant as a hint to new administrators about
|
|
|
|
// steps they should take, we don't need to be thorough about checking
|
|
|
|
// that providers are enabled, available, correctly configured, etc. As
|
|
|
|
// long as they've created some kind of provider in the auth app before,
|
|
|
|
// they know that it exists and don't need the hint to go check it out.
|
|
|
|
|
|
|
|
$configs = id(new PhabricatorAuthProviderConfigQuery())
|
|
|
|
->setViewer(PhabricatorUser::getOmnipotentUser())
|
|
|
|
->execute();
|
|
|
|
|
|
|
|
if (!$configs) {
|
2013-06-20 01:28:48 +02:00
|
|
|
$message = pht(
|
|
|
|
'You have not configured any authentication providers yet. You '.
|
|
|
|
'should add a provider (like username/password, LDAP, or GitHub '.
|
|
|
|
'OAuth) so users can register and log in. You can add and configure '.
|
|
|
|
'providers %s.',
|
|
|
|
phutil_tag(
|
|
|
|
'a',
|
|
|
|
array(
|
|
|
|
'href' => '/auth/',
|
|
|
|
),
|
|
|
|
pht('using the "Auth" application')));
|
|
|
|
|
|
|
|
$this
|
|
|
|
->newIssue('auth.noproviders')
|
|
|
|
->setShortName(pht('No Auth Providers'))
|
|
|
|
->setName(pht('No Authentication Providers Configured'))
|
|
|
|
->setMessage($message);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|