2014-06-14 20:44:19 +02:00
|
|
|
# NOTE: Thinking about adding files created by your operating system, IDE,
|
|
|
|
|
# or text editor here? Don't! Add them to your per-user .gitignore instead.
|
Add a local configuration source and a non-environmental ENV config source
Summary:
See discussion in T2221. Before we can move configuration to the database, we have a bootstrapping problem: we need database credentials to live //somewhere// if we can't guess them (and we can only really guess localhost / root / no password).
Some options for this are:
- Have them live in ENV variables.
- These are often somewhat unfamiliar to users.
- Scripts would become a huge pain -- you'd have to dump a bunch of stuff into ENV.
- Some environments have limited ability to set ENV vars.
- SSH is also a pain.
- Have them live in a normal config file.
- This probably isn't really too awful, but:
- Since we deploy/upgrade with git, we can't currently let them edit a file which already exists, or their working copy will become dirty.
- So they have to copy or create a file, then edit it.
- The biggest issue I have with this is that it will be difficult to give specific, easily-followed directions from Setup. The instructions need to be like "Copy template.conf.php to real.conf.php, then edit these keys: x, y, z". This isn't as easy to follow as "run script Y".
- Have them live in an abnormal config file with script access (this diff).
- I think this is a little better than a normal config file, because we can tell users 'run phabricator/bin/config set mysql.user phabricator' and such, which is easier to follow than editing a config file.
I think this is only a marginal improvement over a normal config file and am open to arguments against this approach, but I think it will be a little easier for users to deal with than a normal config file. In most cases they should only need to store three values in this file -- db user/host/pass -- since once we have those we can bootstrap everything else. Normal config files also aren't going away for more advanced users, we're just offering a simple alternative for most users.
This also adds an ENVIRONMENT file as an alternative to PHABRICATOR_ENV. This is just a simple way to specify the environment if you don't have convenient access to env vars.
Test Plan: Ran `config set x y`, verified writes. Wrote to ENVIRONMENT, ran `PHABRICATOR_ENV= ./bin/repository`.
Reviewers: btrahan, vrana, codeblock
Reviewed By: codeblock
CC: aran
Maniphest Tasks: T2221
Differential Revision: https://secure.phabricator.com/D4294
2012-12-30 15:16:15 +01:00
|
|
|
|
|
|
|
|
# Diviner
|
|
|
|
|
/docs/
|
2014-06-14 20:44:19 +02:00
|
|
|
/.divinercache/
|
2016-07-04 02:40:09 +02:00
|
|
|
/src/.cache/
|
Add a local configuration source and a non-environmental ENV config source
Summary:
See discussion in T2221. Before we can move configuration to the database, we have a bootstrapping problem: we need database credentials to live //somewhere// if we can't guess them (and we can only really guess localhost / root / no password).
Some options for this are:
- Have them live in ENV variables.
- These are often somewhat unfamiliar to users.
- Scripts would become a huge pain -- you'd have to dump a bunch of stuff into ENV.
- Some environments have limited ability to set ENV vars.
- SSH is also a pain.
- Have them live in a normal config file.
- This probably isn't really too awful, but:
- Since we deploy/upgrade with git, we can't currently let them edit a file which already exists, or their working copy will become dirty.
- So they have to copy or create a file, then edit it.
- The biggest issue I have with this is that it will be difficult to give specific, easily-followed directions from Setup. The instructions need to be like "Copy template.conf.php to real.conf.php, then edit these keys: x, y, z". This isn't as easy to follow as "run script Y".
- Have them live in an abnormal config file with script access (this diff).
- I think this is a little better than a normal config file, because we can tell users 'run phabricator/bin/config set mysql.user phabricator' and such, which is easier to follow than editing a config file.
I think this is only a marginal improvement over a normal config file and am open to arguments against this approach, but I think it will be a little easier for users to deal with than a normal config file. In most cases they should only need to store three values in this file -- db user/host/pass -- since once we have those we can bootstrap everything else. Normal config files also aren't going away for more advanced users, we're just offering a simple alternative for most users.
This also adds an ENVIRONMENT file as an alternative to PHABRICATOR_ENV. This is just a simple way to specify the environment if you don't have convenient access to env vars.
Test Plan: Ran `config set x y`, verified writes. Wrote to ENVIRONMENT, ran `PHABRICATOR_ENV= ./bin/repository`.
Reviewers: btrahan, vrana, codeblock
Reviewed By: codeblock
CC: aran
Maniphest Tasks: T2221
Differential Revision: https://secure.phabricator.com/D4294
2012-12-30 15:16:15 +01:00
|
|
|
|
|
|
|
|
# libphutil
|
|
|
|
|
/src/.phutil_module_cache
|
|
|
|
|
|
|
|
|
|
# Configuration
|
|
|
|
|
/conf/custom/*
|
|
|
|
|
/conf/local/local.json
|
|
|
|
|
/conf/local/ENVIRONMENT
|
2013-01-23 21:03:19 +01:00
|
|
|
/conf/local/VERSION
|
2015-01-03 00:13:30 +01:00
|
|
|
/conf/keys/device.pub
|
|
|
|
|
/conf/keys/device.key
|
2015-01-23 01:06:04 +01:00
|
|
|
/conf/keys/device.id
|
2016-04-13 20:03:42 +02:00
|
|
|
/conf/aphlict/aphlict.custom.json
|
2013-02-01 17:19:33 +01:00
|
|
|
|
|
|
|
|
# Impact Font
|
|
|
|
|
/resources/font/impact.ttf
|
2013-03-04 22:45:51 +01:00
|
|
|
|
|
|
|
|
# User-accessible hook for adhoc debugging scripts
|
|
|
|
|
/support/debug.php
|
2013-04-03 21:58:39 +02:00
|
|
|
|
Rate limit requests by IP
Summary:
Fixes T3923. On `secure.phabricator.com`, we occasionally get slowed to a crawl when someone runs a security scanner against us, or 5 search bots decide to simultaneously index every line of every file in Diffusion.
Every time a user makes a request, give their IP address some points. If they get too many points in 5 minutes, start blocking their requests automatically for a while.
We give fewer points for logged in requests. We could futher refine this (more points for a 404, more points for a really slow page, etc.) but let's start simply.
Also, provide a mechanism for configuring this, and configuring the LB environment stuff at the same time (this comes up rarely, but we don't have a good answer right now).
Test Plan: Used `ab` and reloading over and over again to hit rate limits. Read documentation.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: chad, epriestley
Maniphest Tasks: T3923
Differential Revision: https://secure.phabricator.com/D8713
2014-04-09 03:36:21 +02:00
|
|
|
# User-accessible hook for adhoc startup code
|
|
|
|
|
/support/preamble.php
|
|
|
|
|
|
2013-04-03 21:58:39 +02:00
|
|
|
# Users can link binaries here
|
|
|
|
|
/support/bin/*
|
2013-08-15 04:14:23 +02:00
|
|
|
|
|
|
|
|
# User extensions
|
|
|
|
|
/src/extensions/*
|
Rewrite Aphlict to use Websockets
Summary:
Fixes T6559. No more flash, use Websockets. This is less aggressive than the earlier version, and retains more server logic.
- Support "wss".
- Make the client work.
- Remove "notification.user" entirely.
- Seems ok?
Test Plan:
In Safari, Firefox and Chrome, saw the browsers connect. Made a bunch of comments/updates and saw notifications.
Notable holes in the test plan:
- Haven't tested "wss" yet. I'll do this on secure.
- Notifications are //too fast// now, locally. I get them after I hit submit but before the page reloads.
- There are probably some other rough edges, this is a fairly big patch.
Reviewers: joshuaspence, btrahan
Reviewed By: joshuaspence, btrahan
Subscribers: fabe, btrahan, epriestley
Maniphest Tasks: T6713, T6559
Differential Revision: https://secure.phabricator.com/D11143
2015-01-08 19:03:00 +01:00
|
|
|
|
|
|
|
|
# NPM local packages
|
|
|
|
|
/support/aphlict/server/node_modules/
|
2015-10-09 05:23:05 +02:00
|
|
|
|
|
|
|
|
# Places for users to add custom resources.
|
|
|
|
|
/resources/cows/custom/*
|
|
|
|
|
/resources/figlet/custom/*
|
