From 510b96046aa681f01bb6a07f77042cbf08bbb6d5 Mon Sep 17 00:00:00 2001 From: Alex Vandiver Date: Mon, 1 May 2023 12:14:03 -0400 Subject: [PATCH] docs: Update production docs for local S3 caching. --- docs/production/requirements.md | 5 +++-- docs/production/security-model.md | 23 +++++------------------ docs/subsystems/performance.md | 12 +++--------- docs/tutorials/life-of-a-request.md | 3 +-- 4 files changed, 12 insertions(+), 31 deletions(-) diff --git a/docs/production/requirements.md b/docs/production/requirements.md index 4506ab79b1..9fcaf19d5d 100644 --- a/docs/production/requirements.md +++ b/docs/production/requirements.md @@ -202,8 +202,9 @@ installing Zulip with a dedicated database server. - **Disk for application server:** We recommend using [the S3 file uploads backend][s3-uploads] to store uploaded files at scale. With the S3 backend configuration, we recommend 50 GB of disk for the OS, - Zulip software, logs and scratch/free space. Disk needs when - storing uploads locally + Zulip software, logs and scratch/free space. Because uploaded files + are cached locally, you may need more disk space if you make heavy + use of uploaded files. - **Disk for database:** SSD disk is highly recommended. For installations where most messages have <100 recipients, 10 GB per 1M diff --git a/docs/production/security-model.md b/docs/production/security-model.md index 170da1e89b..0778ba6d6a 100644 --- a/docs/production/security-model.md +++ b/docs/production/security-model.md @@ -219,25 +219,12 @@ strength allowed is controlled by two settings in file to be accessed by the unauthorized user. Of course, any such authorized user could have just downloaded and sent the file instead of the URL, so this is arguably pretty good protection.) - However, to help protect against accidental - sharing of URLs to restricted files (e.g. by forwarding a - missed-message email or leaks involving the Referer header), we - provide additional layers of protection in both backends as well. - In the Zulip S3 backend, the random URLs to access files that are - presented to users don't actually host the content. Instead, the S3 - backend verifies that the user has a valid Zulip session in the - relevant organization (and that has access to a Zulip message linking to - the file), and if so, then redirects the browser to a temporary S3 - URL for the file that expires a short time later. In this way, - possessing a URL to a secret file in Zulip does not provide - unauthorized users with access to that file. - - We have a similar protection for the `LOCAL_UPLOADS_DIR` backend. - Every access - to an uploaded file has access control verified (confirming that the - browser is logged into a Zulip account that has received the - uploaded file in question). + However, to help protect against accidental sharing of URLs to + restricted files (e.g. by forwarding a missed-message email or leaks + involving the Referer header), every access to an uploaded file has + access control verified (confirming that the browser is logged into + a Zulip account that has received the uploaded file in question). - Zulip supports using the [go-camo][go-camo] image proxy to proxy content like inline image previews, that can be inserted into the Zulip message feed by diff --git a/docs/subsystems/performance.md b/docs/subsystems/performance.md index 0a58efb330..2691f9faab 100644 --- a/docs/subsystems/performance.md +++ b/docs/subsystems/performance.md @@ -283,15 +283,9 @@ scalability cost of fetching message history dramatically. Requests to fetch uploaded files (including user avatars) account for about 5% of total HTTP requests. Zulip spends consistently ~10-15ms processing one of these requests (mostly authorization logic), before -handing off delivery of the file to `nginx` or S3 (depending on the -configured [upload backend](../production/upload-backends.md)). - -We can significantly reduce the volume of these requests in large -production Zulip servers by fixing [Zulip's upload authorization -strategy preventing browser caching of -uploads](https://github.com/zulip/zulip/issues/13088), since many of -them result from a single client downloading the same file repeatedly -as it navigates around the app. +handing off delivery of the file to `nginx` (which may itself fetch +from S3, depending on the configured [upload +backend](../production/upload-backends.md)). ### Sending and editing messages diff --git a/docs/tutorials/life-of-a-request.md b/docs/tutorials/life-of-a-request.md index 81f79d4087..fecc8a7687 100644 --- a/docs/tutorials/life-of-a-request.md +++ b/docs/tutorials/life-of-a-request.md @@ -22,8 +22,7 @@ are in your Git checkout under `static`, and are served unminified. [served-directly]: https://github.com/zulip/zulip/blob/main/puppet/zulip/files/nginx/zulip-include-frontend/app -Static files include JavaScript, css, static assets (like emoji, avatars), -and user uploads (if stored locally and not on S3). +Static files include JavaScript, CSS, and static assets (like emoji, avatars). File not found errors (404) are served using a Django URL, so that we can use configuration variables (like whether the user is logged in)