This allows users to drag and drop content onto the compose box, storing
their data in Amazon S3.
New dependencies:
- python-boto
(imported from commit 339874e483db5c36312c9ceae56db29da6ca0d99)
This creates a new management command, subscribe_new_users, which should be
run as a daemon process. When new users are created, an event is passed to
RabbitMQ including the following data:
* Email
* Full name
* IP address of the person who confirmed registration
* Time of registration confirmation
MailChimp strongly encourages the collection of the last two to enable
responses to abuse requests, and providing more data lowers the chance that
we could get banned from their service if complaints do occur.
To use this commit, you need to install the "postmonkey" module from
PyPI.
(imported from commit 20c628c3fa8bb985aaead85a80ad3b38bf94b9dc)
...rather than embedding them into index.html.
This is only acceptable for dev, but the next commit adds an alternative
mechanism for prod.
There isn't actually a manual deployment step here. However, this commit won't
work on staging / prod without the next one (since we don't serve
zephyr/static/templates in prod).
(imported from commit dce7ddfe89e07afc3a96699bb972fd124335aa05)
Apparently, something in Django 1.5's changes to their default logging
setup resulted in the logger 500 errors (logged in
django.core.handlers.base.handle_uncaught_exception) from reaching the
root logger -- they stopped at propagating at the 'django' logger. We
deal with this by making our logging system handle those events in the
'django' logger ourselves (and making the related changes needed to
ensure that we still log to server.log and the console everything
logged by our own humbug.requests logger and anything that falls
through to the root logger).
This requires updating the mechanism we use in test_settings.py to
silence our request logging, since now the 'humbug.requests' logger is
being re-initialized by the Django logging setup, which runs after
test_settings.py.
While we're at it, set propagate=False in the commented-out
'django.db' logging configuration (previously, queries would be logged
twice).
(imported from commit 32af29084e52be1ba6f92a7952c3a3946925b46b)
This only does something if DEBUG=False, but it's now required that
you set this on Django 1.5 or the server will silently serve up 500s
for every request (not the best failure mode).
(imported from commit fa226c644770c468d73143c8a49d5d29d282df27)
Now that we can use our servers' DNS names internally, using
verify-full gives us a little bit of extra security.
(imported from commit 3a3715fa8a59851d4543112a55b5c6b24981442e)
This is often useful when working on a local development system and so
seems worth putting in the code, but is so verbose that it probably
doesn't make sense to have on by default in development.
(imported from commit ddb7ae4c83136f96d69368a245ed64e7daf66f34)
This fixes a nondeterministic test failure for me.
The first message sent in the test suite appears to get dropped. I don't know
why this is, and I'm pretty sure it was an existing bug. This message used to
be the one disabling the tutorial, which might explain why that didn't always
work.
Regardless, this commit at least makes the test suite usable, and we can work
on fixing that bug later.
(imported from commit 063e40871b9883e3a6dab93a4e0a51c5b2dae4b7)
We treat these exceptions the same way we treat fatal errors: report
the error message to our server and then allow the exception to reach
the top level.
We could also override document.onerror, but don't. There are a
couple of ramifications of this:
* Exceptions caused by event handlers directly attached to DOM
elements aren't handled
* Exceptions caused by code at the top level that triggers an error
(such as parse errors in our Javascript files) aren't handled
The reason we don't override document.onerror is because the
document.onerror handler has a limited interface and doesn't receive
the exception object. It only gets the message, file, and line
number of the error. Additionally, exceptions that we allow to
propogate out of blueslip trigger an onerror event when they're never
caught. In order to avoid handling the error twice (once by blueslip
and once by the onerror handler), we'd have to encode the fact that
the error has already been handled in the error message, which is
pretty ugly.
(imported from commit 7f049ae519dc198a9f7cfd41fd5dd18e584bd061)
The new system, called blueslip, makes errors fatal when in debug
mode and only output a message when running in production. In the
future, it could also send user errors back to us automatically.
(imported from commit 1232607c0311e885c8b5a5e8a45ffb28822426e0)
This should substantially improve the repeat-rendering time for pages
with large numbers of tweets since we don't need to go all the way to
twitter.com, which can take like a second, to render tweets properly.
To deploy this commit properly, one needs to run
./manage.py createcachetable third_party_api_results
(imported from commit 01b528e61f9dde2ee718bdec0490088907b6017e)
This code adds a dependency on python-django-auth-openid, installable as
django-openid-auth from PyPI.
On prod, one needs to run a syncdb in order to create the required
tables. A database *migration* is not required, as these are new tables
only.
(imported from commit c902a0df8d589d93743b27e480154a04402b2c41)
This commit just moves time rendering logic to its own file, and does
not make any functionality changes.
(imported from commit d111d03c6abc8d9550fcf65e4f89eab8056d1ed4)
Manual deployment steps: The same Nginx reload as for "Get rid of the
static-access-control mechanism". If deploying both commits at once,
just do it once.
(imported from commit dd8dbbf14b95fce0a4b6f66f462fa0a6b50bfb8c)
Django doesn't use this setting, but South consults it when
inspecting tables for their constraints. The fact that we store our
tables in the 'humbug' schema was causing South to fail to find our
table constraints (it was looking in the 'public' schema) and
therefore throw an exception when we try to remove the unique
constraint in migration 0002.
(imported from commit 4230338a7b78329a759339b2f9fcd277137b7f32)
This was to support get_updates sharding, which we never fully
implemented. We can recommit this change later if we choose to bring
the feature back.
This reverts commit fda2d99d9e9a07951d11fcd9fc61cf229988f471.
(imported from commit aec8203c8d8a94dd6f30089aeee22814d1595fc5)
As a side-effect of customizing the e-mail, this also makes the host
on which the error happened a part of the subject line.
(imported from commit 7d5e9ad108b48fd34528512c5955567119935d4e)
We need this so that we can safely expunge old events without interfering with
the running server. See #414.
(imported from commit 4739e59e36ea69f877c158c13ee752bf6a2dacfe)
Before this is deployed, we need to install rabbitmq and pika on the
target server (see the puppet part of this commit for how).
When this is deployed, we need to start the new user activity bot:
./manage.py process_user_activity
in the screen session on the relevant server, or user_activity logs
won't be processed (which will eventually result in all users getting
notifications about how their mirrors are out of date).
(imported from commit 44d605aca0290bef2c94fb99267e15e26b21673b)
This commit has the effect of eliminating all of the non-UserActivity
database queries from the Tornado process -- at least in the uncached
case.
This is safe to do, if a bit fragile, since our Tornado code only
accesses these objects (as opposed to their IDs) in a few places that
are all fine with old data, and I don't expect us to add any new ones
soon:
* UserActivity logging, which I plan to move out of Tornado entirely
* Checking whether we're authenticated in our decorators (which could
be simplified -- the actual security check is just whether the
Django session object has a particular field)
* Checking the user realm for whether we should sync to the client
notices about their Zephyr mirror being up to date, which is quite
static and I think we can move out of this code path.
But implementation constraints around mapping the user_ids to
user_profile_ids mean that it makes sense to get the actual objects
for now.
This code is not what I want to do long-term. I expect we'll be able
to clean up the dual User/UserProfile nonsense once we integrate the
upcoming Django 1.5 release, with its support for pluggable User
models, and after that I change, I expect it'll be fairly easy to make
the Tornado code only work with the user ID, not the actual objects.
(imported from commit 82e25b62fd0e3af7c86040600c63a4deec7bec06)
Luke Faraone
Tim Abbott
Keegan McAllister
Zev Benjamin
Waseem Daher
Reid Barton
Leo Franchi
Jacob Hurwitz
Jessica McKellar