Like the recent change blocking JSON endpoints for deactivated users
and users in deactivated realms, this change is a hardening
improvement. Those users should be unable to get an active session
anyway, but if somehow one is leaked, this means they won't be able to
access any user data.
While in theory users should be unable to get a valid session in order
to access these endpoints in the first place, this provides an extra
layer of hardering to prevent a deactivated user with a session from
accessing data via the old-style JSON API.
In a deactivated realm, webhooks would still successfully send
messages, since there was no check for whether the realm was active in
api_key_only_webhook_view.
We were incorrectly applying the rate limiting rules to webhooks even
if rate limiting was disabled (as in the test suite), causing test
failures when the total number of webhook tests in Zulip got too high.
As documented in https://github.com/zulip/zulip/issues/441, Guardian
has quite poor performance, and in fact almost 50% of the time spent
running the Zulip backend test suite on my laptop was inside Guardian.
As part of this migration, we also clean up the old API_SUPER_USERS
variable used to mark EMAIL_GATEWAY_BOT as an API super user; now that
permission is managed entirely via the database.
When rebasing past this commit, developers will need to do a
`manage.py migrate` in order to apply the migration changes before the
server will run again.
We can't yet remove Guardian from INSTALLED_APPS, requirements.txt,
etc. in this release, because otherwise the reverse migration won't
work.
Fixes#441.
We were expecting Github to send us the string "true" when the exclude_* options
were set. However, we were actually getting "1" when an option was set and the
empty string when unset. So we were always setting the options to False.
(imported from commit 067ba60b0b0404aebc6eda9487b1201fc2764243)
All usages of json_to_dict were replaced with the check_dict
validator. The check_dict validations can eventually be
extended to validate the keys and values of incoming data,
but now we just use check_dict([]) in all the places where
we had json_to_dict, which means we aren't checking for any
specific keys; we are just making sure it's a dictionary.
(imported from commit fc5add9a7ef149dfac2a9a6d9a153799c4c0c24d)
Refactor github webhook to handle multiple payload verions
split github fixtures into v1 and v2 versions
Group together all realm-specific logic. When v2 becomes available, we can
ask someone in each org to make the changes via the Github Hook configuration, and
slowly remove the special cases.
TODO: when our pull request for github-services gets merged, the integrations page
should say to look for Zulip instead of Humbug
(imported from commit 4790a730010b37186640f9996291afa6e8f96c2b)
Avoid repeating request.client = get_client(foo) 5 times, and
decouple the logic for determining the client name from how
we represent the client as an ORM object and piggyback it on the
Django request.
(imported from commit efdf81cbaf9599a5606da18e06d7ffe9b88aaf6f)
The "else" branch used to execute when it was not the case
case that HTTP_USER_AGENT was not in request.META. Now
it's more readable.
(imported from commit ea0664e89d8b3d94cd1c0f8667047461b149ba41)
Validators are similar to converters, but they don't have
to parse JSON, and they are told the name of the request
variable to help format error messages.
(imported from commit 3c33e301892519c67e70675006d5686d9f013353)
All of our other API arguments use "_" as the delimiter, so we're
migrating this to do that as well (except for the legacy send_message
usage, which we're just hoping will eventually shrink to nothing).
(imported from commit 40964cc08e0f94ba439a61e4f68ed500f74a554f)
Now that we've debugged the memory leak, I don't think we need this
anymore.
This reverts commit 1bdc7ee2f72bdebb1cdc94601247834a434614d6.
Conflicts:
puppet/zulip/files/cron.d/rabbitmq-numconsumers
puppet/zulip/files/supervisor/conf.d/zulip.conf
(imported from commit ff87f2aebcbc71013fa7a05aedb24e2dcad82ae6)
One quirk here is that the Request object is built in the
message_sender worker, not Tornado. This means that the request time
only counts time taken for the actual sending and does not account
for socket overhead. For this reason, I've left the fake logging in
for now so we can compare the two times.
(imported from commit b0c60a3017527a328cadf11ba68166e59cf23ddf)