github-mirror/discourse
2
0
Fork 0
mirror of https://github.com/discourse/discourse.git synced 2024-11-25 22:33:37 +08:00
Code Issues Actions 6 Packages Projects Releases Wiki Activity
db15e11cb9
discourse/app/serializers/upload_serializer.rb

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

33 lines
815 B
Ruby
Raw Normal View History

DEV: enable frozen string literal on all files This reduces chances of errors where consumers of strings mutate inputs and reduces memory usage of the app. Test suite passes now, but there may be some stuff left, so we will run a few sites on a branch prior to merging
2019-05-03 06:17:27 +08:00
# frozen_string_literal: true
Initial release of Discourse
2013-02-06 03:16:51 +08:00
class UploadSerializer < ApplicationSerializer
FEATURE: image uploads now have short urls Shorten all image uploads to use short urls, this is the client side implementation.
2017-08-23 04:40:01 +08:00
attributes :id,
:url,
:original_filename,
:filesize,
:width,
:height,
FEATURE: correctly store width and height on uploads Previously we used width and height for thumbnails, new code ensures 1. We auto correct width and height 2. We added extra columns for thumbnail_width and height, this is determined by actual upload and no longer passed in as a side effect 3. Optimized Image now stores filesize which can be used for analysis, decisions Also - fixes Android image manifest as a side effect - fixes issue where a thumbnail generated that is smaller than the upload is no longer used
2018-08-28 10:48:43 +08:00
:thumbnail_width,
:thumbnail_height,
FEATURE: image uploads now have short urls Shorten all image uploads to use short urls, this is the client side implementation.
2017-08-23 04:40:01 +08:00
:extension,
:short_url,
FIX: add short_path to upload_serializer (#9417) What problem I am trying to solve? When an encrypted message is crafted and the image is added - discourse needs a hard refresh to display that image. What is happening? Everything starts here - when the upload is finished we add serialized object to the cache https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/components/composer-editor.js#L748:L757 Then, `discourse-encrypt` is trying to get an image from the cache and use `short_path` property https://github.com/discourse/discourse-encrypt/blob/master/assets/javascripts/discourse/initializers/hook-decrypt-post.js.es6#L142:L143 Why is it working after a hard refresh? After refresh, we populate cache once again using that function: https://github.com/discourse/discourse/blob/master/app/assets/javascripts/pretty-text/upload-short-url.js#L11:L17 And lookup_urls method from backend is returning `short_path` https://github.com/discourse/discourse/blob/master/app/controllers/uploads_controller.rb#L55:L64 TL;DR We should expose short path in upload serializer. I ensured that this serializer is used only when attachments are uploaded so it should not affect performance.
2020-04-15 07:19:59 +08:00
:short_path,
UX: Lightbox support for image uploader. (#7034)
2019-02-21 10:13:37 +08:00
:retain_hours,
UX: Use dominant color as image loading placeholder (#18248) We previously had a system which would generate a 10x10px preview of images and add their URLs in a data-small-upload attribute. The client would then use that as the background-image of the `<img>` element. This works reasonably well on fast connections, but on slower connections it can take a few seconds for the placeholders to appear. The act of loading the placeholders can also break or delay the loading of the 'real' images. This commit replaces the placeholder logic with a new approach. Instead of a 10x10px preview, we use imagemagick to calculate the average color of an image and store it in the database. The hex color value then added as a `data-dominant-color` attribute on the `<img>` element, and the client can use this as a `background-color` on the element while the real image is loading. That means no extra HTTP request is required, and so the placeholder color can appear instantly. Dominant color will be calculated: 1. When a new upload is created 2. During a post rebake, if the dominant color is missing from an upload, it will be calculated and stored 3. Every 15 minutes, 25 old upload records are fetched and their dominant color calculated and stored. (part of the existing PeriodicalUpdates job) Existing posts will continue to use the old 10x10px placeholder system until they are next rebaked
2022-09-20 17:28:17 +08:00
:human_filesize,
:dominant_color
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-16 11:50:27 +08:00
DEV: serialize image upload thumbnail (#29276) Since we recently blocked accidental serialization of AR models, we are getting a 500 error in some cases with thumbnails. We can fix this by serializing the thumbnail, previously we just returned a raw OptimizedImage object. Thumbnails are now attached to the serializer in core, therefore we no longer need to use add_to_serializer within the chat plugin to use thumbnails within chat message uploads.
2024-10-18 16:55:14 +08:00
has_one :thumbnail,
serializer: UploadThumbnailSerializer,
root: false,
embed: :object,
if: -> { SiteSetting.create_thumbnails && object.has_thumbnail? }
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-16 11:50:27 +08:00
def url
DEV: Rename secure_media to secure_uploads (#18376) This commit renames all secure_media related settings to secure_uploads_* along with the associated functionality. This is being done because "media" does not really cover it, we aren't just doing this for images and videos etc. but for all uploads in the site. Additionally, in future we want to secure more types of uploads, and enable a kind of "mixed mode" where some uploads are secure and some are not, so keeping media in the name is just confusing. This also keeps compatibility with the `secure-media-uploads` path, and changes new secure URLs to be `secure-uploads`. Deprecated settings: * secure_media -> secure_uploads * secure_media_allow_embed_images_in_emails -> secure_uploads_allow_embed_images_in_emails * secure_media_max_email_embed_image_size_kb -> secure_uploads_max_email_embed_image_size_kb
2022-09-29 07:24:33 +08:00
if object.for_site_setting
object.url
DEV: Apply syntax_tree formatting to `app/*`
2023-01-09 20:20:10 +08:00
else
DEV: Rename secure_media to secure_uploads (#18376) This commit renames all secure_media related settings to secure_uploads_* along with the associated functionality. This is being done because "media" does not really cover it, we aren't just doing this for images and videos etc. but for all uploads in the site. Additionally, in future we want to secure more types of uploads, and enable a kind of "mixed mode" where some uploads are secure and some are not, so keeping media in the name is just confusing. This also keeps compatibility with the `secure-media-uploads` path, and changes new secure URLs to be `secure-uploads`. Deprecated settings: * secure_media -> secure_uploads * secure_media_allow_embed_images_in_emails -> secure_uploads_allow_embed_images_in_emails * secure_media_max_email_embed_image_size_kb -> secure_uploads_max_email_embed_image_size_kb
2022-09-29 07:24:33 +08:00
UrlHelper.cook_url(object.url, secure: SiteSetting.secure_uploads? && object.secure)
DEV: Apply syntax_tree formatting to `app/*`
2023-01-09 20:20:10 +08:00
end
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-16 11:50:27 +08:00
end
Initial release of Discourse
2013-02-06 03:16:51 +08:00
end
Reference in New Issue Copy Permalink