2021-07-27 18:42:25 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
|
|
|
RSpec.describe ExternalUploadManager do
|
2023-06-21 10:00:19 -04:00
|
|
|
subject(:manager) { ExternalUploadManager.new(external_upload_stub) }
|
|
|
|
|
2023-11-09 17:47:59 -05:00
|
|
|
fab!(:user)
|
2023-06-21 10:00:19 -04:00
|
|
|
|
2021-07-27 18:42:25 -04:00
|
|
|
let!(:logo_file) { file_from_fixtures("logo.png") }
|
|
|
|
let!(:pdf_file) { file_from_fixtures("large.pdf", "pdf") }
|
|
|
|
let(:object_size) { 1.megabyte }
|
|
|
|
let(:etag) { "e696d20564859cbdf77b0f51cbae999a" }
|
|
|
|
let(:client_sha1) { Upload.generate_digest(object_file) }
|
|
|
|
let(:sha1) { Upload.generate_digest(object_file) }
|
|
|
|
let(:object_file) { logo_file }
|
2022-06-20 12:36:05 -04:00
|
|
|
let(:external_upload_stub_metadata) { {} }
|
2021-07-27 18:42:25 -04:00
|
|
|
let!(:external_upload_stub) { Fabricate(:image_external_upload_stub, created_by: user) }
|
2022-06-20 12:36:05 -04:00
|
|
|
let(:s3_bucket_name) { SiteSetting.s3_upload_bucket }
|
2021-07-27 18:42:25 -04:00
|
|
|
|
|
|
|
before do
|
|
|
|
SiteSetting.authorized_extensions += "|pdf"
|
|
|
|
SiteSetting.max_attachment_size_kb = 210.megabytes / 1000
|
|
|
|
|
|
|
|
setup_s3
|
FEATURE: Direct S3 multipart uploads for backups (#14736)
This PR introduces a new `enable_experimental_backup_uploads` site setting (default false and hidden), which when enabled alongside `enable_direct_s3_uploads` will allow for direct S3 multipart uploads of backup .tar.gz files.
To make multipart external uploads work with both the S3BackupStore and the S3Store, I've had to move several methods out of S3Store and into S3Helper, including:
* presigned_url
* create_multipart
* abort_multipart
* complete_multipart
* presign_multipart_part
* list_multipart_parts
Then, S3Store and S3BackupStore either delegate directly to S3Helper or have their own special methods to call S3Helper for these methods. FileStore.temporary_upload_path has also removed its dependence on upload_path, and can now be used interchangeably between the stores. A similar change was made in the frontend as well, moving the multipart related JS code out of ComposerUppyUpload and into a mixin of its own, so it can also be used by UppyUploadMixin.
Some changes to ExternalUploadManager had to be made here as well. The backup direct uploads do not need an Upload record made for them in the database, so they can be moved to their final S3 resting place when completing the multipart upload.
This changeset is not perfect; it introduces some special cases in UploadController to handle backups that was previously in BackupController, because UploadController is where the multipart routes are located. A subsequent pull request will pull these routes into a module or some other sharing pattern, along with hooks, so the backup controller and the upload controller (and any future controllers that may need them) can include these routes in a nicer way.
2021-11-10 17:25:31 -05:00
|
|
|
|
|
|
|
SiteSetting.s3_backup_bucket = "s3-backup-bucket"
|
|
|
|
SiteSetting.backup_location = BackupLocationSiteSetting::S3
|
|
|
|
|
2022-06-20 12:36:05 -04:00
|
|
|
prepare_fake_s3
|
2021-07-27 18:42:25 -04:00
|
|
|
stub_download_object_filehelper
|
|
|
|
end
|
|
|
|
|
FEATURE: Uppy direct S3 multipart uploads in composer (#14051)
This pull request introduces the endpoints required, and the JavaScript functionality in the `ComposerUppyUpload` mixin, for direct S3 multipart uploads. There are four new endpoints in the uploads controller:
* `create-multipart.json` - Creates the multipart upload in S3 along with an `ExternalUploadStub` record, storing information about the file in the same way as `generate-presigned-put.json` does for regular direct S3 uploads
* `batch-presign-multipart-parts.json` - Takes a list of part numbers and the unique identifier for an `ExternalUploadStub` record, and generates the presigned URLs for those parts if the multipart upload still exists and if the user has permission to access that upload
* `complete-multipart.json` - Completes the multipart upload in S3. Needs the full list of part numbers and their associated ETags which are returned when the part is uploaded to the presigned URL above. Only works if the user has permission to access the associated `ExternalUploadStub` record and the multipart upload still exists.
After we confirm the upload is complete in S3, we go through the regular `UploadCreator` flow, the same as `complete-external-upload.json`, and promote the temporary upload S3 into a full `Upload` record, moving it to its final destination.
* `abort-multipart.json` - Aborts the multipart upload on S3 and destroys the `ExternalUploadStub` record if the user has permission to access that upload.
Also added are a few new columns to `ExternalUploadStub`:
* multipart - Whether or not this is a multipart upload
* external_upload_identifier - The "upload ID" for an S3 multipart upload
* filesize - The size of the file when the `create-multipart.json` or `generate-presigned-put.json` is called. This is used for validation.
When the user completes a direct S3 upload, either regular or multipart, we take the `filesize` that was captured when the `ExternalUploadStub` was first created and compare it with the final `Content-Length` size of the file where it is stored in S3. Then, if the two do not match, we throw an error, delete the file on S3, and ban the user from uploading files for N (default 5) minutes. This would only happen if the user uploads a different file than what they first specified, or in the case of multipart uploads uploaded larger chunks than needed. This is done to prevent abuse of S3 storage by bad actors.
Also included in this PR is an update to vendor/uppy.js. This has been built locally from the latest uppy source at https://github.com/transloadit/uppy/commit/d613b849a6591083f8a0968aa8d66537e231bbcd. This must be done so that I can get my multipart upload changes into Discourse. When the Uppy team cuts a proper release, we can bump the package.json versions instead.
2021-08-24 18:46:54 -04:00
|
|
|
describe "#ban_user_from_external_uploads!" do
|
|
|
|
after { Discourse.redis.flushdb }
|
|
|
|
|
|
|
|
it "bans the user from external uploads using a redis key" do
|
|
|
|
ExternalUploadManager.ban_user_from_external_uploads!(user: user)
|
|
|
|
expect(ExternalUploadManager.user_banned?(user)).to eq(true)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2021-07-27 18:42:25 -04:00
|
|
|
describe "#can_promote?" do
|
|
|
|
it "returns false if the external stub status is not created" do
|
|
|
|
external_upload_stub.update!(status: ExternalUploadStub.statuses[:uploaded])
|
2023-06-21 10:00:19 -04:00
|
|
|
expect(manager.can_promote?).to eq(false)
|
2021-07-27 18:42:25 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
FEATURE: Direct S3 multipart uploads for backups (#14736)
This PR introduces a new `enable_experimental_backup_uploads` site setting (default false and hidden), which when enabled alongside `enable_direct_s3_uploads` will allow for direct S3 multipart uploads of backup .tar.gz files.
To make multipart external uploads work with both the S3BackupStore and the S3Store, I've had to move several methods out of S3Store and into S3Helper, including:
* presigned_url
* create_multipart
* abort_multipart
* complete_multipart
* presign_multipart_part
* list_multipart_parts
Then, S3Store and S3BackupStore either delegate directly to S3Helper or have their own special methods to call S3Helper for these methods. FileStore.temporary_upload_path has also removed its dependence on upload_path, and can now be used interchangeably between the stores. A similar change was made in the frontend as well, moving the multipart related JS code out of ComposerUppyUpload and into a mixin of its own, so it can also be used by UppyUploadMixin.
Some changes to ExternalUploadManager had to be made here as well. The backup direct uploads do not need an Upload record made for them in the database, so they can be moved to their final S3 resting place when completing the multipart upload.
This changeset is not perfect; it introduces some special cases in UploadController to handle backups that was previously in BackupController, because UploadController is where the multipart routes are located. A subsequent pull request will pull these routes into a module or some other sharing pattern, along with hooks, so the backup controller and the upload controller (and any future controllers that may need them) can include these routes in a nicer way.
2021-11-10 17:25:31 -05:00
|
|
|
describe "#transform!" do
|
2021-07-27 18:42:25 -04:00
|
|
|
context "when stubbed upload is < DOWNLOAD_LIMIT (small enough to download + generate sha)" do
|
FEATURE: Uppy direct S3 multipart uploads in composer (#14051)
This pull request introduces the endpoints required, and the JavaScript functionality in the `ComposerUppyUpload` mixin, for direct S3 multipart uploads. There are four new endpoints in the uploads controller:
* `create-multipart.json` - Creates the multipart upload in S3 along with an `ExternalUploadStub` record, storing information about the file in the same way as `generate-presigned-put.json` does for regular direct S3 uploads
* `batch-presign-multipart-parts.json` - Takes a list of part numbers and the unique identifier for an `ExternalUploadStub` record, and generates the presigned URLs for those parts if the multipart upload still exists and if the user has permission to access that upload
* `complete-multipart.json` - Completes the multipart upload in S3. Needs the full list of part numbers and their associated ETags which are returned when the part is uploaded to the presigned URL above. Only works if the user has permission to access the associated `ExternalUploadStub` record and the multipart upload still exists.
After we confirm the upload is complete in S3, we go through the regular `UploadCreator` flow, the same as `complete-external-upload.json`, and promote the temporary upload S3 into a full `Upload` record, moving it to its final destination.
* `abort-multipart.json` - Aborts the multipart upload on S3 and destroys the `ExternalUploadStub` record if the user has permission to access that upload.
Also added are a few new columns to `ExternalUploadStub`:
* multipart - Whether or not this is a multipart upload
* external_upload_identifier - The "upload ID" for an S3 multipart upload
* filesize - The size of the file when the `create-multipart.json` or `generate-presigned-put.json` is called. This is used for validation.
When the user completes a direct S3 upload, either regular or multipart, we take the `filesize` that was captured when the `ExternalUploadStub` was first created and compare it with the final `Content-Length` size of the file where it is stored in S3. Then, if the two do not match, we throw an error, delete the file on S3, and ban the user from uploading files for N (default 5) minutes. This would only happen if the user uploads a different file than what they first specified, or in the case of multipart uploads uploaded larger chunks than needed. This is done to prevent abuse of S3 storage by bad actors.
Also included in this PR is an update to vendor/uppy.js. This has been built locally from the latest uppy source at https://github.com/transloadit/uppy/commit/d613b849a6591083f8a0968aa8d66537e231bbcd. This must be done so that I can get my multipart upload changes into Discourse. When the Uppy team cuts a proper release, we can bump the package.json versions instead.
2021-08-24 18:46:54 -04:00
|
|
|
let!(:external_upload_stub) do
|
|
|
|
Fabricate(:image_external_upload_stub, created_by: user, filesize: object_size)
|
2023-01-09 06:18:21 -05:00
|
|
|
end
|
2021-07-27 18:42:25 -04:00
|
|
|
let(:object_size) { 1.megabyte }
|
|
|
|
let(:object_file) { logo_file }
|
|
|
|
|
|
|
|
context "when the download of the s3 file fails" do
|
|
|
|
before { FileHelper.stubs(:download).returns(nil) }
|
|
|
|
|
|
|
|
it "raises an error" do
|
2023-06-21 10:00:19 -04:00
|
|
|
expect { manager.transform! }.to raise_error(ExternalUploadManager::DownloadFailedError)
|
2021-07-27 18:42:25 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context "when the upload is not in the created status" do
|
|
|
|
before { external_upload_stub.update!(status: ExternalUploadStub.statuses[:uploaded]) }
|
2022-06-20 12:36:05 -04:00
|
|
|
|
2021-07-27 18:42:25 -04:00
|
|
|
it "raises an error" do
|
2023-06-21 10:00:19 -04:00
|
|
|
expect { manager.transform! }.to raise_error(ExternalUploadManager::CannotPromoteError)
|
2021-07-27 18:42:25 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context "when the upload does not get changed in UploadCreator (resized etc.)" do
|
|
|
|
it "copies the stubbed upload on S3 to its new destination and deletes it" do
|
2023-06-21 10:00:19 -04:00
|
|
|
upload = manager.transform!
|
2022-06-20 12:36:05 -04:00
|
|
|
|
|
|
|
bucket = @fake_s3.bucket(SiteSetting.s3_upload_bucket)
|
|
|
|
expect(@fake_s3.operation_called?(:copy_object)).to eq(true)
|
|
|
|
expect(bucket.find_object(Discourse.store.get_path_for_upload(upload))).to be_present
|
|
|
|
expect(bucket.find_object(external_upload_stub.key)).to be_nil
|
2021-07-27 18:42:25 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "errors if the image upload is too big" do
|
|
|
|
SiteSetting.max_image_size_kb = 1
|
2023-06-21 10:00:19 -04:00
|
|
|
upload = manager.transform!
|
2021-07-27 18:42:25 -04:00
|
|
|
expect(upload.errors.full_messages).to include(
|
FEATURE: Humanize file size error messages (#14398)
The file size error messages for max_image_size_kb and
max_attachment_size_kb are shown to the user in the KB
format, regardless of how large the limit is. Since we
are going to support uploading much larger files soon,
this KB-based limit soon becomes unfriendly to the end
user.
For example, if the max attachment size is set to 512000
KB, this is what the user sees:
> Sorry, the file you are trying to upload is too big (maximum
size is 512000KB)
This makes the user do math. In almost all file explorers that
a regular user would be familiar width, the file size is shown
in a format based on the maximum increment (e.g. KB, MB, GB).
This commit changes the behaviour to output a humanized file size
instead of the raw KB. For the above example, it would now say:
> Sorry, the file you are trying to upload is too big (maximum
size is 512 MB)
This humanization also handles decimals, e.g. 1536KB = 1.5 MB
2021-09-21 17:59:45 -04:00
|
|
|
"Filesize " +
|
|
|
|
I18n.t(
|
|
|
|
"upload.images.too_large_humanized",
|
|
|
|
max_size:
|
|
|
|
ActiveSupport::NumberHelper.number_to_human_size(
|
|
|
|
SiteSetting.max_image_size_kb.kilobytes,
|
2023-01-09 06:18:21 -05:00
|
|
|
),
|
|
|
|
),
|
2021-07-27 18:42:25 -04:00
|
|
|
)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "errors if the extension is not supported" do
|
|
|
|
SiteSetting.authorized_extensions = ""
|
2023-06-21 10:00:19 -04:00
|
|
|
upload = manager.transform!
|
2021-07-27 18:42:25 -04:00
|
|
|
expect(upload.errors.full_messages).to include(
|
|
|
|
"Original filename " + I18n.t("upload.unauthorized", authorized_extensions: ""),
|
|
|
|
)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context "when the upload does get changed by the UploadCreator" do
|
2022-06-20 12:36:05 -04:00
|
|
|
let(:object_file) { file_from_fixtures("should_be_jpeg.heic", "images") }
|
|
|
|
let(:object_size) { 1.megabyte }
|
|
|
|
let(:external_upload_stub) do
|
|
|
|
Fabricate(
|
|
|
|
:image_external_upload_stub,
|
|
|
|
original_filename: "should_be_jpeg.heic",
|
|
|
|
filesize: object_size,
|
|
|
|
)
|
2023-01-09 06:18:21 -05:00
|
|
|
end
|
2021-07-27 18:42:25 -04:00
|
|
|
|
|
|
|
it "creates a new upload in s3 (not copy) and deletes the original stubbed upload" do
|
2023-06-21 10:00:19 -04:00
|
|
|
upload = manager.transform!
|
2022-06-20 12:36:05 -04:00
|
|
|
|
|
|
|
bucket = @fake_s3.bucket(SiteSetting.s3_upload_bucket)
|
|
|
|
expect(@fake_s3.operation_called?(:copy_object)).to eq(false)
|
|
|
|
expect(bucket.find_object(Discourse.store.get_path_for_upload(upload))).to be_present
|
|
|
|
expect(bucket.find_object(external_upload_stub.key)).to be_nil
|
2021-07-27 18:42:25 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context "when the sha has been set on the s3 object metadata by the clientside JS" do
|
2022-06-20 12:36:05 -04:00
|
|
|
let(:external_upload_stub_metadata) { { "sha1-checksum" => client_sha1 } }
|
2021-07-27 18:42:25 -04:00
|
|
|
|
|
|
|
context "when the downloaded file sha1 does not match the client sha1" do
|
|
|
|
let(:client_sha1) { "blahblah" }
|
|
|
|
|
FEATURE: Uppy direct S3 multipart uploads in composer (#14051)
This pull request introduces the endpoints required, and the JavaScript functionality in the `ComposerUppyUpload` mixin, for direct S3 multipart uploads. There are four new endpoints in the uploads controller:
* `create-multipart.json` - Creates the multipart upload in S3 along with an `ExternalUploadStub` record, storing information about the file in the same way as `generate-presigned-put.json` does for regular direct S3 uploads
* `batch-presign-multipart-parts.json` - Takes a list of part numbers and the unique identifier for an `ExternalUploadStub` record, and generates the presigned URLs for those parts if the multipart upload still exists and if the user has permission to access that upload
* `complete-multipart.json` - Completes the multipart upload in S3. Needs the full list of part numbers and their associated ETags which are returned when the part is uploaded to the presigned URL above. Only works if the user has permission to access the associated `ExternalUploadStub` record and the multipart upload still exists.
After we confirm the upload is complete in S3, we go through the regular `UploadCreator` flow, the same as `complete-external-upload.json`, and promote the temporary upload S3 into a full `Upload` record, moving it to its final destination.
* `abort-multipart.json` - Aborts the multipart upload on S3 and destroys the `ExternalUploadStub` record if the user has permission to access that upload.
Also added are a few new columns to `ExternalUploadStub`:
* multipart - Whether or not this is a multipart upload
* external_upload_identifier - The "upload ID" for an S3 multipart upload
* filesize - The size of the file when the `create-multipart.json` or `generate-presigned-put.json` is called. This is used for validation.
When the user completes a direct S3 upload, either regular or multipart, we take the `filesize` that was captured when the `ExternalUploadStub` was first created and compare it with the final `Content-Length` size of the file where it is stored in S3. Then, if the two do not match, we throw an error, delete the file on S3, and ban the user from uploading files for N (default 5) minutes. This would only happen if the user uploads a different file than what they first specified, or in the case of multipart uploads uploaded larger chunks than needed. This is done to prevent abuse of S3 storage by bad actors.
Also included in this PR is an update to vendor/uppy.js. This has been built locally from the latest uppy source at https://github.com/transloadit/uppy/commit/d613b849a6591083f8a0968aa8d66537e231bbcd. This must be done so that I can get my multipart upload changes into Discourse. When the Uppy team cuts a proper release, we can bump the package.json versions instead.
2021-08-24 18:46:54 -04:00
|
|
|
it "raises an error, deletes the stub" do
|
2023-06-21 10:00:19 -04:00
|
|
|
expect { manager.transform! }.to raise_error(
|
FEATURE: Direct S3 multipart uploads for backups (#14736)
This PR introduces a new `enable_experimental_backup_uploads` site setting (default false and hidden), which when enabled alongside `enable_direct_s3_uploads` will allow for direct S3 multipart uploads of backup .tar.gz files.
To make multipart external uploads work with both the S3BackupStore and the S3Store, I've had to move several methods out of S3Store and into S3Helper, including:
* presigned_url
* create_multipart
* abort_multipart
* complete_multipart
* presign_multipart_part
* list_multipart_parts
Then, S3Store and S3BackupStore either delegate directly to S3Helper or have their own special methods to call S3Helper for these methods. FileStore.temporary_upload_path has also removed its dependence on upload_path, and can now be used interchangeably between the stores. A similar change was made in the frontend as well, moving the multipart related JS code out of ComposerUppyUpload and into a mixin of its own, so it can also be used by UppyUploadMixin.
Some changes to ExternalUploadManager had to be made here as well. The backup direct uploads do not need an Upload record made for them in the database, so they can be moved to their final S3 resting place when completing the multipart upload.
This changeset is not perfect; it introduces some special cases in UploadController to handle backups that was previously in BackupController, because UploadController is where the multipart routes are located. A subsequent pull request will pull these routes into a module or some other sharing pattern, along with hooks, so the backup controller and the upload controller (and any future controllers that may need them) can include these routes in a nicer way.
2021-11-10 17:25:31 -05:00
|
|
|
ExternalUploadManager::ChecksumMismatchError,
|
|
|
|
)
|
FEATURE: Uppy direct S3 multipart uploads in composer (#14051)
This pull request introduces the endpoints required, and the JavaScript functionality in the `ComposerUppyUpload` mixin, for direct S3 multipart uploads. There are four new endpoints in the uploads controller:
* `create-multipart.json` - Creates the multipart upload in S3 along with an `ExternalUploadStub` record, storing information about the file in the same way as `generate-presigned-put.json` does for regular direct S3 uploads
* `batch-presign-multipart-parts.json` - Takes a list of part numbers and the unique identifier for an `ExternalUploadStub` record, and generates the presigned URLs for those parts if the multipart upload still exists and if the user has permission to access that upload
* `complete-multipart.json` - Completes the multipart upload in S3. Needs the full list of part numbers and their associated ETags which are returned when the part is uploaded to the presigned URL above. Only works if the user has permission to access the associated `ExternalUploadStub` record and the multipart upload still exists.
After we confirm the upload is complete in S3, we go through the regular `UploadCreator` flow, the same as `complete-external-upload.json`, and promote the temporary upload S3 into a full `Upload` record, moving it to its final destination.
* `abort-multipart.json` - Aborts the multipart upload on S3 and destroys the `ExternalUploadStub` record if the user has permission to access that upload.
Also added are a few new columns to `ExternalUploadStub`:
* multipart - Whether or not this is a multipart upload
* external_upload_identifier - The "upload ID" for an S3 multipart upload
* filesize - The size of the file when the `create-multipart.json` or `generate-presigned-put.json` is called. This is used for validation.
When the user completes a direct S3 upload, either regular or multipart, we take the `filesize` that was captured when the `ExternalUploadStub` was first created and compare it with the final `Content-Length` size of the file where it is stored in S3. Then, if the two do not match, we throw an error, delete the file on S3, and ban the user from uploading files for N (default 5) minutes. This would only happen if the user uploads a different file than what they first specified, or in the case of multipart uploads uploaded larger chunks than needed. This is done to prevent abuse of S3 storage by bad actors.
Also included in this PR is an update to vendor/uppy.js. This has been built locally from the latest uppy source at https://github.com/transloadit/uppy/commit/d613b849a6591083f8a0968aa8d66537e231bbcd. This must be done so that I can get my multipart upload changes into Discourse. When the Uppy team cuts a proper release, we can bump the package.json versions instead.
2021-08-24 18:46:54 -04:00
|
|
|
expect(ExternalUploadStub.exists?(id: external_upload_stub.id)).to eq(false)
|
2022-06-20 12:36:05 -04:00
|
|
|
|
|
|
|
bucket = @fake_s3.bucket(SiteSetting.s3_upload_bucket)
|
|
|
|
expect(bucket.find_object(external_upload_stub.key)).to be_nil
|
2021-07-27 18:42:25 -04:00
|
|
|
end
|
2021-08-24 21:11:19 -04:00
|
|
|
|
|
|
|
it "does not delete the stub if enable_upload_debug_mode" do
|
|
|
|
SiteSetting.enable_upload_debug_mode = true
|
2023-06-21 10:00:19 -04:00
|
|
|
expect { manager.transform! }.to raise_error(
|
FEATURE: Direct S3 multipart uploads for backups (#14736)
This PR introduces a new `enable_experimental_backup_uploads` site setting (default false and hidden), which when enabled alongside `enable_direct_s3_uploads` will allow for direct S3 multipart uploads of backup .tar.gz files.
To make multipart external uploads work with both the S3BackupStore and the S3Store, I've had to move several methods out of S3Store and into S3Helper, including:
* presigned_url
* create_multipart
* abort_multipart
* complete_multipart
* presign_multipart_part
* list_multipart_parts
Then, S3Store and S3BackupStore either delegate directly to S3Helper or have their own special methods to call S3Helper for these methods. FileStore.temporary_upload_path has also removed its dependence on upload_path, and can now be used interchangeably between the stores. A similar change was made in the frontend as well, moving the multipart related JS code out of ComposerUppyUpload and into a mixin of its own, so it can also be used by UppyUploadMixin.
Some changes to ExternalUploadManager had to be made here as well. The backup direct uploads do not need an Upload record made for them in the database, so they can be moved to their final S3 resting place when completing the multipart upload.
This changeset is not perfect; it introduces some special cases in UploadController to handle backups that was previously in BackupController, because UploadController is where the multipart routes are located. A subsequent pull request will pull these routes into a module or some other sharing pattern, along with hooks, so the backup controller and the upload controller (and any future controllers that may need them) can include these routes in a nicer way.
2021-11-10 17:25:31 -05:00
|
|
|
ExternalUploadManager::ChecksumMismatchError,
|
|
|
|
)
|
2021-08-24 21:11:19 -04:00
|
|
|
external_stub = ExternalUploadStub.find(external_upload_stub.id)
|
|
|
|
expect(external_stub.status).to eq(ExternalUploadStub.statuses[:failed])
|
2022-06-20 12:36:05 -04:00
|
|
|
|
|
|
|
bucket = @fake_s3.bucket(SiteSetting.s3_upload_bucket)
|
|
|
|
expect(bucket.find_object(external_upload_stub.key)).to be_present
|
2021-08-24 21:11:19 -04:00
|
|
|
end
|
2021-07-27 18:42:25 -04:00
|
|
|
end
|
|
|
|
end
|
FEATURE: Uppy direct S3 multipart uploads in composer (#14051)
This pull request introduces the endpoints required, and the JavaScript functionality in the `ComposerUppyUpload` mixin, for direct S3 multipart uploads. There are four new endpoints in the uploads controller:
* `create-multipart.json` - Creates the multipart upload in S3 along with an `ExternalUploadStub` record, storing information about the file in the same way as `generate-presigned-put.json` does for regular direct S3 uploads
* `batch-presign-multipart-parts.json` - Takes a list of part numbers and the unique identifier for an `ExternalUploadStub` record, and generates the presigned URLs for those parts if the multipart upload still exists and if the user has permission to access that upload
* `complete-multipart.json` - Completes the multipart upload in S3. Needs the full list of part numbers and their associated ETags which are returned when the part is uploaded to the presigned URL above. Only works if the user has permission to access the associated `ExternalUploadStub` record and the multipart upload still exists.
After we confirm the upload is complete in S3, we go through the regular `UploadCreator` flow, the same as `complete-external-upload.json`, and promote the temporary upload S3 into a full `Upload` record, moving it to its final destination.
* `abort-multipart.json` - Aborts the multipart upload on S3 and destroys the `ExternalUploadStub` record if the user has permission to access that upload.
Also added are a few new columns to `ExternalUploadStub`:
* multipart - Whether or not this is a multipart upload
* external_upload_identifier - The "upload ID" for an S3 multipart upload
* filesize - The size of the file when the `create-multipart.json` or `generate-presigned-put.json` is called. This is used for validation.
When the user completes a direct S3 upload, either regular or multipart, we take the `filesize` that was captured when the `ExternalUploadStub` was first created and compare it with the final `Content-Length` size of the file where it is stored in S3. Then, if the two do not match, we throw an error, delete the file on S3, and ban the user from uploading files for N (default 5) minutes. This would only happen if the user uploads a different file than what they first specified, or in the case of multipart uploads uploaded larger chunks than needed. This is done to prevent abuse of S3 storage by bad actors.
Also included in this PR is an update to vendor/uppy.js. This has been built locally from the latest uppy source at https://github.com/transloadit/uppy/commit/d613b849a6591083f8a0968aa8d66537e231bbcd. This must be done so that I can get my multipart upload changes into Discourse. When the Uppy team cuts a proper release, we can bump the package.json versions instead.
2021-08-24 18:46:54 -04:00
|
|
|
|
|
|
|
context "when the downloaded file size does not match the expected file size for the upload stub" do
|
|
|
|
before { external_upload_stub.update!(filesize: 10) }
|
|
|
|
|
|
|
|
after { Discourse.redis.flushdb }
|
|
|
|
|
|
|
|
it "raises an error, deletes the file immediately, and prevents the user from uploading external files for a few minutes" do
|
2023-06-21 10:00:19 -04:00
|
|
|
expect { manager.transform! }.to raise_error(ExternalUploadManager::SizeMismatchError)
|
FEATURE: Uppy direct S3 multipart uploads in composer (#14051)
This pull request introduces the endpoints required, and the JavaScript functionality in the `ComposerUppyUpload` mixin, for direct S3 multipart uploads. There are four new endpoints in the uploads controller:
* `create-multipart.json` - Creates the multipart upload in S3 along with an `ExternalUploadStub` record, storing information about the file in the same way as `generate-presigned-put.json` does for regular direct S3 uploads
* `batch-presign-multipart-parts.json` - Takes a list of part numbers and the unique identifier for an `ExternalUploadStub` record, and generates the presigned URLs for those parts if the multipart upload still exists and if the user has permission to access that upload
* `complete-multipart.json` - Completes the multipart upload in S3. Needs the full list of part numbers and their associated ETags which are returned when the part is uploaded to the presigned URL above. Only works if the user has permission to access the associated `ExternalUploadStub` record and the multipart upload still exists.
After we confirm the upload is complete in S3, we go through the regular `UploadCreator` flow, the same as `complete-external-upload.json`, and promote the temporary upload S3 into a full `Upload` record, moving it to its final destination.
* `abort-multipart.json` - Aborts the multipart upload on S3 and destroys the `ExternalUploadStub` record if the user has permission to access that upload.
Also added are a few new columns to `ExternalUploadStub`:
* multipart - Whether or not this is a multipart upload
* external_upload_identifier - The "upload ID" for an S3 multipart upload
* filesize - The size of the file when the `create-multipart.json` or `generate-presigned-put.json` is called. This is used for validation.
When the user completes a direct S3 upload, either regular or multipart, we take the `filesize` that was captured when the `ExternalUploadStub` was first created and compare it with the final `Content-Length` size of the file where it is stored in S3. Then, if the two do not match, we throw an error, delete the file on S3, and ban the user from uploading files for N (default 5) minutes. This would only happen if the user uploads a different file than what they first specified, or in the case of multipart uploads uploaded larger chunks than needed. This is done to prevent abuse of S3 storage by bad actors.
Also included in this PR is an update to vendor/uppy.js. This has been built locally from the latest uppy source at https://github.com/transloadit/uppy/commit/d613b849a6591083f8a0968aa8d66537e231bbcd. This must be done so that I can get my multipart upload changes into Discourse. When the Uppy team cuts a proper release, we can bump the package.json versions instead.
2021-08-24 18:46:54 -04:00
|
|
|
expect(ExternalUploadStub.exists?(id: external_upload_stub.id)).to eq(false)
|
|
|
|
expect(
|
|
|
|
Discourse.redis.get(
|
|
|
|
"#{ExternalUploadManager::BAN_USER_REDIS_PREFIX}#{external_upload_stub.created_by_id}",
|
2023-01-09 06:18:21 -05:00
|
|
|
),
|
FEATURE: Uppy direct S3 multipart uploads in composer (#14051)
This pull request introduces the endpoints required, and the JavaScript functionality in the `ComposerUppyUpload` mixin, for direct S3 multipart uploads. There are four new endpoints in the uploads controller:
* `create-multipart.json` - Creates the multipart upload in S3 along with an `ExternalUploadStub` record, storing information about the file in the same way as `generate-presigned-put.json` does for regular direct S3 uploads
* `batch-presign-multipart-parts.json` - Takes a list of part numbers and the unique identifier for an `ExternalUploadStub` record, and generates the presigned URLs for those parts if the multipart upload still exists and if the user has permission to access that upload
* `complete-multipart.json` - Completes the multipart upload in S3. Needs the full list of part numbers and their associated ETags which are returned when the part is uploaded to the presigned URL above. Only works if the user has permission to access the associated `ExternalUploadStub` record and the multipart upload still exists.
After we confirm the upload is complete in S3, we go through the regular `UploadCreator` flow, the same as `complete-external-upload.json`, and promote the temporary upload S3 into a full `Upload` record, moving it to its final destination.
* `abort-multipart.json` - Aborts the multipart upload on S3 and destroys the `ExternalUploadStub` record if the user has permission to access that upload.
Also added are a few new columns to `ExternalUploadStub`:
* multipart - Whether or not this is a multipart upload
* external_upload_identifier - The "upload ID" for an S3 multipart upload
* filesize - The size of the file when the `create-multipart.json` or `generate-presigned-put.json` is called. This is used for validation.
When the user completes a direct S3 upload, either regular or multipart, we take the `filesize` that was captured when the `ExternalUploadStub` was first created and compare it with the final `Content-Length` size of the file where it is stored in S3. Then, if the two do not match, we throw an error, delete the file on S3, and ban the user from uploading files for N (default 5) minutes. This would only happen if the user uploads a different file than what they first specified, or in the case of multipart uploads uploaded larger chunks than needed. This is done to prevent abuse of S3 storage by bad actors.
Also included in this PR is an update to vendor/uppy.js. This has been built locally from the latest uppy source at https://github.com/transloadit/uppy/commit/d613b849a6591083f8a0968aa8d66537e231bbcd. This must be done so that I can get my multipart upload changes into Discourse. When the Uppy team cuts a proper release, we can bump the package.json versions instead.
2021-08-24 18:46:54 -04:00
|
|
|
).to eq("1")
|
2022-06-20 12:36:05 -04:00
|
|
|
|
|
|
|
bucket = @fake_s3.bucket(SiteSetting.s3_upload_bucket)
|
|
|
|
expect(bucket.find_object(external_upload_stub.key)).to be_nil
|
FEATURE: Uppy direct S3 multipart uploads in composer (#14051)
This pull request introduces the endpoints required, and the JavaScript functionality in the `ComposerUppyUpload` mixin, for direct S3 multipart uploads. There are four new endpoints in the uploads controller:
* `create-multipart.json` - Creates the multipart upload in S3 along with an `ExternalUploadStub` record, storing information about the file in the same way as `generate-presigned-put.json` does for regular direct S3 uploads
* `batch-presign-multipart-parts.json` - Takes a list of part numbers and the unique identifier for an `ExternalUploadStub` record, and generates the presigned URLs for those parts if the multipart upload still exists and if the user has permission to access that upload
* `complete-multipart.json` - Completes the multipart upload in S3. Needs the full list of part numbers and their associated ETags which are returned when the part is uploaded to the presigned URL above. Only works if the user has permission to access the associated `ExternalUploadStub` record and the multipart upload still exists.
After we confirm the upload is complete in S3, we go through the regular `UploadCreator` flow, the same as `complete-external-upload.json`, and promote the temporary upload S3 into a full `Upload` record, moving it to its final destination.
* `abort-multipart.json` - Aborts the multipart upload on S3 and destroys the `ExternalUploadStub` record if the user has permission to access that upload.
Also added are a few new columns to `ExternalUploadStub`:
* multipart - Whether or not this is a multipart upload
* external_upload_identifier - The "upload ID" for an S3 multipart upload
* filesize - The size of the file when the `create-multipart.json` or `generate-presigned-put.json` is called. This is used for validation.
When the user completes a direct S3 upload, either regular or multipart, we take the `filesize` that was captured when the `ExternalUploadStub` was first created and compare it with the final `Content-Length` size of the file where it is stored in S3. Then, if the two do not match, we throw an error, delete the file on S3, and ban the user from uploading files for N (default 5) minutes. This would only happen if the user uploads a different file than what they first specified, or in the case of multipart uploads uploaded larger chunks than needed. This is done to prevent abuse of S3 storage by bad actors.
Also included in this PR is an update to vendor/uppy.js. This has been built locally from the latest uppy source at https://github.com/transloadit/uppy/commit/d613b849a6591083f8a0968aa8d66537e231bbcd. This must be done so that I can get my multipart upload changes into Discourse. When the Uppy team cuts a proper release, we can bump the package.json versions instead.
2021-08-24 18:46:54 -04:00
|
|
|
end
|
2021-08-24 21:11:19 -04:00
|
|
|
|
|
|
|
it "does not delete the stub if enable_upload_debug_mode" do
|
|
|
|
SiteSetting.enable_upload_debug_mode = true
|
2023-06-21 10:00:19 -04:00
|
|
|
expect { manager.transform! }.to raise_error(ExternalUploadManager::SizeMismatchError)
|
2021-08-24 21:11:19 -04:00
|
|
|
external_stub = ExternalUploadStub.find(external_upload_stub.id)
|
|
|
|
expect(external_stub.status).to eq(ExternalUploadStub.statuses[:failed])
|
2022-06-20 12:36:05 -04:00
|
|
|
|
|
|
|
bucket = @fake_s3.bucket(SiteSetting.s3_upload_bucket)
|
|
|
|
expect(bucket.find_object(external_upload_stub.key)).to be_present
|
2021-08-24 21:11:19 -04:00
|
|
|
end
|
FEATURE: Uppy direct S3 multipart uploads in composer (#14051)
This pull request introduces the endpoints required, and the JavaScript functionality in the `ComposerUppyUpload` mixin, for direct S3 multipart uploads. There are four new endpoints in the uploads controller:
* `create-multipart.json` - Creates the multipart upload in S3 along with an `ExternalUploadStub` record, storing information about the file in the same way as `generate-presigned-put.json` does for regular direct S3 uploads
* `batch-presign-multipart-parts.json` - Takes a list of part numbers and the unique identifier for an `ExternalUploadStub` record, and generates the presigned URLs for those parts if the multipart upload still exists and if the user has permission to access that upload
* `complete-multipart.json` - Completes the multipart upload in S3. Needs the full list of part numbers and their associated ETags which are returned when the part is uploaded to the presigned URL above. Only works if the user has permission to access the associated `ExternalUploadStub` record and the multipart upload still exists.
After we confirm the upload is complete in S3, we go through the regular `UploadCreator` flow, the same as `complete-external-upload.json`, and promote the temporary upload S3 into a full `Upload` record, moving it to its final destination.
* `abort-multipart.json` - Aborts the multipart upload on S3 and destroys the `ExternalUploadStub` record if the user has permission to access that upload.
Also added are a few new columns to `ExternalUploadStub`:
* multipart - Whether or not this is a multipart upload
* external_upload_identifier - The "upload ID" for an S3 multipart upload
* filesize - The size of the file when the `create-multipart.json` or `generate-presigned-put.json` is called. This is used for validation.
When the user completes a direct S3 upload, either regular or multipart, we take the `filesize` that was captured when the `ExternalUploadStub` was first created and compare it with the final `Content-Length` size of the file where it is stored in S3. Then, if the two do not match, we throw an error, delete the file on S3, and ban the user from uploading files for N (default 5) minutes. This would only happen if the user uploads a different file than what they first specified, or in the case of multipart uploads uploaded larger chunks than needed. This is done to prevent abuse of S3 storage by bad actors.
Also included in this PR is an update to vendor/uppy.js. This has been built locally from the latest uppy source at https://github.com/transloadit/uppy/commit/d613b849a6591083f8a0968aa8d66537e231bbcd. This must be done so that I can get my multipart upload changes into Discourse. When the Uppy team cuts a proper release, we can bump the package.json versions instead.
2021-08-24 18:46:54 -04:00
|
|
|
end
|
2021-07-27 18:42:25 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
context "when stubbed upload is > DOWNLOAD_LIMIT (too big to download, generate a fake sha)" do
|
|
|
|
let(:object_size) { 200.megabytes }
|
|
|
|
let(:object_file) { pdf_file }
|
FEATURE: Uppy direct S3 multipart uploads in composer (#14051)
This pull request introduces the endpoints required, and the JavaScript functionality in the `ComposerUppyUpload` mixin, for direct S3 multipart uploads. There are four new endpoints in the uploads controller:
* `create-multipart.json` - Creates the multipart upload in S3 along with an `ExternalUploadStub` record, storing information about the file in the same way as `generate-presigned-put.json` does for regular direct S3 uploads
* `batch-presign-multipart-parts.json` - Takes a list of part numbers and the unique identifier for an `ExternalUploadStub` record, and generates the presigned URLs for those parts if the multipart upload still exists and if the user has permission to access that upload
* `complete-multipart.json` - Completes the multipart upload in S3. Needs the full list of part numbers and their associated ETags which are returned when the part is uploaded to the presigned URL above. Only works if the user has permission to access the associated `ExternalUploadStub` record and the multipart upload still exists.
After we confirm the upload is complete in S3, we go through the regular `UploadCreator` flow, the same as `complete-external-upload.json`, and promote the temporary upload S3 into a full `Upload` record, moving it to its final destination.
* `abort-multipart.json` - Aborts the multipart upload on S3 and destroys the `ExternalUploadStub` record if the user has permission to access that upload.
Also added are a few new columns to `ExternalUploadStub`:
* multipart - Whether or not this is a multipart upload
* external_upload_identifier - The "upload ID" for an S3 multipart upload
* filesize - The size of the file when the `create-multipart.json` or `generate-presigned-put.json` is called. This is used for validation.
When the user completes a direct S3 upload, either regular or multipart, we take the `filesize` that was captured when the `ExternalUploadStub` was first created and compare it with the final `Content-Length` size of the file where it is stored in S3. Then, if the two do not match, we throw an error, delete the file on S3, and ban the user from uploading files for N (default 5) minutes. This would only happen if the user uploads a different file than what they first specified, or in the case of multipart uploads uploaded larger chunks than needed. This is done to prevent abuse of S3 storage by bad actors.
Also included in this PR is an update to vendor/uppy.js. This has been built locally from the latest uppy source at https://github.com/transloadit/uppy/commit/d613b849a6591083f8a0968aa8d66537e231bbcd. This must be done so that I can get my multipart upload changes into Discourse. When the Uppy team cuts a proper release, we can bump the package.json versions instead.
2021-08-24 18:46:54 -04:00
|
|
|
let!(:external_upload_stub) do
|
|
|
|
Fabricate(:attachment_external_upload_stub, created_by: user, filesize: object_size)
|
2023-01-09 06:18:21 -05:00
|
|
|
end
|
2021-07-27 18:42:25 -04:00
|
|
|
|
|
|
|
before do
|
|
|
|
UploadCreator
|
|
|
|
.any_instance
|
|
|
|
.stubs(:generate_fake_sha1_hash)
|
|
|
|
.returns("testbc60eb18e8f974cbfae8bb0f069c3a311024")
|
|
|
|
end
|
|
|
|
|
|
|
|
it "does not try and download the file" do
|
|
|
|
FileHelper.expects(:download).never
|
2023-06-21 10:00:19 -04:00
|
|
|
manager.transform!
|
2021-07-27 18:42:25 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "generates a fake sha for the upload record" do
|
2023-06-21 10:00:19 -04:00
|
|
|
upload = manager.transform!
|
2021-07-27 18:42:25 -04:00
|
|
|
expect(upload.sha1).not_to eq(sha1)
|
|
|
|
expect(upload.original_sha1).to eq(nil)
|
|
|
|
expect(upload.filesize).to eq(object_size)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "marks the stub as uploaded" do
|
2023-06-21 10:00:19 -04:00
|
|
|
manager.transform!
|
2021-07-27 18:42:25 -04:00
|
|
|
expect(external_upload_stub.reload.status).to eq(ExternalUploadStub.statuses[:uploaded])
|
|
|
|
end
|
|
|
|
|
|
|
|
it "copies the stubbed upload on S3 to its new destination and deletes it" do
|
2023-06-21 10:00:19 -04:00
|
|
|
upload = manager.transform!
|
2022-06-20 12:36:05 -04:00
|
|
|
|
|
|
|
bucket = @fake_s3.bucket(SiteSetting.s3_upload_bucket)
|
|
|
|
expect(bucket.find_object(Discourse.store.get_path_for_upload(upload))).to be_present
|
|
|
|
expect(bucket.find_object(external_upload_stub.key)).to be_nil
|
2021-07-27 18:42:25 -04:00
|
|
|
end
|
|
|
|
end
|
FEATURE: Direct S3 multipart uploads for backups (#14736)
This PR introduces a new `enable_experimental_backup_uploads` site setting (default false and hidden), which when enabled alongside `enable_direct_s3_uploads` will allow for direct S3 multipart uploads of backup .tar.gz files.
To make multipart external uploads work with both the S3BackupStore and the S3Store, I've had to move several methods out of S3Store and into S3Helper, including:
* presigned_url
* create_multipart
* abort_multipart
* complete_multipart
* presign_multipart_part
* list_multipart_parts
Then, S3Store and S3BackupStore either delegate directly to S3Helper or have their own special methods to call S3Helper for these methods. FileStore.temporary_upload_path has also removed its dependence on upload_path, and can now be used interchangeably between the stores. A similar change was made in the frontend as well, moving the multipart related JS code out of ComposerUppyUpload and into a mixin of its own, so it can also be used by UppyUploadMixin.
Some changes to ExternalUploadManager had to be made here as well. The backup direct uploads do not need an Upload record made for them in the database, so they can be moved to their final S3 resting place when completing the multipart upload.
This changeset is not perfect; it introduces some special cases in UploadController to handle backups that was previously in BackupController, because UploadController is where the multipart routes are located. A subsequent pull request will pull these routes into a module or some other sharing pattern, along with hooks, so the backup controller and the upload controller (and any future controllers that may need them) can include these routes in a nicer way.
2021-11-10 17:25:31 -05:00
|
|
|
|
|
|
|
context "when the upload type is backup" do
|
|
|
|
let(:object_size) { 200.megabytes }
|
|
|
|
let(:object_file) { file_from_fixtures("backup_since_v1.6.tar.gz", "backups") }
|
|
|
|
let!(:external_upload_stub) do
|
|
|
|
Fabricate(
|
|
|
|
:attachment_external_upload_stub,
|
|
|
|
created_by: user,
|
|
|
|
filesize: object_size,
|
|
|
|
upload_type: "backup",
|
|
|
|
original_filename: "backup_since_v1.6.tar.gz",
|
|
|
|
folder_prefix: RailsMultisite::ConnectionManagement.current_db,
|
|
|
|
)
|
|
|
|
end
|
2022-06-20 12:36:05 -04:00
|
|
|
let(:s3_bucket_name) { SiteSetting.s3_backup_bucket }
|
FEATURE: Direct S3 multipart uploads for backups (#14736)
This PR introduces a new `enable_experimental_backup_uploads` site setting (default false and hidden), which when enabled alongside `enable_direct_s3_uploads` will allow for direct S3 multipart uploads of backup .tar.gz files.
To make multipart external uploads work with both the S3BackupStore and the S3Store, I've had to move several methods out of S3Store and into S3Helper, including:
* presigned_url
* create_multipart
* abort_multipart
* complete_multipart
* presign_multipart_part
* list_multipart_parts
Then, S3Store and S3BackupStore either delegate directly to S3Helper or have their own special methods to call S3Helper for these methods. FileStore.temporary_upload_path has also removed its dependence on upload_path, and can now be used interchangeably between the stores. A similar change was made in the frontend as well, moving the multipart related JS code out of ComposerUppyUpload and into a mixin of its own, so it can also be used by UppyUploadMixin.
Some changes to ExternalUploadManager had to be made here as well. The backup direct uploads do not need an Upload record made for them in the database, so they can be moved to their final S3 resting place when completing the multipart upload.
This changeset is not perfect; it introduces some special cases in UploadController to handle backups that was previously in BackupController, because UploadController is where the multipart routes are located. A subsequent pull request will pull these routes into a module or some other sharing pattern, along with hooks, so the backup controller and the upload controller (and any future controllers that may need them) can include these routes in a nicer way.
2021-11-10 17:25:31 -05:00
|
|
|
|
|
|
|
it "does not try and download the file" do
|
|
|
|
FileHelper.expects(:download).never
|
2023-06-21 10:00:19 -04:00
|
|
|
manager.transform!
|
FEATURE: Direct S3 multipart uploads for backups (#14736)
This PR introduces a new `enable_experimental_backup_uploads` site setting (default false and hidden), which when enabled alongside `enable_direct_s3_uploads` will allow for direct S3 multipart uploads of backup .tar.gz files.
To make multipart external uploads work with both the S3BackupStore and the S3Store, I've had to move several methods out of S3Store and into S3Helper, including:
* presigned_url
* create_multipart
* abort_multipart
* complete_multipart
* presign_multipart_part
* list_multipart_parts
Then, S3Store and S3BackupStore either delegate directly to S3Helper or have their own special methods to call S3Helper for these methods. FileStore.temporary_upload_path has also removed its dependence on upload_path, and can now be used interchangeably between the stores. A similar change was made in the frontend as well, moving the multipart related JS code out of ComposerUppyUpload and into a mixin of its own, so it can also be used by UppyUploadMixin.
Some changes to ExternalUploadManager had to be made here as well. The backup direct uploads do not need an Upload record made for them in the database, so they can be moved to their final S3 resting place when completing the multipart upload.
This changeset is not perfect; it introduces some special cases in UploadController to handle backups that was previously in BackupController, because UploadController is where the multipart routes are located. A subsequent pull request will pull these routes into a module or some other sharing pattern, along with hooks, so the backup controller and the upload controller (and any future controllers that may need them) can include these routes in a nicer way.
2021-11-10 17:25:31 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
it "raises an error when backups are disabled" do
|
|
|
|
SiteSetting.enable_backups = false
|
2023-06-21 10:00:19 -04:00
|
|
|
expect { manager.transform! }.to raise_error(Discourse::InvalidAccess)
|
FEATURE: Direct S3 multipart uploads for backups (#14736)
This PR introduces a new `enable_experimental_backup_uploads` site setting (default false and hidden), which when enabled alongside `enable_direct_s3_uploads` will allow for direct S3 multipart uploads of backup .tar.gz files.
To make multipart external uploads work with both the S3BackupStore and the S3Store, I've had to move several methods out of S3Store and into S3Helper, including:
* presigned_url
* create_multipart
* abort_multipart
* complete_multipart
* presign_multipart_part
* list_multipart_parts
Then, S3Store and S3BackupStore either delegate directly to S3Helper or have their own special methods to call S3Helper for these methods. FileStore.temporary_upload_path has also removed its dependence on upload_path, and can now be used interchangeably between the stores. A similar change was made in the frontend as well, moving the multipart related JS code out of ComposerUppyUpload and into a mixin of its own, so it can also be used by UppyUploadMixin.
Some changes to ExternalUploadManager had to be made here as well. The backup direct uploads do not need an Upload record made for them in the database, so they can be moved to their final S3 resting place when completing the multipart upload.
This changeset is not perfect; it introduces some special cases in UploadController to handle backups that was previously in BackupController, because UploadController is where the multipart routes are located. A subsequent pull request will pull these routes into a module or some other sharing pattern, along with hooks, so the backup controller and the upload controller (and any future controllers that may need them) can include these routes in a nicer way.
2021-11-10 17:25:31 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
it "raises an error when backups are local, not s3" do
|
|
|
|
SiteSetting.backup_location = BackupLocationSiteSetting::LOCAL
|
2023-06-21 10:00:19 -04:00
|
|
|
expect { manager.transform! }.to raise_error(Discourse::InvalidAccess)
|
FEATURE: Direct S3 multipart uploads for backups (#14736)
This PR introduces a new `enable_experimental_backup_uploads` site setting (default false and hidden), which when enabled alongside `enable_direct_s3_uploads` will allow for direct S3 multipart uploads of backup .tar.gz files.
To make multipart external uploads work with both the S3BackupStore and the S3Store, I've had to move several methods out of S3Store and into S3Helper, including:
* presigned_url
* create_multipart
* abort_multipart
* complete_multipart
* presign_multipart_part
* list_multipart_parts
Then, S3Store and S3BackupStore either delegate directly to S3Helper or have their own special methods to call S3Helper for these methods. FileStore.temporary_upload_path has also removed its dependence on upload_path, and can now be used interchangeably between the stores. A similar change was made in the frontend as well, moving the multipart related JS code out of ComposerUppyUpload and into a mixin of its own, so it can also be used by UppyUploadMixin.
Some changes to ExternalUploadManager had to be made here as well. The backup direct uploads do not need an Upload record made for them in the database, so they can be moved to their final S3 resting place when completing the multipart upload.
This changeset is not perfect; it introduces some special cases in UploadController to handle backups that was previously in BackupController, because UploadController is where the multipart routes are located. A subsequent pull request will pull these routes into a module or some other sharing pattern, along with hooks, so the backup controller and the upload controller (and any future controllers that may need them) can include these routes in a nicer way.
2021-11-10 17:25:31 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
it "does not create an upload record" do
|
2023-06-21 10:00:19 -04:00
|
|
|
expect { manager.transform! }.not_to change { Upload.count }
|
FEATURE: Direct S3 multipart uploads for backups (#14736)
This PR introduces a new `enable_experimental_backup_uploads` site setting (default false and hidden), which when enabled alongside `enable_direct_s3_uploads` will allow for direct S3 multipart uploads of backup .tar.gz files.
To make multipart external uploads work with both the S3BackupStore and the S3Store, I've had to move several methods out of S3Store and into S3Helper, including:
* presigned_url
* create_multipart
* abort_multipart
* complete_multipart
* presign_multipart_part
* list_multipart_parts
Then, S3Store and S3BackupStore either delegate directly to S3Helper or have their own special methods to call S3Helper for these methods. FileStore.temporary_upload_path has also removed its dependence on upload_path, and can now be used interchangeably between the stores. A similar change was made in the frontend as well, moving the multipart related JS code out of ComposerUppyUpload and into a mixin of its own, so it can also be used by UppyUploadMixin.
Some changes to ExternalUploadManager had to be made here as well. The backup direct uploads do not need an Upload record made for them in the database, so they can be moved to their final S3 resting place when completing the multipart upload.
This changeset is not perfect; it introduces some special cases in UploadController to handle backups that was previously in BackupController, because UploadController is where the multipart routes are located. A subsequent pull request will pull these routes into a module or some other sharing pattern, along with hooks, so the backup controller and the upload controller (and any future controllers that may need them) can include these routes in a nicer way.
2021-11-10 17:25:31 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
it "copies the stubbed upload on S3 to its new destination and deletes it" do
|
2022-06-20 12:36:05 -04:00
|
|
|
bucket = @fake_s3.bucket(SiteSetting.s3_backup_bucket)
|
|
|
|
expect(bucket.find_object(external_upload_stub.key)).to be_present
|
|
|
|
|
2023-06-21 10:00:19 -04:00
|
|
|
manager.transform!
|
2022-06-20 12:36:05 -04:00
|
|
|
|
|
|
|
expect(
|
|
|
|
bucket.find_object(
|
|
|
|
"#{RailsMultisite::ConnectionManagement.current_db}/backup_since_v1.6.tar.gz",
|
2023-01-09 06:18:21 -05:00
|
|
|
),
|
2022-06-20 12:36:05 -04:00
|
|
|
).to be_present
|
|
|
|
expect(bucket.find_object(external_upload_stub.key)).to be_nil
|
FEATURE: Direct S3 multipart uploads for backups (#14736)
This PR introduces a new `enable_experimental_backup_uploads` site setting (default false and hidden), which when enabled alongside `enable_direct_s3_uploads` will allow for direct S3 multipart uploads of backup .tar.gz files.
To make multipart external uploads work with both the S3BackupStore and the S3Store, I've had to move several methods out of S3Store and into S3Helper, including:
* presigned_url
* create_multipart
* abort_multipart
* complete_multipart
* presign_multipart_part
* list_multipart_parts
Then, S3Store and S3BackupStore either delegate directly to S3Helper or have their own special methods to call S3Helper for these methods. FileStore.temporary_upload_path has also removed its dependence on upload_path, and can now be used interchangeably between the stores. A similar change was made in the frontend as well, moving the multipart related JS code out of ComposerUppyUpload and into a mixin of its own, so it can also be used by UppyUploadMixin.
Some changes to ExternalUploadManager had to be made here as well. The backup direct uploads do not need an Upload record made for them in the database, so they can be moved to their final S3 resting place when completing the multipart upload.
This changeset is not perfect; it introduces some special cases in UploadController to handle backups that was previously in BackupController, because UploadController is where the multipart routes are located. A subsequent pull request will pull these routes into a module or some other sharing pattern, along with hooks, so the backup controller and the upload controller (and any future controllers that may need them) can include these routes in a nicer way.
2021-11-10 17:25:31 -05:00
|
|
|
end
|
|
|
|
end
|
2021-07-27 18:42:25 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
def stub_download_object_filehelper
|
|
|
|
signed_url = Discourse.store.signed_url_for_path(external_upload_stub.key)
|
|
|
|
uri = URI.parse(signed_url)
|
|
|
|
signed_url = uri.to_s.gsub(uri.query, "")
|
|
|
|
stub_request(:get, signed_url).with(query: hash_including({})).to_return(
|
|
|
|
status: 200,
|
|
|
|
body: object_file.read,
|
|
|
|
)
|
|
|
|
end
|
|
|
|
|
2022-06-20 12:36:05 -04:00
|
|
|
def prepare_fake_s3
|
|
|
|
@fake_s3 = FakeS3.create
|
2021-07-27 18:42:25 -04:00
|
|
|
|
2022-06-20 12:36:05 -04:00
|
|
|
@fake_s3.bucket(s3_bucket_name).put_object(
|
|
|
|
key: external_upload_stub.key,
|
|
|
|
size: object_size,
|
|
|
|
last_modified: Time.zone.now,
|
|
|
|
metadata: external_upload_stub_metadata,
|
2021-07-27 18:42:25 -04:00
|
|
|
)
|
|
|
|
end
|
|
|
|
end
|