discourse/app/jobs/scheduled/clean_up_uploads.rb

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

74 lines
2.2 KiB
Ruby
Raw Permalink Normal View History

# frozen_string_literal: true
2013-10-14 08:27:41 -04:00
module Jobs
class CleanUpUploads < ::Jobs::Scheduled
every 1.hour
2013-10-14 08:27:41 -04:00
def execute(args)
grace_period = [SiteSetting.clean_orphan_uploads_grace_period_hours, 1].max
2018-06-04 13:06:52 -04:00
# Always remove invalid upload records regardless of clean_up_uploads setting.
Upload
.by_users
.where(
"retain_hours IS NULL OR created_at < current_timestamp - interval '1 hour' * retain_hours",
)
.where("created_at < ?", grace_period.hour.ago)
2018-06-04 12:43:00 -04:00
.where(url: "")
.find_each(&:destroy!)
2018-06-04 13:06:52 -04:00
return unless SiteSetting.clean_up_uploads?
2013-10-14 08:27:41 -04:00
# Do nothing if the last cleanup was run too recently.
last_cleanup_timestamp = last_cleanup
if last_cleanup_timestamp.present? &&
(Time.zone.now.to_i - last_cleanup_timestamp) < (grace_period / 2).hours
return
end
result = Upload.by_users
Upload.unused_callbacks&.each { |handler| result = handler.call(result) }
result =
result
.where(
"uploads.retain_hours IS NULL OR uploads.created_at < current_timestamp - interval '1 hour' * uploads.retain_hours",
)
.where("uploads.created_at < ?", grace_period.hour.ago) # Don't remove any secure uploads.
FEATURE: Secure media allowing duplicated uploads with category-level privacy and post-based access rules (#8664) ### General Changes and Duplication * We now consider a post `with_secure_media?` if it is in a read-restricted category. * When uploading we now set an upload's secure status straight away. * When uploading if `SiteSetting.secure_media` is enabled, we do not check to see if the upload already exists using the `sha1` digest of the upload. The `sha1` column of the upload is filled with a `SecureRandom.hex(20)` value which is the same length as `Upload::SHA1_LENGTH`. The `original_sha1` column is filled with the _real_ sha1 digest of the file. * Whether an upload `should_be_secure?` is now determined by whether the `access_control_post` is `with_secure_media?` (if there is no access control post then we leave the secure status as is). * When serializing the upload, we now cook the URL if the upload is secure. This is so it shows up correctly in the composer preview, because we set secure status on upload. ### Viewing Secure Media * The secure-media-upload URL will take the post that the upload is attached to into account via `Guardian.can_see?` for access permissions * If there is no `access_control_post` then we just deliver the media. This should be a rare occurrance and shouldn't cause issues as the `access_control_post` is set when `link_post_uploads` is called via `CookedPostProcessor` ### Removed We no longer do any of these because we do not reuse uploads by sha1 if secure media is enabled. * We no longer have a way to prevent cross-posting of a secure upload from a private context to a public context. * We no longer have to set `secure: false` for uploads when uploading for a theme component.
2020-01-15 22:50:27 -05:00
.where("uploads.access_control_post_id IS NULL")
.joins(
"LEFT JOIN upload_references ON upload_references.upload_id = uploads.id",
) # Don't remove any uploads linked to an UploadReference.
.where("upload_references.upload_id IS NULL")
.with_no_non_post_relations
2013-10-14 08:27:41 -04:00
result.find_each do |upload|
next if Upload.in_use_callbacks&.any? { |callback| callback.call(upload) }
upload.sha1.present? ? upload.destroy : upload.delete
end
FEATURE: Initial implementation of direct S3 uploads with uppy and stubs (#13787) This adds a few different things to allow for direct S3 uploads using uppy. **These changes are still not the default.** There are hidden `enable_experimental_image_uploader` and `enable_direct_s3_uploads` settings that must be turned on for any of this code to be used, and even if they are turned on only the User Card Background for the user profile actually uses uppy-image-uploader. A new `ExternalUploadStub` model and database table is introduced in this pull request. This is used to keep track of uploads that are uploaded to a temporary location in S3 with the direct to S3 code, and they are eventually deleted a) when the direct upload is completed and b) after a certain time period of not being used. ### Starting a direct S3 upload When an S3 direct upload is initiated with uppy, we first request a presigned PUT URL from the new `generate-presigned-put` endpoint in `UploadsController`. This generates an S3 key in the `temp` folder inside the correct bucket path, along with any metadata from the clientside (e.g. the SHA1 checksum described below). This will also create an `ExternalUploadStub` and store the details of the temp object key and the file being uploaded. Once the clientside has this URL, uppy will upload the file direct to S3 using the presigned URL. Once the upload is complete we go to the next stage. ### Completing a direct S3 upload Once the upload to S3 is done we call the new `complete-external-upload` route with the unique identifier of the `ExternalUploadStub` created earlier. Only the user who made the stub can complete the external upload. One of two paths is followed via the `ExternalUploadManager`. 1. If the object in S3 is too large (currently 100mb defined by `ExternalUploadManager::DOWNLOAD_LIMIT`) we do not download and generate the SHA1 for that file. Instead we create the `Upload` record via `UploadCreator` and simply copy it to its final destination on S3 then delete the initial temp file. Several modifications to `UploadCreator` have been made to accommodate this. 2. If the object in S3 is small enough, we download it. When the temporary S3 file is downloaded, we compare the SHA1 checksum generated by the browser with the actual SHA1 checksum of the file generated by ruby. The browser SHA1 checksum is stored on the object in S3 with metadata, and is generated via the `UppyChecksum` plugin. Keep in mind that some browsers will not generate this due to compatibility or other issues. We then follow the normal `UploadCreator` path with one exception. To cut down on having to re-upload the file again, if there are no changes (such as resizing etc) to the file in `UploadCreator` we follow the same copy + delete temp path that we do for files that are too large. 3. Finally we return the serialized upload record back to the client There are several errors that could happen that are handled by `UploadsController` as well. Also in this PR is some refactoring of `displayErrorForUpload` to handle both uppy and jquery file uploader errors.
2021-07-27 18:42:25 -04:00
ExternalUploadStub.cleanup!
self.last_cleanup = Time.zone.now.to_i
end
def last_cleanup=(timestamp)
Discourse.redis.setex(last_cleanup_key, 7.days.to_i, timestamp.to_s)
end
def last_cleanup
timestamp = Discourse.redis.get(last_cleanup_key)
timestamp ? timestamp.to_i : timestamp
end
def reset_last_cleanup!
Discourse.redis.del(last_cleanup_key)
end
protected
def last_cleanup_key
"LAST_UPLOAD_CLEANUP"
end
end
2013-10-14 08:27:41 -04:00
end