2011-01-31 20:55:26 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
return array(
|
|
|
|
|
|
|
|
// The root URI which Phabricator is installed on.
|
|
|
|
// Example: "http://phabricator.example.com/"
|
|
|
|
'phabricator.base-uri' => null,
|
|
|
|
|
2011-04-04 23:22:16 +02:00
|
|
|
// If you have multiple environments, provide the production environment URI
|
|
|
|
// here so that emails, etc., generated in development/sandbox environments
|
|
|
|
// contain the right links.
|
|
|
|
'phabricator.production-uri' => null,
|
|
|
|
|
2011-05-05 20:00:05 +02:00
|
|
|
// Setting this to 'true' will invoke a special setup mode which helps guide
|
|
|
|
// you through setting up Phabricator.
|
|
|
|
'phabricator.setup' => false,
|
|
|
|
|
Provide a setting which forces all file views to be served from an alternate
domain
Summary:
See D758, D759.
- Provide a strongly recommended setting which permits configuration of an
alternate domain.
- Lock cookies down better: set them on the exact domain, and use SSL-only if
the configuration is HTTPS.
- Prevent Phabriator from setting cookies on other domains.
This assumes D759 will land, it is not effective without that change.
Test Plan:
- Attempted to login from a different domain and was rejected.
- Logged out, logged back in normally.
- Put install in setup mode and verified it revealed a warning.
- Configured an alterate domain.
- Tried to view an image with an old URI, got a 400.
- Went to /files/ and verified links rendered to the alternate domain.
- Viewed an alternate domain file.
- Tried to view an alternate domain file without the secret key, got a 404.
Reviewers: andrewjcg, erling, aran, tuomaspelkonen, jungejason, codeblock
CC: aran
Differential Revision: 760
2011-08-02 07:24:00 +02:00
|
|
|
// -- IMPORTANT! Security! -------------------------------------------------- //
|
|
|
|
|
|
|
|
// IMPORTANT: By default, Phabricator serves files from the same domain the
|
Move ALL files to serve from the alternate file domain, not just files without
"Content-Disposition: attachment"
Summary:
We currently serve some files off the primary domain (with "Content-Disposition:
attachment" + a CSRF check) and some files off the alternate domain (without
either).
This is not sufficient, because some UAs (like the iPad) ignore
"Content-Disposition: attachment". So there's an attack that goes like this:
- Alice uploads xss.html
- Alice says to Bob "hey download this file on your iPad"
- Bob clicks "Download" on Phabricator on his iPad, gets XSS'd.
NOTE: This removes the CSRF check for downloading files. The check is nice to
have but only raises the barrier to entry slightly. Between iPad / sniffing /
flash bytecode attacks, single-domain installs are simply insecure. We could
restore the check at some point in conjunction with a derived authentication
cookie (i.e., a mini-session-token which is only useful for downloading files),
but that's a lot of complexity to drop all at once.
(Because files are now authenticated only by knowing the PHID and secret key,
this also fixes the "no profile pictures in public feed while logged out"
issue.)
Test Plan: Viewed, info'd, and downloaded files
Reviewers: btrahan, arice, alok
Reviewed By: arice
CC: aran, epriestley
Maniphest Tasks: T843
Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
|
|
|
// application lives on. This is convenient but not secure: it creates a large
|
|
|
|
// class of vulnerabilities which can not be generally mitigated.
|
Provide a setting which forces all file views to be served from an alternate
domain
Summary:
See D758, D759.
- Provide a strongly recommended setting which permits configuration of an
alternate domain.
- Lock cookies down better: set them on the exact domain, and use SSL-only if
the configuration is HTTPS.
- Prevent Phabriator from setting cookies on other domains.
This assumes D759 will land, it is not effective without that change.
Test Plan:
- Attempted to login from a different domain and was rejected.
- Logged out, logged back in normally.
- Put install in setup mode and verified it revealed a warning.
- Configured an alterate domain.
- Tried to view an image with an old URI, got a 400.
- Went to /files/ and verified links rendered to the alternate domain.
- Viewed an alternate domain file.
- Tried to view an alternate domain file without the secret key, got a 404.
Reviewers: andrewjcg, erling, aran, tuomaspelkonen, jungejason, codeblock
CC: aran
Differential Revision: 760
2011-08-02 07:24:00 +02:00
|
|
|
//
|
|
|
|
// To avoid this, you should configure a second domain in the same way you
|
|
|
|
// have the primary domain configured (e.g., point it at the same machine and
|
|
|
|
// set up the same vhost rules) and provide it here. For instance, if your
|
|
|
|
// primary install is on "http://www.phabricator-example.com/", you could
|
|
|
|
// configure "http://www.phabricator-files.com/" and specify the entire
|
Move ALL files to serve from the alternate file domain, not just files without
"Content-Disposition: attachment"
Summary:
We currently serve some files off the primary domain (with "Content-Disposition:
attachment" + a CSRF check) and some files off the alternate domain (without
either).
This is not sufficient, because some UAs (like the iPad) ignore
"Content-Disposition: attachment". So there's an attack that goes like this:
- Alice uploads xss.html
- Alice says to Bob "hey download this file on your iPad"
- Bob clicks "Download" on Phabricator on his iPad, gets XSS'd.
NOTE: This removes the CSRF check for downloading files. The check is nice to
have but only raises the barrier to entry slightly. Between iPad / sniffing /
flash bytecode attacks, single-domain installs are simply insecure. We could
restore the check at some point in conjunction with a derived authentication
cookie (i.e., a mini-session-token which is only useful for downloading files),
but that's a lot of complexity to drop all at once.
(Because files are now authenticated only by knowing the PHID and secret key,
this also fixes the "no profile pictures in public feed while logged out"
issue.)
Test Plan: Viewed, info'd, and downloaded files
Reviewers: btrahan, arice, alok
Reviewed By: arice
CC: aran, epriestley
Maniphest Tasks: T843
Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
|
|
|
// domain (with protocol) here. This will enforce that files are
|
|
|
|
// served only from the alternate domain. Ideally, you should use a
|
|
|
|
// completely separate domain name rather than just a different subdomain.
|
Provide a setting which forces all file views to be served from an alternate
domain
Summary:
See D758, D759.
- Provide a strongly recommended setting which permits configuration of an
alternate domain.
- Lock cookies down better: set them on the exact domain, and use SSL-only if
the configuration is HTTPS.
- Prevent Phabriator from setting cookies on other domains.
This assumes D759 will land, it is not effective without that change.
Test Plan:
- Attempted to login from a different domain and was rejected.
- Logged out, logged back in normally.
- Put install in setup mode and verified it revealed a warning.
- Configured an alterate domain.
- Tried to view an image with an old URI, got a 400.
- Went to /files/ and verified links rendered to the alternate domain.
- Viewed an alternate domain file.
- Tried to view an alternate domain file without the secret key, got a 404.
Reviewers: andrewjcg, erling, aran, tuomaspelkonen, jungejason, codeblock
CC: aran
Differential Revision: 760
2011-08-02 07:24:00 +02:00
|
|
|
//
|
Move ALL files to serve from the alternate file domain, not just files without
"Content-Disposition: attachment"
Summary:
We currently serve some files off the primary domain (with "Content-Disposition:
attachment" + a CSRF check) and some files off the alternate domain (without
either).
This is not sufficient, because some UAs (like the iPad) ignore
"Content-Disposition: attachment". So there's an attack that goes like this:
- Alice uploads xss.html
- Alice says to Bob "hey download this file on your iPad"
- Bob clicks "Download" on Phabricator on his iPad, gets XSS'd.
NOTE: This removes the CSRF check for downloading files. The check is nice to
have but only raises the barrier to entry slightly. Between iPad / sniffing /
flash bytecode attacks, single-domain installs are simply insecure. We could
restore the check at some point in conjunction with a derived authentication
cookie (i.e., a mini-session-token which is only useful for downloading files),
but that's a lot of complexity to drop all at once.
(Because files are now authenticated only by knowing the PHID and secret key,
this also fixes the "no profile pictures in public feed while logged out"
issue.)
Test Plan: Viewed, info'd, and downloaded files
Reviewers: btrahan, arice, alok
Reviewed By: arice
CC: aran, epriestley
Maniphest Tasks: T843
Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
|
|
|
// It is STRONGLY RECOMMENDED that you configure this. Your install is NOT
|
|
|
|
// SECURE unless you do so.
|
Provide a setting which forces all file views to be served from an alternate
domain
Summary:
See D758, D759.
- Provide a strongly recommended setting which permits configuration of an
alternate domain.
- Lock cookies down better: set them on the exact domain, and use SSL-only if
the configuration is HTTPS.
- Prevent Phabriator from setting cookies on other domains.
This assumes D759 will land, it is not effective without that change.
Test Plan:
- Attempted to login from a different domain and was rejected.
- Logged out, logged back in normally.
- Put install in setup mode and verified it revealed a warning.
- Configured an alterate domain.
- Tried to view an image with an old URI, got a 400.
- Went to /files/ and verified links rendered to the alternate domain.
- Viewed an alternate domain file.
- Tried to view an alternate domain file without the secret key, got a 404.
Reviewers: andrewjcg, erling, aran, tuomaspelkonen, jungejason, codeblock
CC: aran
Differential Revision: 760
2011-08-02 07:24:00 +02:00
|
|
|
'security.alternate-file-domain' => null,
|
2011-08-08 00:14:23 +02:00
|
|
|
|
2011-12-18 20:00:39 +01:00
|
|
|
// Default key for HMAC digests where the key is not important (i.e., the
|
|
|
|
// hash itself is secret). You can change this if you want (to any other
|
|
|
|
// string), but doing so will break existing sessions and CSRF tokens.
|
|
|
|
'security.hmac-key' => '[D\t~Y7eNmnQGJ;rnH6aF;m2!vJ8@v8C=Cs:aQS\.Qw',
|
|
|
|
|
2012-09-04 18:56:30 +02:00
|
|
|
// If the web server responds to both HTTP and HTTPS requests but you want
|
|
|
|
// users to connect with only HTTPS, you can set this to true to make
|
|
|
|
// Phabricator redirect HTTP requests to HTTPS.
|
|
|
|
//
|
|
|
|
// Normally, you should just configure your server not to accept HTTP traffic,
|
|
|
|
// but this setting may be useful if you originally used HTTP and have now
|
|
|
|
// switched to HTTPS but don't want to break old links, or if your webserver
|
|
|
|
// sits behind a load balancer which terminates HTTPS connections and you
|
|
|
|
// can not reasonably configure more granular behavior there.
|
|
|
|
//
|
|
|
|
// NOTE: Phabricator determines if a request is HTTPS or not by examining the
|
|
|
|
// PHP $_SERVER['HTTPS'] variable. If you run Apache/mod_php this will
|
|
|
|
// probably be set correctly for you automatically, but if you run Phabricator
|
|
|
|
// as CGI/FCGI (e.g., through nginx or lighttpd), you need to configure your
|
|
|
|
// web server so that it passes the value correctly based on the connection
|
|
|
|
// type. Alternatively, you can add a PHP snippet to the top of this
|
|
|
|
// configuration file to directly set $_SERVER['HTTPS'] to the correct value.
|
|
|
|
'security.require-https' => false,
|
|
|
|
|
2011-12-18 20:00:39 +01:00
|
|
|
|
2012-06-14 22:43:09 +02:00
|
|
|
// -- Internationalization -------------------------------------------------- //
|
|
|
|
|
|
|
|
// This allows customizing texts used in Phabricator. The class must extend
|
|
|
|
// PhabricatorTranslation.
|
|
|
|
'translation.provider' => 'PhabricatorEnglishTranslation',
|
|
|
|
|
2012-06-21 19:20:52 +02:00
|
|
|
// You can use 'translation.override' if you don't want to create a full
|
|
|
|
// translation to give users an option for switching to it and you just want
|
|
|
|
// to override some strings in the default translation.
|
|
|
|
'translation.override' => array(),
|
|
|
|
|
2012-06-14 22:43:09 +02:00
|
|
|
|
2012-04-17 16:52:10 +02:00
|
|
|
// -- Access Policies ------------------------------------------------------- //
|
|
|
|
|
|
|
|
// Phabricator allows you to set the visibility of objects (like repositories
|
|
|
|
// and source code) to "Public", which means anyone on the internet can see
|
|
|
|
// them, even without being logged in. This is great for open source, but
|
|
|
|
// some installs may never want to make anything public, so this policy is
|
|
|
|
// disabled by default. You can enable it here, which will let you set the
|
|
|
|
// policy for objects to "Public". With this option disabled, the most open
|
|
|
|
// policy is "All Users", which means users must be logged in to view things.
|
|
|
|
'policy.allow-public' => false,
|
|
|
|
|
|
|
|
|
Allow Phabricator to write an access log using PhutilDeferredLog
Summary: Provide a configurable access log.
Test Plan:
Got a sensible-looking log including logged-in, logged-out, conduit, 404, etc:
[Mon, 23 Apr 2012 20:08:12 -0700] 32599 orbital - epriestley DifferentialCommentPreviewController - /differential/comment/preview/42/ http://local.aphront.com:8080/D42 200 65406
[Mon, 23 Apr 2012 20:08:12 -0700] 32881 orbital - epriestley DifferentialChangesetViewController - /differential/changeset/ http://local.aphront.com:8080/D42 200 72669
[Mon, 23 Apr 2012 20:08:39 -0700] 32882 orbital 127.0.0.1 epriestley DifferentialRevisionListController - /differential/ http://local.aphront.com:8080/D42 200 106444
[Mon, 23 Apr 2012 20:08:54 -0700] 32867 orbital 127.0.0.1 epriestley DifferentialRevisionListController - /differential/ http://local.aphront.com:8080/differential/ 200 112229
[Mon, 23 Apr 2012 20:09:05 -0700] 32530 orbital 127.0.0.1 epriestley PhabricatorDirectoryMainController - / http://local.aphront.com:8080/differential/ 200 141350
[Mon, 23 Apr 2012 20:09:10 -0700] 32598 orbital 127.0.0.1 epriestley PhabricatorDirectoryCategoryViewController - /directory/6/ http://local.aphront.com:8080/ 200 43474
[Mon, 23 Apr 2012 20:09:12 -0700] 32880 orbital 127.0.0.1 epriestley PhabricatorConduitConsoleController - /conduit/ http://local.aphront.com:8080/directory/6/ 200 139340
[Mon, 23 Apr 2012 20:09:15 -0700] 32868 orbital 127.0.0.1 epriestley PhabricatorConduitAPIController arcanist.projectinfo /api/arcanist.projectinfo http://local.aphront.com:8080/conduit/ 200 128774
[Mon, 23 Apr 2012 20:10:04 -0700] 32599 orbital 127.0.0.1 epriestley Phabricator404Controller - /asdbmabdmbsm - 404 38782
[Mon, 23 Apr 2012 20:10:04 -0700] 32881 orbital 127.0.0.1 - CelerityResourceController - /res/c9a43002/rsrc/css/aphront/request-failure-view.css http://local.aphront.com:8080/asdbmabdmbsm 200 25160
[Mon, 23 Apr 2012 20:10:57 -0700] 32882 orbital 127.0.0.1 epriestley PhabricatorLogoutController - /logout/ http://local.aphront.com:8080/asdbmabdmbsm 200 40810
[Mon, 23 Apr 2012 20:10:57 -0700] 32867 orbital 127.0.0.1 - PhabricatorLoginController - /login/ http://local.aphront.com:8080/asdbmabdmbsm 200 42526
[Mon, 23 Apr 2012 20:10:59 -0700] 32919 orbital 127.0.0.1 - PhabricatorLoginController - /login/ http://local.aphront.com:8080/asdbmabdmbsm 200 49052
[Mon, 23 Apr 2012 20:10:59 -0700] 32880 orbital 127.0.0.1 - CelerityResourceController - /res/c80156c4/rsrc/js/application/core/behavior-dark-console.js http://local.aphront.com:8080/login/ 200 33166
[Mon, 23 Apr 2012 20:10:59 -0700] 32868 orbital 127.0.0.1 - CelerityResourceController - /res/4965d970/rsrc/css/aphront/dark-console.css http://local.aphront.com:8080/login/ 200 38078
[Mon, 23 Apr 2012 20:10:59 -0700] 32599 orbital 127.0.0.1 - CelerityResourceController - /res/pkg/8a5de8a3/javelin.pkg.js http://local.aphront.com:8080/login/ 200 40534
[Mon, 23 Apr 2012 20:10:59 -0700] 32882 orbital 127.0.0.1 - CelerityResourceController - /res/pkg/9c4e265b/core.pkg.css http://local.aphront.com:8080/login/ 200 41262
[Mon, 23 Apr 2012 20:10:59 -0700] 32881 orbital 127.0.0.1 - CelerityResourceController - /res/pkg/0c96375e/core.pkg.js http://local.aphront.com:8080/login/ 200 43720
[Mon, 23 Apr 2012 20:10:59 -0700] 32921 orbital 127.0.0.1 - CelerityResourceController - /res/caa86a45/rsrc/js/javelin/core/init.js http://local.aphront.com:8080/login/ 200 47566
[Mon, 23 Apr 2012 20:10:59 -0700] 32867 orbital 127.0.0.1 - CelerityResourceController - /res/f46289e9/rsrc/js/application/core/behavior-error-log.js http://local.aphront.com:8080/login/ 200 29328
[Mon, 23 Apr 2012 20:10:59 -0700] 32919 orbital 127.0.0.1 - CelerityResourceController - /res/7e62ff40/rsrc/image/phabricator_logo.png http://local.aphront.com:8080/login/ 200 25583
[Mon, 23 Apr 2012 20:10:59 -0700] 32880 orbital 127.0.0.1 - CelerityResourceController - /res/8c6200d3/rsrc/image/sprite.png http://local.aphront.com:8080/login/ 200 29829
[Mon, 23 Apr 2012 20:11:01 -0700] 32868 orbital 127.0.0.1 - PhabricatorOAuthLoginController - /oauth/facebook/login/ http://local.aphront.com:8080/login/ 200 855931
[Mon, 23 Apr 2012 20:11:02 -0700] 32882 orbital 127.0.0.1 epriestley789 PhabricatorLoginValidateController - /login/validate/ http://local.aphront.com:8080/login/ 200 29793
[Mon, 23 Apr 2012 20:11:02 -0700] 32881 orbital 127.0.0.1 epriestley789 PhabricatorDirectoryMainController - / http://local.aphront.com:8080/login/ 200 91638
Reviewers: jungejason, btrahan, vrana
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D2310
2012-04-25 16:24:08 +02:00
|
|
|
// -- Logging --------------------------------------------------------------- //
|
|
|
|
|
|
|
|
// To enable the Phabricator access log, specify a path here. The Phabricator
|
|
|
|
// access log can provide more detailed information about Phabricator access
|
|
|
|
// than normal HTTP access logs (for instance, it can show logged-in users,
|
|
|
|
// controllers, and other application data). If not set, no log will be
|
|
|
|
// written.
|
|
|
|
//
|
|
|
|
// Make sure the PHP process can write to the log!
|
|
|
|
'log.access.path' => null,
|
|
|
|
|
|
|
|
// Format for the access log. If not set, the default format will be used:
|
|
|
|
//
|
|
|
|
// "[%D]\t%h\t%u\t%M\t%C\t%m\t%U\t%c\t%T"
|
|
|
|
//
|
|
|
|
// Available variables are:
|
|
|
|
//
|
|
|
|
// - %c The HTTP response code.
|
|
|
|
// - %C The controller which handled the request.
|
|
|
|
// - %D The request date.
|
|
|
|
// - %e Epoch timestamp.
|
|
|
|
// - %h The webserver's host name.
|
|
|
|
// - %p The PID of the server process.
|
|
|
|
// - %R The HTTP referrer.
|
|
|
|
// - %r The remote IP.
|
|
|
|
// - %T The request duration, in microseconds.
|
|
|
|
// - %U The request path.
|
|
|
|
// - %u The logged-in user, if one is logged in.
|
|
|
|
// - %M The HTTP method.
|
|
|
|
// - %m For conduit, the Conduit method which was invoked.
|
|
|
|
//
|
|
|
|
// If a variable isn't available (for example, %m appears in the file format
|
|
|
|
// but the request is not a Conduit request), it will be rendered as "-".
|
|
|
|
//
|
|
|
|
// Note that the default format is subject to change in the future, so if you
|
|
|
|
// rely on the log's format, specify it explicitly.
|
|
|
|
'log.access.format' => null,
|
|
|
|
|
|
|
|
|
2011-02-05 20:45:13 +01:00
|
|
|
// -- DarkConsole ----------------------------------------------------------- //
|
|
|
|
|
|
|
|
// DarkConsole is a administrative debugging/profiling tool built into
|
|
|
|
// Phabricator. You can leave it disabled unless you're developing against
|
|
|
|
// Phabricator.
|
2011-02-05 21:20:18 +01:00
|
|
|
|
2011-02-05 20:45:13 +01:00
|
|
|
// Determines whether or not DarkConsole is available. DarkConsole exposes
|
|
|
|
// some data like queries and stack traces, so you should be careful about
|
|
|
|
// turning it on in production (although users can not normally see it, even
|
|
|
|
// if the deployment configuration enables it).
|
2011-05-05 20:00:05 +02:00
|
|
|
'darkconsole.enabled' => false,
|
2011-02-05 21:20:18 +01:00
|
|
|
|
2011-02-05 20:45:13 +01:00
|
|
|
// Always enable DarkConsole, even for logged out users. This potentially
|
|
|
|
// exposes sensitive information to users, so make sure untrusted users can
|
|
|
|
// not access an install running in this mode. You should definitely leave
|
|
|
|
// this off in production. It is only really useful for using DarkConsole
|
2012-01-20 16:39:55 +01:00
|
|
|
// utilities to debug or profile logged-out pages. You must set
|
2011-02-05 20:45:13 +01:00
|
|
|
// 'darkconsole.enabled' to use this option.
|
|
|
|
'darkconsole.always-on' => false,
|
|
|
|
|
2011-02-01 01:50:08 +01:00
|
|
|
|
2011-02-12 01:48:43 +01:00
|
|
|
// Allows you to mask certain configuration values from appearing in the
|
|
|
|
// "Config" tab of DarkConsole.
|
|
|
|
'darkconsole.config-mask' => array(
|
|
|
|
'mysql.pass',
|
|
|
|
'amazon-ses.secret-key',
|
2012-07-18 16:01:13 +02:00
|
|
|
'amazon-s3.secret-key',
|
|
|
|
'sendgrid.api-key',
|
2011-02-12 01:48:43 +01:00
|
|
|
'recaptcha.private-key',
|
|
|
|
'phabricator.csrf-key',
|
|
|
|
'facebook.application-secret',
|
2011-04-30 07:20:52 +02:00
|
|
|
'github.application-secret',
|
2012-05-08 21:08:05 +02:00
|
|
|
'google.application-secret',
|
|
|
|
'phabricator.application-secret',
|
|
|
|
'disqus.application-secret',
|
2012-03-10 00:45:30 +01:00
|
|
|
'phabricator.mail-key',
|
|
|
|
'security.hmac-key',
|
2012-11-30 13:21:44 +01:00
|
|
|
'ldap.anonymous-user-password',
|
2011-02-12 01:48:43 +01:00
|
|
|
),
|
|
|
|
|
2011-08-08 00:14:23 +02:00
|
|
|
|
2011-02-01 01:50:08 +01:00
|
|
|
// -- MySQL --------------------------------------------------------------- //
|
|
|
|
|
2012-04-06 23:42:02 +02:00
|
|
|
// Class providing database configuration. It must implement
|
|
|
|
// DatabaseConfigurationProvider.
|
|
|
|
'mysql.configuration-provider' => 'DefaultDatabaseConfigurationProvider',
|
|
|
|
|
2011-02-01 01:50:08 +01:00
|
|
|
// The username to use when connecting to MySQL.
|
|
|
|
'mysql.user' => 'root',
|
2011-02-02 00:52:04 +01:00
|
|
|
|
2011-02-01 01:50:08 +01:00
|
|
|
// The password to use when connecting to MySQL.
|
|
|
|
'mysql.pass' => '',
|
2011-02-02 00:52:04 +01:00
|
|
|
|
2011-06-08 19:10:11 +02:00
|
|
|
// The MySQL server to connect to. If you want to connect to a different
|
|
|
|
// port than the default (which is 3306), specify it in the hostname
|
|
|
|
// (e.g., db.example.com:1234).
|
2011-02-01 01:50:08 +01:00
|
|
|
'mysql.host' => 'localhost',
|
2011-02-12 01:12:24 +01:00
|
|
|
|
2012-01-20 00:04:38 +01:00
|
|
|
// The number of times to try reconnecting to the MySQL database
|
|
|
|
'mysql.connection-retries' => 3,
|
|
|
|
|
2012-04-07 06:29:19 +02:00
|
|
|
// Phabricator supports PHP extensions MySQL and MySQLi. It is possible to
|
|
|
|
// implement also other access mechanism (e.g. PDO_MySQL). The class must
|
|
|
|
// extend AphrontMySQLDatabaseConnectionBase.
|
|
|
|
'mysql.implementation' => 'AphrontMySQLDatabaseConnection',
|
|
|
|
|
2012-06-17 20:35:18 +02:00
|
|
|
|
|
|
|
// -- Notifications --------------------------------------------------------- //
|
|
|
|
|
2012-12-08 01:27:01 +01:00
|
|
|
// Set this to true to enable real-time notifications. You must also run a
|
|
|
|
// notification server for this to work. Consult the documentation in
|
|
|
|
// "Notifications User Guide: Setup and Configuration" for instructions.
|
|
|
|
'notification.enabled' => false,
|
2011-08-08 00:14:23 +02:00
|
|
|
|
2012-06-17 20:35:18 +02:00
|
|
|
// Client port for the realtime server to listen on, and for realtime clients
|
|
|
|
// to connect to. Use "localhost" if you are running the notification server
|
|
|
|
// on the same host as the web server.
|
|
|
|
'notification.client-uri' => 'http://localhost:22280/',
|
|
|
|
|
|
|
|
// URI and port for the notification root server.
|
|
|
|
'notification.server-uri' => 'http://localhost:22281/',
|
|
|
|
|
2012-06-19 00:11:19 +02:00
|
|
|
// The server must be started as root so it can bind to privileged ports, but
|
|
|
|
// if you specify a user here it will drop permissions after binding.
|
|
|
|
'notification.user' => null,
|
|
|
|
|
|
|
|
// Location where the server should log to.
|
|
|
|
'notification.log' => '/var/log/aphlict.log',
|
|
|
|
|
|
|
|
// PID file to use.
|
|
|
|
'notification.pidfile' => '/var/run/aphlict.pid',
|
|
|
|
|
2012-06-20 22:20:47 +02:00
|
|
|
// Enable this option to get additional debug output in the browser.
|
|
|
|
'notification.debug' => false,
|
|
|
|
|
2012-06-17 20:35:18 +02:00
|
|
|
|
2011-02-09 20:11:24 +01:00
|
|
|
// -- Email ----------------------------------------------------------------- //
|
|
|
|
|
|
|
|
// Some Phabricator tools send email notifications, e.g. when Differential
|
|
|
|
// revisions are updated or Maniphest tasks are changed. These options allow
|
|
|
|
// you to configure how email is delivered.
|
2011-02-12 01:12:24 +01:00
|
|
|
|
2011-02-09 20:11:24 +01:00
|
|
|
// You can test your mail setup by going to "MetaMTA" in the web interface,
|
2011-02-12 01:12:24 +01:00
|
|
|
// clicking "Send New Message", and then composing a message.
|
2011-02-09 20:11:24 +01:00
|
|
|
|
|
|
|
// Default address to send mail "From".
|
|
|
|
'metamta.default-address' => 'noreply@example.com',
|
2011-02-12 01:12:24 +01:00
|
|
|
|
2011-04-10 17:46:17 +02:00
|
|
|
// Domain used to generate Message-IDs.
|
|
|
|
'metamta.domain' => 'example.com',
|
|
|
|
|
Fix various threading issues, particularly in Gmail
Summary:
- Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance.
- Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works).
- Add a preference to enable subject line variance.
- Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results.
NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better.
Test Plan:
Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK?
NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults.
I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/
Reviewers: btrahan, vrana, jungejason, nh
Reviewed By: btrahan
CC: cpiro, 20after4, aran
Maniphest Tasks: T1097, T847
Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
|
|
|
// When a message is sent to multiple recipients (for example, several
|
|
|
|
// reviewers on a code review), Phabricator can either deliver one email to
|
|
|
|
// everyone (e.g., "To: alincoln, usgrant, htaft") or separate emails to each
|
|
|
|
// user (e.g., "To: alincoln", "To: usgrant", "To: htaft"). The major
|
|
|
|
// advantages and disadvantages of each approach are:
|
|
|
|
//
|
|
|
|
// - One mail to everyone:
|
|
|
|
// - Recipients can see To/Cc at a glance.
|
|
|
|
// - If you use mailing lists, you won't get duplicate mail if you're
|
|
|
|
// a normal recipient and also Cc'd on a mailing list.
|
|
|
|
// - Getting threading to work properly is harder, and probably requires
|
|
|
|
// making mail less useful by turning off options.
|
|
|
|
// - Sometimes people will "Reply All" and everyone will get two mails,
|
|
|
|
// one from the user and one from Phabricator turning their mail into
|
|
|
|
// a comment.
|
|
|
|
// - Not supported with a private reply-to address.
|
2012-06-20 20:20:11 +02:00
|
|
|
// - Mails are sent in the server default translation.
|
Fix various threading issues, particularly in Gmail
Summary:
- Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance.
- Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works).
- Add a preference to enable subject line variance.
- Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results.
NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better.
Test Plan:
Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK?
NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults.
I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/
Reviewers: btrahan, vrana, jungejason, nh
Reviewed By: btrahan
CC: cpiro, 20after4, aran
Maniphest Tasks: T1097, T847
Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
|
|
|
// - One mail to each user:
|
|
|
|
// - Recipients need to look in the mail body to see To/Cc.
|
|
|
|
// - If you use mailing lists, recipients may sometimes get duplicate
|
|
|
|
// mail.
|
|
|
|
// - Getting threading to work properly is easier, and threading settings
|
|
|
|
// can be customzied by each user.
|
|
|
|
// - "Reply All" no longer spams all other users.
|
|
|
|
// - Required if private reply-to addresses are configured.
|
2012-06-20 20:20:11 +02:00
|
|
|
// - Mails are sent in the language of user preference.
|
Fix various threading issues, particularly in Gmail
Summary:
- Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance.
- Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works).
- Add a preference to enable subject line variance.
- Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results.
NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better.
Test Plan:
Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK?
NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults.
I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/
Reviewers: btrahan, vrana, jungejason, nh
Reviewed By: btrahan
CC: cpiro, 20after4, aran
Maniphest Tasks: T1097, T847
Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
|
|
|
//
|
|
|
|
// In the code, splitting one outbound email into one-per-recipient is
|
|
|
|
// sometimes referred to as "multiplexing".
|
|
|
|
'metamta.one-mail-per-recipient' => true,
|
|
|
|
|
2012-07-18 01:50:52 +02:00
|
|
|
// When sending a message that has no To recipient (i.e. all recipients
|
|
|
|
// are CC'd, for example when multiplexing mail), set the To field to the
|
|
|
|
// following value. If no value is set, messages with no To will have
|
|
|
|
// their CCs upgraded to To.
|
|
|
|
'metamta.placeholder-to-recipient' => null,
|
|
|
|
|
2011-02-09 20:11:24 +01:00
|
|
|
// When a user takes an action which generates an email notification (like
|
|
|
|
// commenting on a Differential revision), Phabricator can either send that
|
|
|
|
// mail "From" the user's email address (like "alincoln@logcabin.com") or
|
|
|
|
// "From" the 'metamta.default-address' address. The user experience is
|
|
|
|
// generally better if Phabricator uses the user's real address as the "From"
|
|
|
|
// since the messages are easier to organize when they appear in mail clients,
|
|
|
|
// but this will only work if the server is authorized to send email on behalf
|
|
|
|
// of the "From" domain. Practically, this means:
|
|
|
|
// - If you are doing an install for Example Corp and all the users will
|
|
|
|
// have corporate @corp.example.com addresses and any hosts Phabricator
|
|
|
|
// is running on are authorized to send email from corp.example.com,
|
|
|
|
// you can enable this to make the user experience a little better.
|
|
|
|
// - If you are doing an install for an open source project and your
|
|
|
|
// users will be registering via Facebook and using personal email
|
|
|
|
// addresses, you MUST NOT enable this or virtually all of your outgoing
|
|
|
|
// email will vanish into SFP blackholes.
|
|
|
|
// - If your install is anything else, you're much safer leaving this
|
|
|
|
// off since the risk in turning it on is that your outgoing mail will
|
|
|
|
// mostly never arrive.
|
|
|
|
'metamta.can-send-as-user' => false,
|
|
|
|
|
Fix various threading issues, particularly in Gmail
Summary:
- Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance.
- Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works).
- Add a preference to enable subject line variance.
- Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results.
NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better.
Test Plan:
Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK?
NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults.
I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/
Reviewers: btrahan, vrana, jungejason, nh
Reviewed By: btrahan
CC: cpiro, 20after4, aran
Maniphest Tasks: T1097, T847
Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
|
|
|
|
2011-02-09 20:11:24 +01:00
|
|
|
// Adapter class to use to transmit mail to the MTA. The default uses
|
2011-05-12 17:15:02 +02:00
|
|
|
// PHPMailerLite, which will invoke "sendmail". This is appropriate
|
|
|
|
// if sendmail actually works on your host, but if you haven't configured mail
|
2011-02-09 20:11:24 +01:00
|
|
|
// it may not be so great. You can also use Amazon SES, by changing this to
|
|
|
|
// 'PhabricatorMailImplementationAmazonSESAdapter', signing up for SES, and
|
|
|
|
// filling in your 'amazon-ses.access-key' and 'amazon-ses.secret-key' below.
|
|
|
|
'metamta.mail-adapter' =>
|
|
|
|
'PhabricatorMailImplementationPHPMailerLiteAdapter',
|
|
|
|
|
2012-07-23 21:04:53 +02:00
|
|
|
// When email is sent, try to hand it off to the MTA immediately instead of
|
|
|
|
// queueing it for delivery by the daemons. If you are running the Phabricator
|
|
|
|
// daemons with "phd start", you should disable this to provide a (sometimes
|
|
|
|
// substantial) performance boost. It's on by default to make setup and
|
|
|
|
// configuration a little easier.
|
2011-02-09 20:11:24 +01:00
|
|
|
'metamta.send-immediately' => true,
|
|
|
|
|
2012-10-05 20:27:58 +02:00
|
|
|
// When email is sent, what format should Phabricator use for user's
|
|
|
|
// email addresses? Valid values are:
|
|
|
|
// - 'short' - 'gwashington <gwashington@example.com>'
|
|
|
|
// - 'real' - 'George Washington <gwashington@example.com>'
|
|
|
|
// - 'full' - 'gwashington (George Washington) <gwashington@example.com>'
|
|
|
|
// The default is 'full'.
|
|
|
|
'metamta.user-address-format' => 'full',
|
|
|
|
|
2011-02-09 20:11:24 +01:00
|
|
|
// If you're using Amazon SES to send email, provide your AWS access key
|
|
|
|
// and AWS secret key here. To set up Amazon SES with Phabricator, you need
|
|
|
|
// to:
|
|
|
|
// - Make sure 'metamta.mail-adapter' is set to:
|
|
|
|
// "PhabricatorMailImplementationAmazonSESAdapter"
|
|
|
|
// - Make sure 'metamta.can-send-as-user' is false.
|
|
|
|
// - Make sure 'metamta.default-address' is configured to something sensible.
|
|
|
|
// - Make sure 'metamta.default-address' is a validated SES "From" address.
|
|
|
|
'amazon-ses.access-key' => null,
|
|
|
|
'amazon-ses.secret-key' => null,
|
2011-02-01 01:50:08 +01:00
|
|
|
|
2011-05-26 19:00:26 +02:00
|
|
|
// If you're using Sendgrid to send email, provide your access credentials
|
|
|
|
// here. This will use the REST API. You can also use Sendgrid as a normal
|
|
|
|
// SMTP service.
|
|
|
|
'sendgrid.api-user' => null,
|
|
|
|
'sendgrid.api-key' => null,
|
|
|
|
|
2011-05-10 01:31:26 +02:00
|
|
|
// You can configure a reply handler domain so that email sent from Maniphest
|
|
|
|
// will have a special "Reply To" address like "T123+82+af19f@example.com"
|
|
|
|
// that allows recipients to reply by email and interact with tasks. For
|
|
|
|
// instructions on configurating reply handlers, see the article
|
|
|
|
// "Configuring Inbound Email" in the Phabricator documentation. By default,
|
|
|
|
// this is set to 'null' and Phabricator will use a generic 'noreply@' address
|
|
|
|
// or the address of the acting user instead of a special reply handler
|
|
|
|
// address (see 'metamta.default-address'). If you set a domain here,
|
|
|
|
// Phabricator will begin generating private reply handler addresses. See
|
|
|
|
// also 'metamta.maniphest.reply-handler' to further configure behavior.
|
|
|
|
// This key should be set to the domain part after the @, like "example.com".
|
|
|
|
'metamta.maniphest.reply-handler-domain' => null,
|
|
|
|
|
|
|
|
// You can follow the instructions in "Configuring Inbound Email" in the
|
|
|
|
// Phabricator documentation and set 'metamta.maniphest.reply-handler-domain'
|
|
|
|
// to support updating Maniphest tasks by email. If you want more advanced
|
|
|
|
// customization than this provides, you can override the reply handler
|
|
|
|
// class with an implementation of your own. This will allow you to do things
|
|
|
|
// like have a single public reply handler or change how private reply
|
|
|
|
// handlers are generated and validated.
|
2012-11-22 02:39:46 +01:00
|
|
|
//
|
2011-05-10 01:31:26 +02:00
|
|
|
// This key should be set to a loadable subclass of
|
2012-11-22 02:39:46 +01:00
|
|
|
// PhabricatorMailReplyHandler.
|
2011-05-10 01:31:26 +02:00
|
|
|
'metamta.maniphest.reply-handler' => 'ManiphestReplyHandler',
|
|
|
|
|
2011-08-16 11:31:51 +02:00
|
|
|
// If you don't want phabricator to take up an entire domain
|
|
|
|
// (or subdomain for that matter), you can use this and set a common
|
|
|
|
// prefix for mail sent by phabricator. It will make use of the fact that
|
|
|
|
// a mail-address such as phabricator+D123+1hjk213h@example.com will be
|
|
|
|
// delivered to the phabricator users mailbox.
|
|
|
|
// Set this to the left part of the email address and it well get
|
|
|
|
// prepended to all outgoing mail. If you want to use e.g.
|
|
|
|
// 'phabricator@example.com' this should be set to 'phabricator'.
|
|
|
|
'metamta.single-reply-handler-prefix' => null,
|
|
|
|
|
2011-05-17 00:54:41 +02:00
|
|
|
// Prefix prepended to mail sent by Maniphest. You can change this to
|
|
|
|
// distinguish between testing and development installs, for example.
|
|
|
|
'metamta.maniphest.subject-prefix' => '[Maniphest]',
|
|
|
|
|
2012-11-22 02:39:46 +01:00
|
|
|
// See 'metamta.pholio.reply-handler-domain'. This does the same thing, but
|
|
|
|
// affects Pholio.
|
|
|
|
'metamta.pholio.reply-handler-domain' => null,
|
|
|
|
|
|
|
|
// Prefix prepended to mail sent by Pholio.
|
|
|
|
'metamta.pholio.subject-prefix' => '[Pholio]',
|
|
|
|
|
2011-05-10 01:31:26 +02:00
|
|
|
// See 'metamta.maniphest.reply-handler-domain'. This does the same thing,
|
|
|
|
// but allows email replies via Differential.
|
|
|
|
'metamta.differential.reply-handler-domain' => null,
|
|
|
|
|
|
|
|
// See 'metamta.maniphest.reply-handler'. This does the same thing, but
|
|
|
|
// affects Differential.
|
|
|
|
'metamta.differential.reply-handler' => 'DifferentialReplyHandler',
|
|
|
|
|
2011-05-17 00:54:41 +02:00
|
|
|
// Prefix prepended to mail sent by Differential.
|
|
|
|
'metamta.differential.subject-prefix' => '[Differential]',
|
|
|
|
|
2011-10-14 21:08:31 +02:00
|
|
|
// Set this to true if you want patches to be attached to mail from
|
2012-03-03 20:05:19 +01:00
|
|
|
// Differential. This won't work if you are using SendGrid as your mail
|
2011-10-14 21:08:31 +02:00
|
|
|
// adapter.
|
|
|
|
'metamta.differential.attach-patches' => false,
|
|
|
|
|
2012-03-03 20:05:19 +01:00
|
|
|
// To include patches in email bodies, set this to a positive integer. Patches
|
|
|
|
// will be inlined if they are at most that many lines. For instance, a value
|
|
|
|
// of 100 means "inline patches if they are no longer than 100 lines". By
|
|
|
|
// default, patches are not inlined.
|
|
|
|
'metamta.differential.inline-patches' => 0,
|
|
|
|
|
|
|
|
// If you enable either of the options above, you can choose what format
|
|
|
|
// patches are sent in. Valid options are 'unified' (like diff -u) or 'git'.
|
|
|
|
'metamta.differential.patch-format' => 'unified',
|
|
|
|
|
2012-08-02 15:00:18 +02:00
|
|
|
// Enables a different format for comments in differential emails.
|
|
|
|
// Differential will create unified diffs around the comment, which
|
|
|
|
// will give enough context for people who are only viewing the
|
|
|
|
// reviews in email to understand what is going on. The context will
|
|
|
|
// be created based on the range of the comment.
|
2012-08-15 01:26:36 +02:00
|
|
|
'metamta.differential.unified-comment-context' => false,
|
2012-08-02 15:00:18 +02:00
|
|
|
|
2012-02-27 21:57:57 +01:00
|
|
|
// Prefix prepended to mail sent by Diffusion.
|
|
|
|
'metamta.diffusion.subject-prefix' => '[Diffusion]',
|
|
|
|
|
|
|
|
// See 'metamta.maniphest.reply-handler-domain'. This does the same thing,
|
|
|
|
// but allows email replies via Diffusion.
|
|
|
|
'metamta.diffusion.reply-handler-domain' => null,
|
|
|
|
|
|
|
|
// See 'metamta.maniphest.reply-handler'. This does the same thing, but
|
|
|
|
// affects Diffusion.
|
|
|
|
'metamta.diffusion.reply-handler' => 'PhabricatorAuditReplyHandler',
|
|
|
|
|
2012-07-12 22:33:35 +02:00
|
|
|
// Set this to true if you want patches to be attached to commit notifications
|
|
|
|
// from Diffusion. This won't work with SendGrid.
|
|
|
|
'metamta.diffusion.attach-patches' => false,
|
|
|
|
|
|
|
|
// To include patches in Diffusion email bodies, set this to a positive
|
|
|
|
// integer. Patches will be inlined if they are at most that many lines.
|
|
|
|
// By default, patches are not inlined.
|
|
|
|
'metamta.diffusion.inline-patches' => 0,
|
|
|
|
|
|
|
|
// If you've enabled attached patches or inline patches for commit emails, you
|
|
|
|
// can establish a hard byte limit on their size. You should generally set
|
|
|
|
// reasonable byte and time limits (defaults are 1MB and 60 seconds) to avoid
|
|
|
|
// sending ridiculously enormous email for changes like "importing an external
|
|
|
|
// library" or "accidentally committed this full-length movie as text".
|
|
|
|
'metamta.diffusion.byte-limit' => 1024 * 1024,
|
|
|
|
|
|
|
|
// If you've enabled attached patches or inline patches for commit emails, you
|
|
|
|
// can establish a hard time limit on generating them.
|
|
|
|
'metamta.diffusion.time-limit' => 60,
|
|
|
|
|
Detect package change and send out email
Summary:
For package creation and deletion, send email to all the owners For
package modification, detect important fields such as owners and paths, and then
send out emails to all owners (including deleted owners and current owners)
Also start using transaction for package creation/deletion/modification.
Test Plan:
- tested mail creation and deletion
- tested modification to auditing enabled, primary owners, owners, paths
Reviewers: epriestley, nh, vrana
Reviewed By: epriestley
CC: prithvi, aran, Koolvin
Differential Revision: https://secure.phabricator.com/D2470
2012-05-07 09:19:44 +02:00
|
|
|
// Prefix prepended to mail sent by Package.
|
|
|
|
'metamta.package.subject-prefix' => '[Package]',
|
|
|
|
|
|
|
|
// See 'metamta.maniphest.reply-handler'. This does similar thing for package
|
|
|
|
// except that it only supports sending out mail and doesn't handle incoming
|
|
|
|
// email.
|
|
|
|
'metamta.package.reply-handler' => 'OwnersPackageReplyHandler',
|
|
|
|
|
Allow Phabricator to be configured to use a public Reply-To address
Summary:
We already support this (and Facebook uses it) but it is difficult to configure
and you have to write a bunch of code. Instead, provide a simple flag.
See the documentation changes for details, but when this flag is enabled we send
one email with a reply-to like "D2+public+23hf91fh19fh@phabricator.example.com".
Anyone can reply to this, and we figure out who they are based on their "From"
address instead of a unique hash. This is less secure, but a reasonable tradeoff
in many cases.
This also has the advantage over a naive implementation of at least doing object
hash validation.
@jungejason: I don't think this affects Facebook's implementation but this is an
area where we've had problems in the past, so watch out for it when you deploy.
Also note that you must set "metamta.public-replies" to true since Maniphest now
looks for that key specifically before going into public reply mode; it no
longer just tests for a public reply address being generateable (since it can
always generate one now).
Test Plan:
Swapped my local install in and out of public reply mode and commented on
objects. Got expected email behavior. Replied to public and private email
addresses.
Attacked public addresses by using them when the install was configured to
disallow them and by altering the hash and the from address. All this stuff was
rejected.
Reviewed By: jungejason
Reviewers: moskov, jungejason, tuomaspelkonen, aran
CC: aran, epriestley, moskov, jungejason
Differential Revision: 563
2011-06-30 22:01:35 +02:00
|
|
|
// By default, Phabricator generates unique reply-to addresses and sends a
|
|
|
|
// separate email to each recipient when you enable reply handling. This is
|
|
|
|
// more secure than using "From" to establish user identity, but can mean
|
|
|
|
// users may receive multiple emails when they are on mailing lists. Instead,
|
|
|
|
// you can use a single, non-unique reply to address and authenticate users
|
|
|
|
// based on the "From" address by setting this to 'true'. This trades away
|
|
|
|
// a little bit of security for convenience, but it's reasonable in many
|
|
|
|
// installs. Object interactions are still protected using hashes in the
|
|
|
|
// single public email address, so objects can not be replied to blindly.
|
|
|
|
'metamta.public-replies' => false,
|
|
|
|
|
2011-07-04 18:45:42 +02:00
|
|
|
// You can configure an email address like "bugs@phabricator.example.com"
|
|
|
|
// which will automatically create Maniphest tasks when users send email
|
|
|
|
// to it. This relies on the "From" address to authenticate users, so it is
|
|
|
|
// is not completely secure. To set this up, enter a complete email
|
|
|
|
// address like "bugs@phabricator.example.com" and then configure mail to
|
|
|
|
// that address so it routed to Phabricator (if you've already configured
|
|
|
|
// reply handlers, you're probably already done). See "Configuring Inbound
|
|
|
|
// Email" in the documentation for more information.
|
|
|
|
'metamta.maniphest.public-create-email' => null,
|
|
|
|
|
2011-08-21 21:03:57 +02:00
|
|
|
// If you enable 'metamta.public-replies', Phabricator uses "From" to
|
|
|
|
// authenticate users. You can additionally enable this setting to try to
|
|
|
|
// authenticate with 'Reply-To'. Note that this is completely spoofable and
|
|
|
|
// insecure (any user can set any 'Reply-To' address) but depending on the
|
|
|
|
// nature of your install or other deliverability conditions this might be
|
|
|
|
// okay. Generally, you can't do much more by spoofing Reply-To than be
|
|
|
|
// annoying (you can write but not read content). But, you know, this is
|
|
|
|
// still **COMPLETELY INSECURE**.
|
|
|
|
'metamta.insecure-auth-with-reply-to' => false,
|
|
|
|
|
2011-10-14 22:11:58 +02:00
|
|
|
// If you enable 'metamta.maniphest.public-create-email' and create an
|
|
|
|
// email address like "bugs@phabricator.example.com", it will default to
|
|
|
|
// rejecting mail which doesn't come from a known user. However, you might
|
|
|
|
// want to let anyone send email to this address; to do so, set a default
|
|
|
|
// author here (a Phabricator username). A typical use of this might be to
|
|
|
|
// create a "System Agent" user called "bugs" and use that name here. If you
|
|
|
|
// specify a valid username, mail will always be accepted and used to create
|
|
|
|
// a task, even if the sender is not a system user. The original email
|
|
|
|
// address will be stored in an 'From Email' field on the task.
|
|
|
|
'metamta.maniphest.default-public-author' => null,
|
|
|
|
|
2012-07-17 04:02:06 +02:00
|
|
|
// You can disable the Herald hints in email if users prefer smaller messages.
|
|
|
|
// These are the links under the headers "MANAGE HERALD RULES" and
|
|
|
|
// "WHY DID I GET THIS EMAIL?". If you set this to true, they will not appear
|
|
|
|
// in any mail. Users can still navigate to the links via the web interface.
|
|
|
|
'metamta.herald.show-hints' => true,
|
|
|
|
|
|
|
|
// You can disable the hints under "REPLY HANDLER ACTIONS" if users prefer
|
|
|
|
// smaller messages. The actions themselves will still work properly.
|
|
|
|
'metamta.reply.show-hints' => true,
|
|
|
|
|
|
|
|
// You can disable the "To:" and "Cc:" footers in mail if users prefer
|
|
|
|
// smaller messages.
|
|
|
|
'metamta.recipients.show-hints' => true,
|
|
|
|
|
2011-10-23 21:07:37 +02:00
|
|
|
// If this option is enabled, Phabricator will add a "Precedence: bulk"
|
|
|
|
// header to transactional mail (e.g., Differential, Maniphest and Herald
|
|
|
|
// notifications). This may improve the behavior of some auto-responder
|
|
|
|
// software and prevent it from replying. However, it may also cause
|
|
|
|
// deliverability issues -- notably, you currently can not send this header
|
|
|
|
// via Amazon SES, and enabling this option with SES will prevent delivery
|
|
|
|
// of any affected mail.
|
|
|
|
'metamta.precedence-bulk' => false,
|
|
|
|
|
Add optional "Re:" prefix to all threaded mail and allow disabling mail about
your own actions
Summary:
- Mail.app on Lion has cumbersome threading rules, see T782. Add an option to
stick "Re: " in front of all threaded mail so it behaves. This is horrible, but
apparently the least-horrible option.
- While I was in there, I added an option for T228.
Test Plan:
- Sent a bunch of threaded and unthreaded mail with varous "Re:" settings,
seemed to get "Re:" in the right places.
- Disabled email about my stuff, created a task with just me, got voided mail,
added a CC, got mail to just the CC.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, mkjones
Maniphest Tasks: T228, T782
Differential Revision: https://secure.phabricator.com/D1448
2012-01-18 05:32:28 +01:00
|
|
|
// Mail.app on OS X Lion won't respect threading headers unless the subject
|
|
|
|
// is prefixed with "Re:". If you enable this option, Phabricator will add
|
Fix various threading issues, particularly in Gmail
Summary:
- Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance.
- Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works).
- Add a preference to enable subject line variance.
- Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results.
NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better.
Test Plan:
Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK?
NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults.
I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/
Reviewers: btrahan, vrana, jungejason, nh
Reviewed By: btrahan
CC: cpiro, 20after4, aran
Maniphest Tasks: T1097, T847
Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
|
|
|
// "Re:" to the subject line of all mail which is expected to thread. If
|
|
|
|
// you've set 'metamta.one-mail-per-recipient', users can override this
|
|
|
|
// setting in their preferences.
|
Add optional "Re:" prefix to all threaded mail and allow disabling mail about
your own actions
Summary:
- Mail.app on Lion has cumbersome threading rules, see T782. Add an option to
stick "Re: " in front of all threaded mail so it behaves. This is horrible, but
apparently the least-horrible option.
- While I was in there, I added an option for T228.
Test Plan:
- Sent a bunch of threaded and unthreaded mail with varous "Re:" settings,
seemed to get "Re:" in the right places.
- Disabled email about my stuff, created a task with just me, got voided mail,
added a CC, got mail to just the CC.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, mkjones
Maniphest Tasks: T228, T782
Differential Revision: https://secure.phabricator.com/D1448
2012-01-18 05:32:28 +01:00
|
|
|
'metamta.re-prefix' => false,
|
|
|
|
|
Fix various threading issues, particularly in Gmail
Summary:
- Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance.
- Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works).
- Add a preference to enable subject line variance.
- Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results.
NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better.
Test Plan:
Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK?
NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults.
I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/
Reviewers: btrahan, vrana, jungejason, nh
Reviewed By: btrahan
CC: cpiro, 20after4, aran
Maniphest Tasks: T1097, T847
Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 18:31:03 +02:00
|
|
|
// If true, allow MetaMTA to change mail subjects to put text like
|
|
|
|
// '[Accepted]' and '[Commented]' in them. This makes subjects more useful,
|
|
|
|
// but might break threading on some clients. If you've set
|
|
|
|
// 'metamta.one-mail-per-recipient', users can override this setting in their
|
|
|
|
// preferences.
|
|
|
|
'metamta.vary-subjects' => true,
|
|
|
|
|
2011-02-01 01:50:08 +01:00
|
|
|
|
2011-02-28 04:47:22 +01:00
|
|
|
// -- Auth ------------------------------------------------------------------ //
|
|
|
|
|
|
|
|
// Can users login with a username/password, or by following the link from
|
|
|
|
// a password reset email? You can disable this and configure one or more
|
|
|
|
// OAuth providers instead.
|
2011-02-28 19:15:42 +01:00
|
|
|
'auth.password-auth-enabled' => true,
|
|
|
|
|
Enable multiple web sessions
Summary:
Conduit already has multiple-session code, just move it to the main
establishSession() method and set a web session limit larger than 1.
NOTE: This will log everyone out since we no longer look for the "web" session,
only for "web-1", "web-2", ..., etc. Presumably this doesn't matter.
Test Plan:
Applied patch, was logged out. Logged in in Safari. Verified I was issued
"web-1". Logged in in Firefox. Verified I was issued "web-2".
Kept logging in and out until I got issued "web-5", then did it again and was
issued "web-1" with a new key.
Ran conduit methods and verified they work and correctly cycled session keys.
Reviewed By: tuomaspelkonen
Reviewers: tuomaspelkonen, jungejason, aran
Commenters: jungejason
CC: rm, fzamore, ola, aran, epriestley, jungejason, tuomaspelkonen
Differential Revision: 264
2011-05-11 13:52:32 +02:00
|
|
|
// Maximum number of simultaneous web sessions each user is permitted to have.
|
|
|
|
// Setting this to "1" will prevent a user from logging in on more than one
|
|
|
|
// browser at the same time.
|
|
|
|
'auth.sessions.web' => 5,
|
|
|
|
|
|
|
|
// Maximum number of simultaneous Conduit sessions each user is permitted
|
|
|
|
// to have.
|
Improve a race condition in session establishment code
Summary:
If you try to establish several sessions quickly (e.g., by running several
copies of "arc" at once, as in "arc x | arc y"), the current logic has a high
chance of making them all pick the same conduit session to refresh (since it's
the oldest one when each process selects the current sessions). This means they
all issue updates against "conduit-3" (or whatever) and one ends up with a bogus
session.
Instead, do an update against the table with the session key we read, so only
one process wins the race. If we don't win the race, try again until we do or
have tried every session slot.
Test Plan:
- Wiped conduit sessions, ran arc commands to verify the fresh session case.
- Ran a bunch of arc piped to itself, e.g. "arc list | arc list | arc list |
...". It succeeds up to the session limit, and above that gets failures as
expected.
- Manually checked the session table to make sure things seemed reasonable
there.
- Generally ran a bunch of arc commands.
- Logged out and logged in on the web interface.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, btrahan
Maniphest Tasks: T687
Differential Revision: https://secure.phabricator.com/D1329
2012-01-06 02:55:21 +01:00
|
|
|
'auth.sessions.conduit' => 5,
|
Enable multiple web sessions
Summary:
Conduit already has multiple-session code, just move it to the main
establishSession() method and set a web session limit larger than 1.
NOTE: This will log everyone out since we no longer look for the "web" session,
only for "web-1", "web-2", ..., etc. Presumably this doesn't matter.
Test Plan:
Applied patch, was logged out. Logged in in Safari. Verified I was issued
"web-1". Logged in in Firefox. Verified I was issued "web-2".
Kept logging in and out until I got issued "web-5", then did it again and was
issued "web-1" with a new key.
Ran conduit methods and verified they work and correctly cycled session keys.
Reviewed By: tuomaspelkonen
Reviewers: tuomaspelkonen, jungejason, aran
Commenters: jungejason
CC: rm, fzamore, ola, aran, epriestley, jungejason, tuomaspelkonen
Differential Revision: 264
2011-05-11 13:52:32 +02:00
|
|
|
|
2011-07-24 20:02:08 +02:00
|
|
|
// Set this true to enable the Settings -> SSH Public Keys panel, which will
|
|
|
|
// allow users to associated SSH public keys with their accounts. This is only
|
|
|
|
// really useful if you're setting up services over SSH and want to use
|
|
|
|
// Phabricator for authentication; in most situations you can leave this
|
|
|
|
// disabled.
|
|
|
|
'auth.sshkeys.enabled' => false,
|
|
|
|
|
Allow installs to require email verification
Summary:
Allow installs to require users to verify email addresses before they can use Phabricator. If a user logs in without a verified email address, they're given instructions to verify their address.
This isn't too useful on its own since we don't actually have arbitrary email registration, but the next step is to allow installs to restrict email to only some domains (e.g., @mycompany.com).
Test Plan:
- Verification
- Set verification requirement to `true`.
- Tried to use Phabricator with an unverified account, was told to verify.
- Tried to use Conduit, was given a verification error.
- Verified account, used Phabricator.
- Unverified account, reset password, verified implicit verification, used Phabricator.
- People Admin Interface
- Viewed as admin. Clicked "Administrate User".
- Viewed as non-admin
- Sanity Checks
- Used Conduit normally from web/CLI with a verified account.
- Logged in/out.
- Sent password reset email.
- Created a new user.
- Logged in with an unverified user but with the configuration set to off.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran, csilvers
Maniphest Tasks: T1184
Differential Revision: https://secure.phabricator.com/D2520
2012-05-21 21:47:38 +02:00
|
|
|
// If true, email addresses must be verified (by clicking a link in an
|
Allow restriction of permitted email domains
Summary:
Allow allowed email addresses to be restricted to certain domains. This implies email must be verified.
This probably isn't QUITE ready for prime-time without a few other tweaks (better administrative tools, notably) but we're nearly there.
Test Plan:
- With no restrictions:
- Registered with OAuth
- Created an account with accountadmin
- Added an email
- With restrictions:
- Tried to OAuth register with a restricted address, was prompted to provide a valid one.
- Tried to OAuth register with a valid address, worked fine.
- Tried to accountadmin a restricted address, got blocked.
- Tried to accountadmin a valid address, worked fine.
- Tried to add a restricted address, blocked.
- Tried to add a valid address, worked fine.
- Created a user with People with an invalid address, got blocked.
- Created a user with People with a valid address, worked fine.
Reviewers: btrahan, csilvers
Reviewed By: csilvers
CC: aran, joe, csilvers
Maniphest Tasks: T1184
Differential Revision: https://secure.phabricator.com/D2581
2012-05-26 15:04:35 +02:00
|
|
|
// email) before a user can login. By default, verification is optional
|
|
|
|
// unless 'auth.email-domains' is nonempty (see below).
|
Allow installs to require email verification
Summary:
Allow installs to require users to verify email addresses before they can use Phabricator. If a user logs in without a verified email address, they're given instructions to verify their address.
This isn't too useful on its own since we don't actually have arbitrary email registration, but the next step is to allow installs to restrict email to only some domains (e.g., @mycompany.com).
Test Plan:
- Verification
- Set verification requirement to `true`.
- Tried to use Phabricator with an unverified account, was told to verify.
- Tried to use Conduit, was given a verification error.
- Verified account, used Phabricator.
- Unverified account, reset password, verified implicit verification, used Phabricator.
- People Admin Interface
- Viewed as admin. Clicked "Administrate User".
- Viewed as non-admin
- Sanity Checks
- Used Conduit normally from web/CLI with a verified account.
- Logged in/out.
- Sent password reset email.
- Created a new user.
- Logged in with an unverified user but with the configuration set to off.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran, csilvers
Maniphest Tasks: T1184
Differential Revision: https://secure.phabricator.com/D2520
2012-05-21 21:47:38 +02:00
|
|
|
'auth.require-email-verification' => false,
|
|
|
|
|
Allow restriction of permitted email domains
Summary:
Allow allowed email addresses to be restricted to certain domains. This implies email must be verified.
This probably isn't QUITE ready for prime-time without a few other tweaks (better administrative tools, notably) but we're nearly there.
Test Plan:
- With no restrictions:
- Registered with OAuth
- Created an account with accountadmin
- Added an email
- With restrictions:
- Tried to OAuth register with a restricted address, was prompted to provide a valid one.
- Tried to OAuth register with a valid address, worked fine.
- Tried to accountadmin a restricted address, got blocked.
- Tried to accountadmin a valid address, worked fine.
- Tried to add a restricted address, blocked.
- Tried to add a valid address, worked fine.
- Created a user with People with an invalid address, got blocked.
- Created a user with People with a valid address, worked fine.
Reviewers: btrahan, csilvers
Reviewed By: csilvers
CC: aran, joe, csilvers
Maniphest Tasks: T1184
Differential Revision: https://secure.phabricator.com/D2581
2012-05-26 15:04:35 +02:00
|
|
|
// You can restrict allowed email addresses to certain domains (like
|
|
|
|
// "yourcompany.com") by setting a list of allowed domains here. Users will
|
|
|
|
// only be allowed to register using email addresses at one of the domains,
|
|
|
|
// and will only be able to add new email addresses for these domains. If
|
|
|
|
// you configure this, it implies 'auth.require-email-verification'.
|
|
|
|
//
|
|
|
|
// To configure email domains, set a list of domains like this:
|
|
|
|
//
|
|
|
|
// array(
|
|
|
|
// 'yourcompany.com',
|
|
|
|
// 'yourcompany.co.uk',
|
|
|
|
// )
|
|
|
|
//
|
|
|
|
// You should omit the "@" from domains. Note that the domain must match
|
|
|
|
// exactly. If you allow "yourcompany.com", that permits "joe@yourcompany.com"
|
|
|
|
// but rejects "joe@mail.yourcompany.com".
|
|
|
|
'auth.email-domains' => array(),
|
|
|
|
|
2012-08-15 04:11:46 +02:00
|
|
|
// You can provide an arbitrary block of HTML here, which will appear on the
|
|
|
|
// login screen. Normally, you'd use this to provide login or registration
|
|
|
|
// instructions to users.
|
|
|
|
'auth.login-message' => null,
|
|
|
|
|
2011-02-28 19:15:42 +01:00
|
|
|
|
|
|
|
// -- Accounts -------------------------------------------------------------- //
|
|
|
|
|
|
|
|
// Is basic account information (email, real name, profile picture) editable?
|
|
|
|
// If you set up Phabricator to automatically synchronize account information
|
|
|
|
// from some other authoritative system, you can disable this to ensure
|
|
|
|
// information remains consistent across both systems.
|
|
|
|
'account.editable' => true,
|
|
|
|
|
Allow configuration of a minimum password length, unify password reset
interfaces
Summary:
- We have a hard-coded minimum length of 3 right now (and 1 in the other
interface), which is sort of silly.
- Provide a more reasonable default, and allow it to be configured.
- We have two password reset interfaces, one of which no longer actually
requires you to verify you own the account. This is more than a bit derp.
- Merge the interfaces into one, using either an email token or the account's
current password to let you change the password.
Test Plan:
- Reset password on an account.
- Changed password on an account.
- Created a new account, logged in, set the password.
- Tried to set a too-short password, got an error.
Reviewers: btrahan, jungejason, nh
Reviewed By: jungejason
CC: aran, jungejason
Maniphest Tasks: T766
Differential Revision: https://secure.phabricator.com/D1374
2012-01-12 05:26:38 +01:00
|
|
|
// When users set or reset a password, it must have at least this many
|
|
|
|
// characters.
|
|
|
|
'account.minimum-password-length' => 8,
|
|
|
|
|
2011-02-28 04:47:22 +01:00
|
|
|
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
// -- Facebook OAuth -------------------------------------------------------- //
|
2011-01-31 20:55:26 +01:00
|
|
|
|
|
|
|
// Can users use Facebook credentials to login to Phabricator?
|
|
|
|
'facebook.auth-enabled' => false,
|
|
|
|
|
2011-02-28 04:47:22 +01:00
|
|
|
// Can users use Facebook credentials to create new Phabricator accounts?
|
|
|
|
'facebook.registration-enabled' => true,
|
|
|
|
|
|
|
|
// Are Facebook accounts permanently linked to Phabricator accounts, or can
|
|
|
|
// the user unlink them?
|
|
|
|
'facebook.auth-permanent' => false,
|
|
|
|
|
2011-01-31 20:55:26 +01:00
|
|
|
// The Facebook "Application ID" to use for Facebook API access.
|
|
|
|
'facebook.application-id' => null,
|
|
|
|
|
|
|
|
// The Facebook "Application Secret" to use for Facebook API access.
|
|
|
|
'facebook.application-secret' => null,
|
|
|
|
|
2012-07-18 03:18:16 +02:00
|
|
|
// Should Phabricator reject requests made by users with
|
|
|
|
// Secure Browsing disabled?
|
|
|
|
'facebook.require-https-auth' => false,
|
2011-02-01 01:50:08 +01:00
|
|
|
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
// -- GitHub OAuth ---------------------------------------------------------- //
|
2011-02-21 07:47:56 +01:00
|
|
|
|
2012-02-03 02:25:31 +01:00
|
|
|
// Can users use GitHub credentials to login to Phabricator?
|
2011-02-21 07:47:56 +01:00
|
|
|
'github.auth-enabled' => false,
|
|
|
|
|
2012-02-03 02:25:31 +01:00
|
|
|
// Can users use GitHub credentials to create new Phabricator accounts?
|
2011-02-28 04:47:22 +01:00
|
|
|
'github.registration-enabled' => true,
|
|
|
|
|
2012-02-03 02:25:31 +01:00
|
|
|
// Are GitHub accounts permanently linked to Phabricator accounts, or can
|
2011-02-28 04:47:22 +01:00
|
|
|
// the user unlink them?
|
|
|
|
'github.auth-permanent' => false,
|
|
|
|
|
2012-02-03 02:25:31 +01:00
|
|
|
// The GitHub "Client ID" to use for GitHub API access.
|
2011-02-21 07:47:56 +01:00
|
|
|
'github.application-id' => null,
|
|
|
|
|
2012-02-03 02:25:31 +01:00
|
|
|
// The GitHub "Secret" to use for GitHub API access.
|
2011-02-21 07:47:56 +01:00
|
|
|
'github.application-secret' => null,
|
|
|
|
|
|
|
|
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
// -- Google OAuth ---------------------------------------------------------- //
|
Add Google as an OAuth2 provider (BETA)
Summary:
This is pretty straightforward, except:
- We need to request read/write access to the address book to get the account
ID (which we MUST have) and real name, email and account name (which we'd like
to have). This is way more access than we should need, but there's apparently no
"get_loggedin_user_basic_information" type of call in the Google API suite (or,
at least, I couldn't find one).
- We can't get the profile picture or profile URI since there's no Plus API
access and Google users don't have meaningful public pages otherwise.
- Google doesn't save the fact that you've authorized the app, so every time
you want to login you need to reaffirm that you want to give us silly amounts of
access. Phabricator sessions are pretty long-duration though so this shouldn't
be a major issue.
Test Plan:
- Registered, logged out, and logged in with Google.
- Registered, logged out, and logged in with Facebook / Github to make sure I
didn't break anything.
- Linked / unlinked Google accounts.
Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran
Reviewed By: aran
CC: aran, epriestley, Makinde
Differential Revision: 916
2011-09-09 01:37:22 +02:00
|
|
|
|
|
|
|
// Can users use Google credentials to login to Phabricator?
|
|
|
|
'google.auth-enabled' => false,
|
|
|
|
|
|
|
|
// Can users use Google credentials to create new Phabricator accounts?
|
|
|
|
'google.registration-enabled' => true,
|
|
|
|
|
|
|
|
// Are Google accounts permanently linked to Phabricator accounts, or can
|
|
|
|
// the user unlink them?
|
|
|
|
'google.auth-permanent' => false,
|
|
|
|
|
|
|
|
// The Google "Client ID" to use for Google API access.
|
|
|
|
'google.application-id' => null,
|
|
|
|
|
|
|
|
// The Google "Client Secret" to use for Google API access.
|
|
|
|
'google.application-secret' => null,
|
|
|
|
|
2012-06-13 17:52:05 +02:00
|
|
|
// -- LDAP Auth ----------------------------------------------------- //
|
|
|
|
// Enable ldap auth
|
|
|
|
'ldap.auth-enabled' => false,
|
|
|
|
|
|
|
|
// The LDAP server hostname
|
|
|
|
'ldap.hostname' => '',
|
|
|
|
|
2012-08-06 00:11:45 +02:00
|
|
|
// The LDAP server port
|
|
|
|
'ldap.port' => 389,
|
|
|
|
|
2012-06-13 17:52:05 +02:00
|
|
|
// The LDAP base domain name
|
|
|
|
'ldap.base_dn' => '',
|
|
|
|
|
|
|
|
// The attribute to be regarded as 'username'. Has to be unique
|
|
|
|
'ldap.search_attribute' => '',
|
|
|
|
|
2012-07-26 03:55:48 +02:00
|
|
|
// Perform a search to find a user
|
|
|
|
// Many LDAP installations do not have the username in the dn, if this is
|
|
|
|
// true for you set this to true and configure the username_attribute below
|
|
|
|
'ldap.search-first' => false,
|
|
|
|
|
|
|
|
// The attribute to search for if you have to search for a user
|
2012-07-26 23:32:51 +02:00
|
|
|
'ldap.username-attribute' => '',
|
2012-07-26 03:55:48 +02:00
|
|
|
|
2012-06-13 17:52:05 +02:00
|
|
|
// The attribute(s) to be regarded as 'real name'.
|
|
|
|
// If more then one attribute is supplied the values of the attributes in
|
|
|
|
// the array will be joined
|
|
|
|
'ldap.real_name_attributes' => array(),
|
|
|
|
|
2012-07-13 14:16:16 +02:00
|
|
|
// A domain name to use when authenticating against Active Directory
|
|
|
|
// (e.g. 'example.com')
|
|
|
|
'ldap.activedirectory_domain' => '',
|
2012-07-23 21:04:53 +02:00
|
|
|
|
2012-06-13 17:52:05 +02:00
|
|
|
// The LDAP version
|
|
|
|
'ldap.version' => 3,
|
2012-07-20 00:04:18 +02:00
|
|
|
|
2012-07-18 22:38:24 +02:00
|
|
|
// LDAP Referrals Option
|
|
|
|
// Whether referrals should be followed by the client
|
|
|
|
// Should be set to 0 if you use Windows 2003 AD
|
|
|
|
'ldap.referrals' => 1,
|
2012-06-13 17:52:05 +02:00
|
|
|
|
2012-11-30 13:21:44 +01:00
|
|
|
// The anonymous user name to use before searching a user.
|
|
|
|
// Many LDAP installations require login even before searching a user, set
|
|
|
|
// this option to enable it.
|
|
|
|
'ldap.anonymous-user-name' => '',
|
|
|
|
|
|
|
|
// The password of the LDAP anonymous user.
|
|
|
|
'ldap.anonymous-user-password' => '',
|
|
|
|
|
|
|
|
|
2012-05-08 21:08:05 +02:00
|
|
|
// -- Disqus OAuth ---------------------------------------------------------- //
|
|
|
|
|
|
|
|
// Can users use Disqus credentials to login to Phabricator?
|
|
|
|
'disqus.auth-enabled' => false,
|
|
|
|
|
|
|
|
// Can users use Disqus credentials to create new Phabricator accounts?
|
|
|
|
'disqus.registration-enabled' => true,
|
|
|
|
|
|
|
|
// Are Disqus accounts permanently linked to Phabricator accounts, or can
|
|
|
|
// the user unlink them?
|
|
|
|
'disqus.auth-permanent' => false,
|
|
|
|
|
|
|
|
// The Disqus "Client ID" to use for Disqus API access.
|
|
|
|
'disqus.application-id' => null,
|
|
|
|
|
|
|
|
// The Disqus "Client Secret" to use for Disqus API access.
|
|
|
|
'disqus.application-secret' => null,
|
|
|
|
|
|
|
|
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
// -- Phabricator OAuth ----------------------------------------------------- //
|
|
|
|
|
|
|
|
// Meta-town -- Phabricator is itself an OAuth Provider
|
|
|
|
// TODO -- T887 -- make this support multiple Phabricator instances!
|
|
|
|
|
|
|
|
// The URI of the Phabricator instance to use as an OAuth server.
|
|
|
|
'phabricator.oauth-uri' => null,
|
|
|
|
|
|
|
|
// Can users use Phabricator credentials to login to Phabricator?
|
|
|
|
'phabricator.auth-enabled' => false,
|
|
|
|
|
|
|
|
// Can users use Phabricator credentials to create new Phabricator accounts?
|
|
|
|
'phabricator.registration-enabled' => true,
|
|
|
|
|
|
|
|
// Are Phabricator accounts permanently linked to Phabricator accounts, or can
|
|
|
|
// the user unlink them?
|
|
|
|
'phabricator.auth-permanent' => false,
|
|
|
|
|
|
|
|
// The Phabricator "Client ID" to use for Phabricator API access.
|
|
|
|
'phabricator.application-id' => null,
|
|
|
|
|
|
|
|
// The Phabricator "Client Secret" to use for Phabricator API access.
|
|
|
|
'phabricator.application-secret' => null,
|
|
|
|
|
2012-04-12 22:09:04 +02:00
|
|
|
|
2011-02-01 01:50:08 +01:00
|
|
|
// -- Recaptcha ------------------------------------------------------------- //
|
|
|
|
|
2012-01-12 21:56:11 +01:00
|
|
|
// Is Recaptcha enabled? If disabled, captchas will not appear. You should
|
|
|
|
// enable Recaptcha if your install is public-facing, as it hinders
|
|
|
|
// brute-force attacks.
|
2011-02-01 01:50:08 +01:00
|
|
|
'recaptcha.enabled' => false,
|
2011-02-02 00:52:04 +01:00
|
|
|
|
2011-02-01 01:50:08 +01:00
|
|
|
// Your Recaptcha public key, obtained from Recaptcha.
|
2011-01-31 20:55:26 +01:00
|
|
|
'recaptcha.public-key' => null,
|
2011-02-02 00:52:04 +01:00
|
|
|
|
2011-02-01 01:50:08 +01:00
|
|
|
// Your Recaptcha private key, obtained from Recaptcha.
|
2011-01-31 20:55:26 +01:00
|
|
|
'recaptcha.private-key' => null,
|
|
|
|
|
|
|
|
|
2011-02-11 23:58:45 +01:00
|
|
|
// -- Misc ------------------------------------------------------------------ //
|
|
|
|
|
|
|
|
// This is hashed with other inputs to generate CSRF tokens. If you want, you
|
|
|
|
// can change it to some other string which is unique to your install. This
|
|
|
|
// will make your install more secure in a vague, mostly theoretical way. But
|
|
|
|
// it will take you like 3 seconds of mashing on your keyboard to set it up so
|
|
|
|
// you might as well.
|
|
|
|
'phabricator.csrf-key' => '0b7ec0592e0a2829d8b71df2fa269b2c6172eca3',
|
|
|
|
|
2011-05-05 08:09:42 +02:00
|
|
|
// This is hashed with other inputs to generate mail tokens. If you want, you
|
|
|
|
// can change it to some other string which is unique to your install. In
|
|
|
|
// particular, you will want to do this if you accidentally send a bunch of
|
|
|
|
// mail somewhere you shouldn't have, to invalidate all old reply-to
|
|
|
|
// addresses.
|
|
|
|
'phabricator.mail-key' => '5ce3e7e8787f6e40dfae861da315a5cdf1018f12',
|
|
|
|
|
2012-06-21 20:12:48 +02:00
|
|
|
// Version string displayed in the footer. You can generate this value from
|
|
|
|
// Git log or from the current date in the deploy with a script like this:
|
|
|
|
//
|
|
|
|
// git log -n1 --pretty=%h > version.txt
|
|
|
|
//
|
|
|
|
// You can then use this generated value like this:
|
|
|
|
//
|
|
|
|
// 'phabricator.version' =>
|
|
|
|
// file_get_contents(dirname(__FILE__).'/version.txt'),
|
2011-02-11 23:58:45 +01:00
|
|
|
'phabricator.version' => 'UNSTABLE',
|
2011-02-22 18:22:57 +01:00
|
|
|
|
2011-04-03 02:21:16 +02:00
|
|
|
// PHP requires that you set a timezone in your php.ini before using date
|
|
|
|
// functions, or it will emit a warning. If this isn't possible (for instance,
|
|
|
|
// because you are using HPHP) you can set some valid constant for
|
|
|
|
// date_default_timezone_set() here and Phabricator will set it on your
|
|
|
|
// behalf, silencing the warning.
|
|
|
|
'phabricator.timezone' => null,
|
|
|
|
|
2011-08-17 23:29:53 +02:00
|
|
|
// When unhandled exceptions occur, stack traces are hidden by default.
|
|
|
|
// You can enable traces for development to make it easier to debug problems.
|
|
|
|
'phabricator.show-stack-traces' => false,
|
|
|
|
|
2012-01-04 16:35:52 +01:00
|
|
|
// Shows an error callout if a page generated PHP errors, warnings or notices.
|
|
|
|
// This makes it harder to miss problems while developing Phabricator.
|
|
|
|
'phabricator.show-error-callout' => false,
|
|
|
|
|
2012-01-20 16:39:55 +01:00
|
|
|
// When users write comments which have URIs, they'll be automatically linked
|
2011-10-09 22:47:27 +02:00
|
|
|
// if the protocol appears in this set. This whitelist is primarily to prevent
|
|
|
|
// security issues like javascript:// URIs.
|
|
|
|
'uri.allowed-protocols' => array(
|
|
|
|
'http' => true,
|
|
|
|
'https' => true,
|
|
|
|
),
|
|
|
|
|
Add an option to switch tokenizers to use "ondemand" instead of "preloaded"
datasources
Summary:
The open source Phabricator has like 3,500 user accounts now and it takes a
while to pull/render them. Add an option to switch to ondemand for large
installs.
I'll follow up with a patch at some point to address a couple of name things:
- Denormalize last names into a keyed column (although this evidences some
bias toward the western world).
- Force all usernames to lowercase (sorry Girish, Makinde).
Also this patch is so clean it's crazy.
Didn't bother with other object types for now, I'm planning to dedicate a few
days to Projects at some point and I'll flesh out some auxiliary features like
this when I do that.
Test Plan: Switched to ondemand, verified data was queried dynamically. Switched
back, verified data was preloaded.
Reviewers: jungejason, nh, tuomaspelkonen, aran
Reviewed By: nh
CC: aran, epriestley, nh
Differential Revision: 923
2011-09-13 20:00:17 +02:00
|
|
|
// Tokenizers are UI controls which let the user select other users, email
|
|
|
|
// addresses, project names, etc., by typing the first few letters and having
|
|
|
|
// the control autocomplete from a list. They can load their data in two ways:
|
|
|
|
// either in a big chunk up front, or as the user types. By default, the data
|
|
|
|
// is loaded in a big chunk. This is simpler and performs better for small
|
|
|
|
// datasets. However, if you have a very large number of users or projects,
|
|
|
|
// (in the ballpark of more than a thousand), loading all that data may become
|
|
|
|
// slow enough that it's worthwhile to query on demand instead. This makes
|
|
|
|
// the typeahead slightly less responsive but overall performance will be much
|
|
|
|
// better if you have a ton of stuff. You can figure out which setting is
|
|
|
|
// best for your install by changing this setting and then playing with a
|
|
|
|
// user tokenizer (like the user selectors in Maniphest or Differential) and
|
|
|
|
// seeing which setting loads faster and feels better.
|
|
|
|
'tokenizer.ondemand' => false,
|
2011-08-08 00:14:23 +02:00
|
|
|
|
Provide a configuration flag to disable silliness in the UI
Summary: See comments. A few installs have remarked that their organizations
would prefer buttons labled "Submit" to buttons labeled "Clowncopterize".
Test Plan:
- In "serious" mode, verified Differential and Maniphest have serious strings,
tasks can not be closed out of spite, and reset/welcome emails are extremely
serious.
- In unserious mode, verified Differential and Maniphest have normal strings,
tasks can be closed out of spite, and reset/welcome emails are silly.
- This does not disable the "fax these changes" message in Arcanist (no
reasonable way for it to read the config value) or the rainbow syntax
highlighter (already removable though configuration).
Reviewers: moskov, jungejason, nh, tuomaspelkonen, aran
Reviewed By: moskov
CC: aran, moskov
Differential Revision: 1081
2011-11-04 23:16:34 +01:00
|
|
|
// By default, Phabricator includes some silly nonsense in the UI, such as
|
|
|
|
// a submit button called "Clowncopterize" in Differential and a call to
|
|
|
|
// "Leap Into Action". If you'd prefer more traditional UI strings like
|
|
|
|
// "Submit", you can set this flag to disable most of the jokes and easter
|
|
|
|
// eggs.
|
|
|
|
'phabricator.serious-business' => false,
|
|
|
|
|
|
|
|
|
2011-02-22 18:19:14 +01:00
|
|
|
// -- Files ----------------------------------------------------------------- //
|
|
|
|
|
|
|
|
// Lists which uploaded file types may be viewed in the browser. If a file
|
|
|
|
// has a mime type which does not appear in this list, it will always be
|
Move ALL files to serve from the alternate file domain, not just files without
"Content-Disposition: attachment"
Summary:
We currently serve some files off the primary domain (with "Content-Disposition:
attachment" + a CSRF check) and some files off the alternate domain (without
either).
This is not sufficient, because some UAs (like the iPad) ignore
"Content-Disposition: attachment". So there's an attack that goes like this:
- Alice uploads xss.html
- Alice says to Bob "hey download this file on your iPad"
- Bob clicks "Download" on Phabricator on his iPad, gets XSS'd.
NOTE: This removes the CSRF check for downloading files. The check is nice to
have but only raises the barrier to entry slightly. Between iPad / sniffing /
flash bytecode attacks, single-domain installs are simply insecure. We could
restore the check at some point in conjunction with a derived authentication
cookie (i.e., a mini-session-token which is only useful for downloading files),
but that's a lot of complexity to drop all at once.
(Because files are now authenticated only by knowing the PHID and secret key,
this also fixes the "no profile pictures in public feed while logged out"
issue.)
Test Plan: Viewed, info'd, and downloaded files
Reviewers: btrahan, arice, alok
Reviewed By: arice
CC: aran, epriestley
Maniphest Tasks: T843
Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
|
|
|
// downloaded instead of displayed. This is mainly a usability
|
2011-02-22 18:19:14 +01:00
|
|
|
// consideration, since browsers tend to freak out when viewing enormous
|
|
|
|
// binary files.
|
|
|
|
//
|
|
|
|
// The keys in this array are viewable mime types; the values are the mime
|
|
|
|
// types they will be delivered as when they are viewed in the browser.
|
Provide a setting which forces all file views to be served from an alternate
domain
Summary:
See D758, D759.
- Provide a strongly recommended setting which permits configuration of an
alternate domain.
- Lock cookies down better: set them on the exact domain, and use SSL-only if
the configuration is HTTPS.
- Prevent Phabriator from setting cookies on other domains.
This assumes D759 will land, it is not effective without that change.
Test Plan:
- Attempted to login from a different domain and was rejected.
- Logged out, logged back in normally.
- Put install in setup mode and verified it revealed a warning.
- Configured an alterate domain.
- Tried to view an image with an old URI, got a 400.
- Went to /files/ and verified links rendered to the alternate domain.
- Viewed an alternate domain file.
- Tried to view an alternate domain file without the secret key, got a 404.
Reviewers: andrewjcg, erling, aran, tuomaspelkonen, jungejason, codeblock
CC: aran
Differential Revision: 760
2011-08-02 07:24:00 +02:00
|
|
|
//
|
Move ALL files to serve from the alternate file domain, not just files without
"Content-Disposition: attachment"
Summary:
We currently serve some files off the primary domain (with "Content-Disposition:
attachment" + a CSRF check) and some files off the alternate domain (without
either).
This is not sufficient, because some UAs (like the iPad) ignore
"Content-Disposition: attachment". So there's an attack that goes like this:
- Alice uploads xss.html
- Alice says to Bob "hey download this file on your iPad"
- Bob clicks "Download" on Phabricator on his iPad, gets XSS'd.
NOTE: This removes the CSRF check for downloading files. The check is nice to
have but only raises the barrier to entry slightly. Between iPad / sniffing /
flash bytecode attacks, single-domain installs are simply insecure. We could
restore the check at some point in conjunction with a derived authentication
cookie (i.e., a mini-session-token which is only useful for downloading files),
but that's a lot of complexity to drop all at once.
(Because files are now authenticated only by knowing the PHID and secret key,
this also fixes the "no profile pictures in public feed while logged out"
issue.)
Test Plan: Viewed, info'd, and downloaded files
Reviewers: btrahan, arice, alok
Reviewed By: arice
CC: aran, epriestley
Maniphest Tasks: T843
Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
|
|
|
// IMPORTANT: Configure 'security.alternate-file-domain' above! Your install
|
|
|
|
// is NOT safe if it is left unconfigured.
|
2011-02-24 23:52:57 +01:00
|
|
|
'files.viewable-mime-types' => array(
|
2011-02-22 18:19:14 +01:00
|
|
|
'image/jpeg' => 'image/jpeg',
|
|
|
|
'image/jpg' => 'image/jpg',
|
|
|
|
'image/png' => 'image/png',
|
2011-03-25 05:32:26 +01:00
|
|
|
'image/gif' => 'image/gif',
|
2011-02-22 18:19:14 +01:00
|
|
|
'text/plain' => 'text/plain; charset=utf-8',
|
2012-05-02 22:43:45 +02:00
|
|
|
'text/x-diff' => 'text/plain; charset=utf-8',
|
2012-03-14 01:26:30 +01:00
|
|
|
|
|
|
|
// ".ico" favicon files, which have mime type diversity. See:
|
|
|
|
// http://en.wikipedia.org/wiki/ICO_(file_format)#MIME_type
|
|
|
|
'image/x-ico' => 'image/x-icon',
|
|
|
|
'image/x-icon' => 'image/x-icon',
|
|
|
|
'image/vnd.microsoft.icon' => 'image/x-icon',
|
2011-02-22 18:19:14 +01:00
|
|
|
),
|
2011-01-31 20:55:26 +01:00
|
|
|
|
2012-03-20 03:52:24 +01:00
|
|
|
// List of mime types which can be used as the source for an <img /> tag.
|
|
|
|
// This should be a subset of 'files.viewable-mime-types' and exclude files
|
|
|
|
// like text.
|
|
|
|
'files.image-mime-types' => array(
|
|
|
|
'image/jpeg' => true,
|
|
|
|
'image/jpg' => true,
|
|
|
|
'image/png' => true,
|
|
|
|
'image/gif' => true,
|
|
|
|
'image/x-ico' => true,
|
|
|
|
'image/x-icon' => true,
|
|
|
|
'image/vnd.microsoft.icon' => true,
|
|
|
|
),
|
|
|
|
|
2011-07-20 07:48:38 +02:00
|
|
|
// -- Storage --------------------------------------------------------------- //
|
|
|
|
|
|
|
|
// Phabricator allows users to upload files, and can keep them in various
|
|
|
|
// storage engines. This section allows you to configure which engines
|
|
|
|
// Phabricator will use, and how it will use them.
|
|
|
|
|
|
|
|
// The largest filesize Phabricator will store in the MySQL BLOB storage
|
|
|
|
// engine, which just uses a database table to store files. While this isn't a
|
2012-08-28 00:40:28 +02:00
|
|
|
// best practice, it's really easy to set up. Set this to 0 to disable use of
|
|
|
|
// the MySQL blob engine.
|
2011-07-20 07:48:38 +02:00
|
|
|
'storage.mysql-engine.max-size' => 1000000,
|
|
|
|
|
|
|
|
// Phabricator provides a local disk storage engine, which just writes files
|
|
|
|
// to some directory on local disk. The webserver must have read/write
|
|
|
|
// permissions on this directory. This is straightforward and suitable for
|
|
|
|
// most installs, but will not scale past one web frontend unless the path
|
|
|
|
// is actually an NFS mount, since you'll end up with some of the files
|
|
|
|
// written to each web frontend and no way for them to share. To use the
|
|
|
|
// local disk storage engine, specify the path to a directory here. To
|
|
|
|
// disable it, specify null.
|
|
|
|
'storage.local-disk.path' => null,
|
|
|
|
|
2011-07-31 22:54:58 +02:00
|
|
|
// If you want to store files in Amazon S3, specify an AWS access and secret
|
|
|
|
// key here and a bucket name below.
|
|
|
|
'amazon-s3.access-key' => null,
|
|
|
|
'amazon-s3.secret-key' => null,
|
|
|
|
|
2012-11-16 13:07:57 +01:00
|
|
|
// To use a custom endpoint, specify it here. Normally, you do not need to
|
|
|
|
// configure this.
|
|
|
|
'amazon-s3.endpoint' => null,
|
|
|
|
|
2011-07-31 22:54:58 +02:00
|
|
|
// Set this to a valid Amazon S3 bucket to store files there. You must also
|
|
|
|
// configure S3 access keys above.
|
|
|
|
'storage.s3.bucket' => null,
|
2011-07-20 07:48:38 +02:00
|
|
|
|
|
|
|
// Phabricator uses a storage engine selector to choose which storage engine
|
|
|
|
// to use when writing file data. If you add new storage engines or want to
|
|
|
|
// provide very custom rules (e.g., write images to one storage engine and
|
|
|
|
// other files to a different one), you can provide an alternate
|
|
|
|
// implementation here. The default engine will use choose MySQL, Local Disk,
|
|
|
|
// and S3, in that order, if they have valid configurations above and a file
|
|
|
|
// fits within configured limits.
|
|
|
|
'storage.engine-selector' => 'PhabricatorDefaultFileStorageEngineSelector',
|
|
|
|
|
2012-05-04 02:30:17 +02:00
|
|
|
// Set the size of the largest file a user may upload. This is used to render
|
|
|
|
// text like "Maximum file size: 10MB" on interfaces where users can upload
|
|
|
|
// files, and files larger than this size will be rejected.
|
|
|
|
//
|
|
|
|
// Specify this limit in bytes, or using a "K", "M", or "G" suffix.
|
|
|
|
//
|
|
|
|
// NOTE: Setting this to a large size is NOT sufficient to allow users to
|
|
|
|
// upload large files. You must also configure a number of other settings. To
|
|
|
|
// configure file upload limits, consult the article "Configuring File Upload
|
|
|
|
// Limits" in the documentation. Once you've configured some limit across all
|
|
|
|
// levels of the server, you can set this limit to an appropriate value and
|
|
|
|
// the UI will then reflect the actual configured limit.
|
|
|
|
'storage.upload-size-limit' => null,
|
|
|
|
|
2012-04-30 20:56:58 +02:00
|
|
|
// Phabricator puts databases in a namespace, which defualts to "phabricator"
|
|
|
|
// -- for instance, the Differential database is named
|
|
|
|
// "phabricator_differential" by default. You can change this namespace if you
|
|
|
|
// want. Normally, you should not do this unless you are developing
|
|
|
|
// Phabricator and using namespaces to separate multiple sandbox datasets.
|
|
|
|
'storage.default-namespace' => 'phabricator',
|
|
|
|
|
2011-08-08 00:14:23 +02:00
|
|
|
|
|
|
|
// -- Search ---------------------------------------------------------------- //
|
|
|
|
|
[NO CLUE WHAT I'M DOING] Add an Elasticsearch engine
Summary:
I have no idea what I'm doing, but here's part of an elasticsearch engine. These things work:
- Indexing stuff (??)
- Searching for text/type?
- Reconstructing things??
All the complicated stuff doesn't work. I'm having a hard time figuring out the best way to model things because elasticsearch's documentation is not exactly the most complete or illuminating.
@amckinley, does this look sane-ish so far? Particularly, the /phabricator/<type>/<phid>/ URI scheme and how I've set up the relationships and fields in the documents?
How should I model the relationship and field queries? I want, like, an "equal" query but it seems like I've got "text" or "term" to work with and neither are exact match? And "term" doesn't consider PHIDs to be terms since they have hyphens in them?
I'll keep kind of slogging my way forward here but if you have valuable wisdom to share it would probably get me to a better end state much faster. The whole query construction phase is pretty much black magic to me.
Test Plan: nyancat
Reviewers: amckinley, vrana
Reviewed By: vrana
CC: jungejason, tuomaspelkonen, aran, 20after4, vrana
Differential Revision: https://secure.phabricator.com/D790
2012-04-21 00:33:09 +02:00
|
|
|
// Phabricator supports Elastic Search; to use it, specify a host like
|
|
|
|
// 'http://elastic.example.com:9200/' here.
|
|
|
|
'search.elastic.host' => null,
|
|
|
|
|
2011-08-08 00:14:23 +02:00
|
|
|
// Phabricator uses a search engine selector to choose which search engine
|
|
|
|
// to use when indexing and reconstructing documents, and when executing
|
|
|
|
// queries. You can override the engine selector to provide a new selector
|
|
|
|
// class which can select some custom engine you implement, if you want to
|
|
|
|
// store your documents in some search engine which does not have default
|
|
|
|
// support.
|
|
|
|
'search.engine-selector' => 'PhabricatorDefaultSearchEngineSelector',
|
|
|
|
|
|
|
|
|
2011-04-13 21:12:02 +02:00
|
|
|
// -- Differential ---------------------------------------------------------- //
|
|
|
|
|
|
|
|
'differential.revision-custom-detail-renderer' => null,
|
|
|
|
|
2011-05-26 22:13:36 +02:00
|
|
|
// Array for custom remarkup rules. The array should have a list of
|
|
|
|
// class names of classes that extend PhutilRemarkupRule
|
|
|
|
'differential.custom-remarkup-rules' => null,
|
|
|
|
|
|
|
|
// Array for custom remarkup block rules. The array should have a list of
|
|
|
|
// class names of classes that extend PhutilRemarkupEngineBlockRule
|
|
|
|
'differential.custom-remarkup-block-rules' => null,
|
2011-04-13 21:12:02 +02:00
|
|
|
|
2012-06-04 19:19:24 +02:00
|
|
|
// List of file regexps where whitespace is meaningful and should not
|
2011-07-22 22:15:11 +02:00
|
|
|
// use 'ignore-all' by default
|
|
|
|
'differential.whitespace-matters' => array(
|
|
|
|
'/\.py$/',
|
2012-01-24 23:47:04 +01:00
|
|
|
'/\.l?hs$/',
|
2011-07-22 22:15:11 +02:00
|
|
|
),
|
|
|
|
|
2011-08-10 20:29:08 +02:00
|
|
|
'differential.field-selector' => 'DifferentialDefaultFieldSelector',
|
|
|
|
|
2012-02-12 10:36:05 +01:00
|
|
|
// Differential can show "Host" and "Path" fields on revisions, with
|
|
|
|
// information about the machine and working directory where the
|
2012-02-07 01:34:25 +01:00
|
|
|
// change came from. These fields are disabled by default because they may
|
2012-02-06 21:14:07 +01:00
|
|
|
// occasionally have sensitive information; you can set this to true to
|
|
|
|
// enable them.
|
|
|
|
'differential.show-host-field' => false,
|
|
|
|
|
2012-04-10 22:36:05 +02:00
|
|
|
// Differential has a required "Test Plan" field by default, which requires
|
|
|
|
// authors to fill out information about how they verified the correctness of
|
|
|
|
// their changes when sending code for review. If you'd prefer not to use
|
|
|
|
// this field, you can disable it here. You can also make it optional
|
|
|
|
// (instead of required) below.
|
|
|
|
'differential.show-test-plan-field' => true,
|
|
|
|
|
|
|
|
// Differential has a required "Test Plan" field by default. You can make it
|
|
|
|
// optional by setting this to false. You can also completely remove it above,
|
|
|
|
// if you prefer.
|
|
|
|
'differential.require-test-plan-field' => true,
|
|
|
|
|
2011-09-14 17:11:05 +02:00
|
|
|
// If you set this to true, users can "!accept" revisions via email (normally,
|
|
|
|
// they can take other actions but can not "!accept"). This action is disabled
|
|
|
|
// by default because email authentication can be configured to be very weak,
|
|
|
|
// and, socially, email "!accept" is kind of sketchy and implies revisions may
|
|
|
|
// not actually be receiving thorough review.
|
|
|
|
'differential.enable-email-accept' => false,
|
|
|
|
|
2011-10-24 21:27:16 +02:00
|
|
|
// If you set this to true, users won't need to login to view differential
|
|
|
|
// revisions. Anonymous users will have read-only access and won't be able to
|
|
|
|
// interact with the revisions.
|
|
|
|
'differential.anonymous-access' => false,
|
|
|
|
|
2012-11-09 22:33:58 +01:00
|
|
|
// If you set this to true, revision author email address information will
|
|
|
|
// be exposed in Conduit. This is useful for Arcanist.
|
|
|
|
//
|
|
|
|
// For example, consider the "arc patch DX" workflow which needs to ask
|
|
|
|
// Differential for the revision DX. This data often should contain
|
|
|
|
// the author's email address, eg "George Washington
|
|
|
|
// <gwashinton@example.com>" when DX is a git or mercurial revision. If this
|
|
|
|
// option is false, Differential defaults to the best it can, something like
|
|
|
|
// "George Washington" or "gwashington".
|
|
|
|
'differential.expose-emails-prudently' => false,
|
|
|
|
|
2012-01-19 18:39:54 +01:00
|
|
|
// List of file regexps that should be treated as if they are generated by
|
2012-07-03 09:38:49 +02:00
|
|
|
// an automatic process, and thus get hidden by default in differential.
|
2012-01-19 18:39:54 +01:00
|
|
|
'differential.generated-paths' => array(
|
|
|
|
// '/config\.h$/',
|
|
|
|
// '#/autobuilt/#',
|
|
|
|
),
|
|
|
|
|
2012-07-03 09:38:49 +02:00
|
|
|
// If you set this to true, users can accept their own revisions. This action
|
|
|
|
// is disabled by default because it's most likely not a behavior you want,
|
|
|
|
// but it proves useful if you are working alone on a project and want to make
|
|
|
|
// use of all of differential's features.
|
|
|
|
'differential.allow-self-accept' => false,
|
2011-08-10 20:29:08 +02:00
|
|
|
|
2012-08-28 23:17:23 +02:00
|
|
|
// If you set this to true, any user can close any revision so long as it has
|
|
|
|
// been accepted. This can be useful depending on your development model. For
|
|
|
|
// example, github-style pull requests where the reviewer is often the
|
|
|
|
// actual committer can benefit from turning this option to true. If false,
|
|
|
|
// only the submitter can close a revision.
|
|
|
|
'differential.always-allow-close' => false,
|
|
|
|
|
2012-08-21 23:20:21 +02:00
|
|
|
// Revisions newer than this number of days are marked as fresh in Action
|
|
|
|
// Required and Revisions Waiting on You views. Only work days (not weekends
|
|
|
|
// and holidays) are included. Set to 0 to disable this feature.
|
|
|
|
'differential.days-fresh' => 1,
|
|
|
|
|
|
|
|
// Similar to 'differential.days-fresh' but marks stale revisions. If the
|
|
|
|
// revision is even older than it is marked as old.
|
|
|
|
'differential.days-stale' => 3,
|
|
|
|
|
2011-04-13 21:12:02 +02:00
|
|
|
// -- Maniphest ------------------------------------------------------------- //
|
|
|
|
|
|
|
|
'maniphest.enabled' => true,
|
|
|
|
|
2011-08-05 18:44:43 +02:00
|
|
|
// Array of custom fields for Maniphest tasks. For details on adding custom
|
|
|
|
// fields to Maniphest, see "Maniphest User Guide: Adding Custom Fields".
|
2011-07-27 18:49:50 +02:00
|
|
|
'maniphest.custom-fields' => array(),
|
|
|
|
|
2011-08-05 18:44:43 +02:00
|
|
|
// Class which drives custom field construction. See "Maniphest User Guide:
|
|
|
|
// Adding Custom Fields" in the documentation for more information.
|
|
|
|
'maniphest.custom-task-extensions-class' => 'ManiphestDefaultTaskExtensions',
|
2011-08-08 00:14:23 +02:00
|
|
|
|
2012-10-04 23:19:37 +02:00
|
|
|
// What should the default task priority be in create flows?
|
|
|
|
// See the constants in @{class:ManiphestTaskPriority} for valid values.
|
|
|
|
// Defaults to "needs triage".
|
|
|
|
'maniphest.default-priority' => 90,
|
|
|
|
|
2012-02-18 01:08:35 +01:00
|
|
|
// -- Phriction ------------------------------------------------------------- //
|
|
|
|
|
|
|
|
'phriction.enabled' => true,
|
|
|
|
|
2012-10-01 02:10:27 +02:00
|
|
|
// -- Phame ----------------------------------------------------------------- //
|
|
|
|
|
|
|
|
// Should Phame users have Disqus comment widget, and if so what's the
|
|
|
|
// website shortname to use? For example, secure.phabricator.org uses
|
|
|
|
// "phabricator", which we registered with Disqus. If you aren't familiar
|
|
|
|
// with Disqus, see:
|
|
|
|
// Disqus quick start guide - http://docs.disqus.com/help/4/
|
|
|
|
// Information on shortnames - http://docs.disqus.com/help/68/
|
|
|
|
'disqus.shortname' => null,
|
|
|
|
|
2012-10-17 17:36:48 +02:00
|
|
|
// Directories to look for Phame skins inside of.
|
|
|
|
'phame.skins' => array(
|
2012-10-17 17:37:05 +02:00
|
|
|
'externals/skins/',
|
2012-10-17 17:36:48 +02:00
|
|
|
),
|
|
|
|
|
2011-05-27 21:50:02 +02:00
|
|
|
// -- Remarkup -------------------------------------------------------------- //
|
|
|
|
|
2011-05-29 19:20:24 +02:00
|
|
|
// If you enable this, linked YouTube videos will be embeded inline. This has
|
|
|
|
// mild security implications (you'll leak referrers to YouTube) and is pretty
|
|
|
|
// silly (but sort of awesome).
|
2011-05-27 21:50:02 +02:00
|
|
|
'remarkup.enable-embedded-youtube' => false,
|
|
|
|
|
2011-07-03 18:47:31 +02:00
|
|
|
|
|
|
|
// -- Garbage Collection ---------------------------------------------------- //
|
|
|
|
|
|
|
|
// Phabricator generates various logs and caches in the database which can
|
|
|
|
// be garbage collected after a while to make the total data size more
|
|
|
|
// manageable. To run garbage collection, launch a
|
|
|
|
// PhabricatorGarbageCollector daemon.
|
|
|
|
|
|
|
|
// Since the GC daemon can issue large writes and table scans, you may want to
|
|
|
|
// run it only during off hours or make sure it is scheduled so it doesn't
|
|
|
|
// overlap with backups. This determines when the daemon can start running
|
|
|
|
// each day.
|
|
|
|
'gcdaemon.run-at' => '12 AM',
|
|
|
|
|
|
|
|
// How many seconds after 'gcdaemon.run-at' the daemon may collect garbage
|
|
|
|
// for. By default it runs continuously, but you can set it to run for a
|
|
|
|
// limited period of time. For instance, if you do backups at 3 AM, you might
|
|
|
|
// run garbage collection for an hour beforehand. This is not a high-precision
|
|
|
|
// limit so you may want to leave some room for the GC to actually stop, and
|
|
|
|
// if you set it to something like 3 seconds you're on your own.
|
|
|
|
'gcdaemon.run-for' => 24 * 60 * 60,
|
|
|
|
|
|
|
|
// These 'ttl' keys configure how much old data the GC daemon keeps around.
|
|
|
|
// Objects older than the ttl will be collected. Set any value to 0 to store
|
|
|
|
// data indefinitely.
|
|
|
|
|
|
|
|
'gcdaemon.ttl.herald-transcripts' => 30 * (24 * 60 * 60),
|
|
|
|
'gcdaemon.ttl.daemon-logs' => 7 * (24 * 60 * 60),
|
2011-07-09 00:26:33 +02:00
|
|
|
'gcdaemon.ttl.differential-parse-cache' => 14 * (24 * 60 * 60),
|
2012-07-11 20:40:18 +02:00
|
|
|
'gcdaemon.ttl.markup-cache' => 30 * (24 * 60 * 60),
|
2012-10-31 23:22:16 +01:00
|
|
|
'gcdaemon.ttl.task-archive' => 14 * (24 * 60 * 60),
|
2011-07-03 18:47:31 +02:00
|
|
|
|
|
|
|
|
2011-07-10 03:03:59 +02:00
|
|
|
// -- Feed ------------------------------------------------------------------ //
|
|
|
|
|
|
|
|
// If you set this to true, you can embed Phabricator activity feeds in other
|
|
|
|
// pages using iframes. These feeds are completely public, and a login is not
|
|
|
|
// required to view them! This is intended for things like open source
|
|
|
|
// projects that want to expose an activity feed on the project homepage.
|
2012-07-03 00:41:19 +02:00
|
|
|
//
|
|
|
|
// NOTE: You must also set `policy.allow-public` to true for this setting
|
|
|
|
// to work properly.
|
2011-07-10 03:03:59 +02:00
|
|
|
'feed.public' => false,
|
|
|
|
|
2012-11-02 21:34:18 +01:00
|
|
|
// If you set this to a list of http URIs, when a feed story is published a
|
|
|
|
// task will be created for each uri that posts the story data to the uri.
|
|
|
|
// Daemons automagically retry failures 100 times, waiting $fail_count * 60s
|
|
|
|
// between each subsequent failure. Be sure to keep the daemon console
|
|
|
|
// (/daemon/) open while developing and testing your end points.
|
|
|
|
//
|
|
|
|
// NOTE: URIs are not validated, the URI must return http status 200 within
|
|
|
|
// 30 seconds, and no permission checks are performed.
|
|
|
|
'feed.http-hooks' => array(),
|
Drydock Rough Cut
Summary:
Rough cut of Drydock. This is very basic and doesn't do much of use yet (it
//does// allocate EC2 machines as host resources and expose interfaces to them),
but I think the overall structure is more or less reasonable.
== Interfaces
Vision: Applications interact with Drydock resources through DrydockInterfaces,
like **command**, **filesystem** and **httpd** interfaces. Each interface allows
applications to perform some kind of operation on the resource, like executing
commands, reading/writing files, or configuring a web server. Interfaces have a
concrete, specific API:
// Filesystem Interface
$fs = $lease->getInterface('filesystem'); // Constants, some day?
$fs->writeFile('index.html', 'hello world!');
// Command Interface
$cmd = $lease->getInterface('command');
echo $cmd->execx('uptime');
// HTTPD Interface
$httpd = $lease->getInterface('httpd');
$httpd->restart();
Interfaces are mostly just stock, although installs might add new interfaces if
they expose different ways to interact with resources (for instance, a resource
might want to expose a new 'MongoDB' interface or whatever).
Currently: We have like part of a command interface.
== Leases
Vision: Leases keep track of which resources are in use, and what they're being
used for. They allow us to know when we need to allocate more resources (too
many sandcastles on the existing hosts, e.g.) and when we can release resources
(because they are no longer being used). They also give applications something
to hold while resources are being allocated.
// EXAMPLE: How this should work some day.
$allocator = new DrydockAllocator();
$allocator->setResourceType('sandcastle');
$allocator->setAttributes(
array(
'diffID' => $diff->getID(),
));
$lease = $allocator->allocate();
$diff->setSandcastleLeaseID($lease->getID());
// ...
if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) {
$sandcastle_link = $lease->getInterface('httpd')->getURI('/');
} else {
$sandcastle_link = 'Still building your sandcastle...';
}
echo "Sandcastle for this diff: ".$sandcastle_link;
// EXAMPLE: How this actually works now.
$allocator = new DrydockAllocator();
$allocator->setResourceType('host');
// NOTE: Allocation is currently synchronous but will be task-driven soon.
$lease = $allocator->allocate();
Leases are completely stock, installs will not define new lease types.
Currently: Leases exist and work but are very very basic.
== Resources
Vision: Resources represent some actual thing we've put somewhere, whether it's
a host, a block of storage, a webroot, or whatever else. Applications interact
through resources by acquiring leases to them, and then getting interfaces
through these leases. The lease acquisition process has a side effect of
allocating new resources if a lease can't be acquired on existing resources
(e.g., the application wants storage but all storage resources are full) and
things are configured to autoscale.
Resources may themselves acquire leases in order to allocate. For instance, a
storage resource might first acquire a lease to a host resource. A 'test
scaffold' resource might lease a storage resource and a mysql resource.
Not all resources are auto-allocate: the entry-level version of Drydock is that
you manually allocate a couple boxes and configure them through the web console.
Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the
host pool itself does not autoscale.
Resources are completely stock, they are abstract shells representing any
arbitrary thing.
Currently: Resource exist ('host' only) but are very very basic.
== Blueprints
Vision: Blueprints contain instructions for building interfaces to, (possibly)
allocating, updating, managing, and destroying a specific type of resource in a
specific location. One way to think of them is that they are scripts for
creating and deleting resources. For example, the LocalHost, RemoteHost and
EC2Host blueprints can all manage 'host' resources.
Eventually, we will support more types of resources (storage, webroot,
sandcastle, test scaffold, phacility deployment) and more providers for resource
types, some of which will be in the Phabricator mainline and some of which will
be custom.
Blueprints are very custom and specific to application types, so installs will
define new blueprints if they are making significant use of Drydock.
Currently: They exist but have few capabilities. The stock blueprints do nearly
nothing useful. There is a technically functional blueprint for host allocation
in EC2.
== Allocator
This is just the actual code to execute the lease acquisition process.
Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2,
acquired a lease on it, interfaced with it, and then released the lease. Ran it
again, got a fresh lease on the existing resource.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
|
|
|
|
|
|
|
// -- Drydock --------------------------------------------------------------- //
|
|
|
|
|
2012-11-07 00:30:11 +01:00
|
|
|
// Drydock is used to allocate various software resources. For example, it
|
|
|
|
// allocates working copies so continuous integration tests can be executed.
|
|
|
|
// It needs at least one host to allocate these resources on.
|
|
|
|
//
|
|
|
|
// Set this option to true to let Drydock use the localhost for allocations.
|
|
|
|
// This is the simplest configuration, but the least scalable. You MUST
|
|
|
|
// disable this if you run daemons on more than one machine -- if you do not,
|
|
|
|
// a daemon on machine A may allocate a resource locally, and then a daemon
|
|
|
|
// on machine B may try to access it.
|
|
|
|
'drydock.localhost.enabled' => true,
|
|
|
|
|
|
|
|
// If the localhost is available to Drydock, specify the path on disk where
|
|
|
|
// Drydock should write files. You should create this directory and make sure
|
|
|
|
// the user that the daemons run as has permission to write to it.
|
|
|
|
'drydock.localhost.path' => '/var/drydock/',
|
|
|
|
|
Drydock Rough Cut
Summary:
Rough cut of Drydock. This is very basic and doesn't do much of use yet (it
//does// allocate EC2 machines as host resources and expose interfaces to them),
but I think the overall structure is more or less reasonable.
== Interfaces
Vision: Applications interact with Drydock resources through DrydockInterfaces,
like **command**, **filesystem** and **httpd** interfaces. Each interface allows
applications to perform some kind of operation on the resource, like executing
commands, reading/writing files, or configuring a web server. Interfaces have a
concrete, specific API:
// Filesystem Interface
$fs = $lease->getInterface('filesystem'); // Constants, some day?
$fs->writeFile('index.html', 'hello world!');
// Command Interface
$cmd = $lease->getInterface('command');
echo $cmd->execx('uptime');
// HTTPD Interface
$httpd = $lease->getInterface('httpd');
$httpd->restart();
Interfaces are mostly just stock, although installs might add new interfaces if
they expose different ways to interact with resources (for instance, a resource
might want to expose a new 'MongoDB' interface or whatever).
Currently: We have like part of a command interface.
== Leases
Vision: Leases keep track of which resources are in use, and what they're being
used for. They allow us to know when we need to allocate more resources (too
many sandcastles on the existing hosts, e.g.) and when we can release resources
(because they are no longer being used). They also give applications something
to hold while resources are being allocated.
// EXAMPLE: How this should work some day.
$allocator = new DrydockAllocator();
$allocator->setResourceType('sandcastle');
$allocator->setAttributes(
array(
'diffID' => $diff->getID(),
));
$lease = $allocator->allocate();
$diff->setSandcastleLeaseID($lease->getID());
// ...
if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) {
$sandcastle_link = $lease->getInterface('httpd')->getURI('/');
} else {
$sandcastle_link = 'Still building your sandcastle...';
}
echo "Sandcastle for this diff: ".$sandcastle_link;
// EXAMPLE: How this actually works now.
$allocator = new DrydockAllocator();
$allocator->setResourceType('host');
// NOTE: Allocation is currently synchronous but will be task-driven soon.
$lease = $allocator->allocate();
Leases are completely stock, installs will not define new lease types.
Currently: Leases exist and work but are very very basic.
== Resources
Vision: Resources represent some actual thing we've put somewhere, whether it's
a host, a block of storage, a webroot, or whatever else. Applications interact
through resources by acquiring leases to them, and then getting interfaces
through these leases. The lease acquisition process has a side effect of
allocating new resources if a lease can't be acquired on existing resources
(e.g., the application wants storage but all storage resources are full) and
things are configured to autoscale.
Resources may themselves acquire leases in order to allocate. For instance, a
storage resource might first acquire a lease to a host resource. A 'test
scaffold' resource might lease a storage resource and a mysql resource.
Not all resources are auto-allocate: the entry-level version of Drydock is that
you manually allocate a couple boxes and configure them through the web console.
Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the
host pool itself does not autoscale.
Resources are completely stock, they are abstract shells representing any
arbitrary thing.
Currently: Resource exist ('host' only) but are very very basic.
== Blueprints
Vision: Blueprints contain instructions for building interfaces to, (possibly)
allocating, updating, managing, and destroying a specific type of resource in a
specific location. One way to think of them is that they are scripts for
creating and deleting resources. For example, the LocalHost, RemoteHost and
EC2Host blueprints can all manage 'host' resources.
Eventually, we will support more types of resources (storage, webroot,
sandcastle, test scaffold, phacility deployment) and more providers for resource
types, some of which will be in the Phabricator mainline and some of which will
be custom.
Blueprints are very custom and specific to application types, so installs will
define new blueprints if they are making significant use of Drydock.
Currently: They exist but have few capabilities. The stock blueprints do nearly
nothing useful. There is a technically functional blueprint for host allocation
in EC2.
== Allocator
This is just the actual code to execute the lease acquisition process.
Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2,
acquired a lease on it, interfaced with it, and then released the lease. Ran it
again, got a fresh lease on the existing resource.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
|
|
|
// If you want to use Drydock's builtin EC2 Blueprints, configure your AWS
|
|
|
|
// EC2 credentials here.
|
|
|
|
'amazon-ec2.access-key' => null,
|
|
|
|
'amazon-ec2.secret-key' => null,
|
|
|
|
|
2012-07-03 00:41:19 +02:00
|
|
|
|
2011-02-24 23:52:57 +01:00
|
|
|
// -- Customization --------------------------------------------------------- //
|
|
|
|
|
|
|
|
// Paths to additional phutil libraries to load.
|
|
|
|
'load-libraries' => array(),
|
|
|
|
|
|
|
|
'aphront.default-application-configuration-class' =>
|
|
|
|
'AphrontDefaultApplicationConfiguration',
|
2011-02-28 04:47:22 +01:00
|
|
|
|
|
|
|
'controller.oauth-registration' =>
|
|
|
|
'PhabricatorOAuthDefaultRegistrationController',
|
2011-03-08 02:25:47 +01:00
|
|
|
|
2011-03-14 20:33:20 +01:00
|
|
|
|
|
|
|
// Directory that phd (the Phabricator daemon control script) should use to
|
|
|
|
// track running daemons.
|
2012-08-04 10:27:57 +02:00
|
|
|
'phd.pid-directory' => '/var/tmp/phd/pid',
|
|
|
|
|
|
|
|
// Directory that the Phabricator daemons should use to store the log file
|
|
|
|
'phd.log-directory' => '/var/tmp/phd/log',
|
2011-03-14 20:33:20 +01:00
|
|
|
|
2012-05-09 19:29:37 +02:00
|
|
|
// Number of "TaskMaster" daemons that "phd start" should start. You can
|
|
|
|
// raise this if you have a task backlog, or explicitly launch more with
|
|
|
|
// "phd launch <N> taskmaster".
|
|
|
|
'phd.start-taskmasters' => 4,
|
|
|
|
|
2012-06-19 21:56:41 +02:00
|
|
|
// Launch daemons in "verbose" mode by default. This creates a lot of output,
|
|
|
|
// but can help debug issues. Daemons launched in debug mode with "phd debug"
|
|
|
|
// are always launched in verbose mode. See also 'phd.trace'.
|
|
|
|
'phd.verbose' => false,
|
|
|
|
|
|
|
|
// Launch daemons in "trace" mode by default. This creates an ENORMOUS amount
|
|
|
|
// of output, but can help debug issues. Daemons launched in debug mode with
|
|
|
|
// "phd debug" are always launched in trace mdoe. See also 'phd.verbose'.
|
|
|
|
'phd.trace' => false,
|
|
|
|
|
2012-06-09 02:22:40 +02:00
|
|
|
// Path to custom celerity resource map relative to 'phabricator/src'.
|
|
|
|
// See also `scripts/celerity_mapper.php`.
|
2012-06-06 17:15:42 +02:00
|
|
|
'celerity.resource-path' => '__celerity_resource_map__.php',
|
2012-06-01 01:04:10 +02:00
|
|
|
|
2011-05-09 10:10:40 +02:00
|
|
|
// This value is an input to the hash function when building resource hashes.
|
|
|
|
// It has no security value, but if you accidentally poison user caches (by
|
|
|
|
// pushing a bad patch or having something go wrong with a CDN, e.g.) you can
|
|
|
|
// change this to something else and rebuild the Celerity map to break user
|
|
|
|
// caches. Unless you are doing Celerity development, it is exceptionally
|
|
|
|
// unlikely that you need to modify this.
|
|
|
|
'celerity.resource-hash' => 'd9455ea150622ee044f7931dabfa52aa',
|
|
|
|
|
2011-05-11 12:42:02 +02:00
|
|
|
// In a development environment, it is desirable to force static resources
|
|
|
|
// (CSS and JS) to be read from disk on every request, so that edits to them
|
|
|
|
// appear when you reload the page even if you haven't updated the resource
|
|
|
|
// maps. This setting ensures requests will be verified against the state on
|
|
|
|
// disk. Generally, you should leave this off in production (caching behavior
|
|
|
|
// and performance improve with it off) but turn it on in development. (These
|
|
|
|
// settings are the defaults.)
|
|
|
|
'celerity.force-disk-reads' => false,
|
|
|
|
|
2012-03-28 19:13:53 +02:00
|
|
|
// Minify static resources by removing whitespace and comments. You should
|
|
|
|
// enable this in production, but disable it in development.
|
|
|
|
'celerity.minify' => false,
|
|
|
|
|
2011-08-31 22:25:13 +02:00
|
|
|
// You can respond to various application events by installing listeners,
|
|
|
|
// which will receive callbacks when interesting things occur. Specify a list
|
|
|
|
// of classes which extend PhabricatorEventListener here.
|
|
|
|
'events.listeners' => array(),
|
|
|
|
|
2012-06-27 04:06:53 +02:00
|
|
|
// -- Syntax Highlighting --------------------------------------------------- //
|
2011-08-31 22:25:13 +02:00
|
|
|
|
2012-06-27 04:06:53 +02:00
|
|
|
// Phabricator can highlight PHP by default and use Pygments for other
|
|
|
|
// languages if enabled. You can provide a custom highlighter engine by
|
|
|
|
// extending class PhutilSyntaxHighlighterEngine.
|
|
|
|
'syntax-highlighter.engine' => 'PhutilDefaultSyntaxHighlighterEngine',
|
|
|
|
|
|
|
|
// If you want syntax highlighting for other languages than PHP then you can
|
|
|
|
// install the python package 'Pygments', make sure the 'pygmentize' script is
|
|
|
|
// available in the $PATH of the webserver, and then enable this.
|
2011-07-04 00:29:58 +02:00
|
|
|
'pygments.enabled' => false,
|
|
|
|
|
|
|
|
// In places that we display a dropdown to syntax-highlight code,
|
|
|
|
// this is where that list is defined.
|
|
|
|
// Syntax is 'lexer-name' => 'Display Name',
|
|
|
|
'pygments.dropdown-choices' => array(
|
|
|
|
'apacheconf' => 'Apache Configuration',
|
|
|
|
'bash' => 'Bash Scripting',
|
|
|
|
'brainfuck' => 'Brainf*ck',
|
|
|
|
'c' => 'C',
|
|
|
|
'cpp' => 'C++',
|
|
|
|
'css' => 'CSS',
|
2012-09-18 02:42:52 +02:00
|
|
|
'd' => 'D',
|
2011-07-04 00:29:58 +02:00
|
|
|
'diff' => 'Diff',
|
|
|
|
'django' => 'Django Templating',
|
|
|
|
'erb' => 'Embedded Ruby/ERB',
|
|
|
|
'erlang' => 'Erlang',
|
2012-09-18 00:26:03 +02:00
|
|
|
'haskell' => 'Haskell',
|
2011-07-04 00:29:58 +02:00
|
|
|
'html' => 'HTML',
|
|
|
|
'java' => 'Java',
|
|
|
|
'js' => 'Javascript',
|
|
|
|
'mysql' => 'MySQL',
|
2012-09-18 00:26:03 +02:00
|
|
|
'objc' => 'Objective-C',
|
2011-07-04 00:29:58 +02:00
|
|
|
'perl' => 'Perl',
|
|
|
|
'php' => 'PHP',
|
2012-09-18 05:43:36 +02:00
|
|
|
'rest' => 'reStructuredText',
|
2011-07-04 00:29:58 +02:00
|
|
|
'text' => 'Plain Text',
|
|
|
|
'python' => 'Python',
|
2011-08-02 19:32:59 +02:00
|
|
|
'rainbow' => 'Rainbow',
|
|
|
|
'remarkup' => 'Remarkup',
|
2011-07-04 00:29:58 +02:00
|
|
|
'ruby' => 'Ruby',
|
|
|
|
'xml' => 'XML',
|
|
|
|
),
|
|
|
|
|
2011-07-06 21:12:17 +02:00
|
|
|
// This is an override list of regular expressions which allows you to choose
|
|
|
|
// what language files are highlighted as. If your projects have certain rules
|
|
|
|
// about filenames or use unusual or ambiguous language extensions, you can
|
|
|
|
// create a mapping here. This is an ordered dictionary of regular expressions
|
|
|
|
// which will be tested against the filename. They should map to either an
|
|
|
|
// explicit language as a string value, or a numeric index into the captured
|
|
|
|
// groups as an integer.
|
|
|
|
'syntax.filemap' => array(
|
|
|
|
// Example: Treat all '*.xyz' files as PHP.
|
|
|
|
// '@\\.xyz$@' => 'php',
|
|
|
|
|
|
|
|
// Example: Treat 'httpd.conf' as 'apacheconf'.
|
|
|
|
// '@/httpd\\.conf$@' => 'apacheconf',
|
|
|
|
|
|
|
|
// Example: Treat all '*.x.bak' file as '.x'. NOTE: we map to capturing
|
|
|
|
// group 1 by specifying the mapping as "1".
|
|
|
|
// '@\\.([^.]+)\\.bak$@' => 1,
|
2011-12-24 07:22:04 +01:00
|
|
|
|
|
|
|
'@\.arcconfig$@' => 'js',
|
2012-07-17 03:36:24 +02:00
|
|
|
'@\.divinerconfig$@' => 'js',
|
2011-07-06 21:12:17 +02:00
|
|
|
),
|
|
|
|
|
2012-07-07 00:39:43 +02:00
|
|
|
// Set the default monospaced font style for users who haven't set a custom
|
|
|
|
// style.
|
|
|
|
'style.monospace' => '10px "Menlo", "Consolas", "Monaco", monospace',
|
|
|
|
|
|
|
|
|
2012-07-17 21:06:25 +02:00
|
|
|
// -- Debugging ------------------------------------------------------------- //
|
|
|
|
|
|
|
|
// Enable this to change HTTP redirects into normal pages with a link to the
|
|
|
|
// redirection target. For example, after you submit a form you'll get a page
|
|
|
|
// saying "normally, you'd be redirected...". This is useful to examine
|
|
|
|
// service or profiler information on write pathways, or debug redirects. It
|
|
|
|
// also makes the UX horrible for normal use, so you should enable it only
|
|
|
|
// when debugging.
|
|
|
|
//
|
|
|
|
// NOTE: This does not currently work for forms with Javascript "workflow",
|
|
|
|
// since the redirect happens in Javascript.
|
|
|
|
'debug.stop-on-redirect' => false,
|
|
|
|
|
2012-08-25 00:14:38 +02:00
|
|
|
// Set the rate for how often to do sampled profiling. On average, one
|
|
|
|
// request for every number of requests specified here will be sampled.
|
|
|
|
// Set this value to 0 to completely disable profiling. In a production
|
|
|
|
// environment, this value should either be set to 0 (to disable) or to
|
|
|
|
// a large number (to sample only a few requests).
|
|
|
|
'debug.profile-rate' => 0,
|
2012-07-17 21:06:25 +02:00
|
|
|
|
2012-07-25 20:51:27 +02:00
|
|
|
|
|
|
|
// -- Previews ------------------------------------------------------------- //
|
|
|
|
|
|
|
|
// Turn on to enable the "viewport" meta tag. This is a preview feature which
|
|
|
|
// will improve the usability of Phabricator on phones and tablets once it
|
|
|
|
// is ready.
|
|
|
|
'preview.viewport-meta-tag' => false,
|
|
|
|
|
2012-07-27 23:30:16 +02:00
|
|
|
// -- Environment ---------------------------------------------------------- //
|
|
|
|
|
|
|
|
// Phabricator occasionally shells out to other binaries on the server.
|
|
|
|
// An example of this is the "pygmentize" command, used to syntax-highlight
|
|
|
|
// code written in languages other than PHP. By default, it is assumed that
|
|
|
|
// these binaries are in the $PATH of the user running Phabricator (normally
|
|
|
|
// 'apache', 'httpd', or 'nobody'). Here you can add extra directories to
|
|
|
|
// the $PATH environment variable, for when these binaries are in non-standard
|
|
|
|
// locations.
|
|
|
|
'environment.append-paths' => array(),
|
2011-01-31 20:55:26 +01:00
|
|
|
);
|