You can use a denylist to reject content types. Let's say we need an uploader that reject JSON files. A valid allowlist that will restrict your uploader to images only, and mitigate the CVE is:.
By default, CarrierWave provides only English letters, arabic numerals and some symbols as allowlisted characters in the file name.
It should return regular expression which would match all non -allowed symbols. Also make sure that allowing non-latin characters won't cause a compatibility issue with a third-party plugins or client-side software.
As of v0. You no longer need to do this manually. Often you'll want to add different versions of the same file. The classic example is image thumbnails.
When this uploader is used, an uploaded image would be scaled to be no larger than by pixels. The original aspect ratio will be kept. A version called :thumb is then created, which is scaled to exactly by pixels. One important thing to remember is that process is called before versions are created.
This can cut down on processing cost. Occasionally you want to restrict the creation of versions on certain properties within the model or based on the picture itself. The model variable points to the instance object the uploader is attached to. For performance reasons, it is often useful to create versions from existing ones instead of using the original file. If your uploader generates several versions where the next is smaller than the last, it will take less time to generate from a smaller, already processed image.
Often you'll notice that uploaded files disappear when a validation fails. CarrierWave has a feature that makes it easy to remember the uploaded file even in that case. In Rails, this would look like this:. It might be a good idea to show the user that a file has been uploaded, in the case of images, a small thumbnail would be a good indicator:.
If you want to remove a previously uploaded file on a mounted uploader, you can easily add a checkbox to the form which will remove the file when checked. Your users may find it convenient to upload a file from a location on the Internet via a URL. CarrierWave makes this simple, just add the appropriate attribute to your form and you're good to go:.
If you're using ActiveRecord, CarrierWave will indicate invalid URLs and download failures automatically with attribute validation errors. This option is effective when the remote destination is unstable. In many cases, especially when working with images, it might be a good idea to provide a default url, a fallback in case no file has been uploaded.
You might come to a situation where you want to retroactively change a version or add a new one. This uses a naive approach which will re-upload and process the specified version or all versions, if none is passed as an argument. When you are generating random unique filenames you have to call save! Calling save! To avoid this, scope the records to those with images or check if an image exists within the block. If you're using ActiveRecord, recreating versions for a user avatar might look like this:.
CarrierWave has a broad range of configuration options, which you can configure, both globally and on a per-uploader basis:.
If you want CarrierWave to fail noisily in development, you can change these configs in your environment file:. It's a good idea to test your uploaders in isolation. In order to speed up your tests, it's recommended to switch off processing in your tests, and to use the file storage. In Rails you could do that by adding an initializer with:. Remember, if you have already set storage :something in your uploader, the storage setting from this initializer will be ignored.
If you need to test your processing, you should test it in isolation, and enable processing only for those tests that need it. Processing can be enabled for a single version by setting the processing flag on the version like so:. If you want to use fog you must add in your CarrierWave initializer the following lines. Ensure you have it in your Gemfile:. The really important argument for my purposes to download instead of display in the browser is the :disposition which needs to be set to 'attachment' as opposed to 'inline'.
Since I'm not supplying the filename, perhaps this is the only way for me to provide that to the file being downloaded, but I'm not certain of this. Note that supplying the :id symbol with the id of the current resource provided the specific information needed to identify the resource in question.
I hope this helps someone else out. This must be very obvious to everyone else, because I did not find any basic tutorials on file downloading files. I'm still learning a great deal. Here is the new method that is working:. With these changes I no longer have to set the :type. Setting this to false seems counterintuitive based upon my reading of the function of this argument, however, doing so yielded the desired results of naming the file after the actual file name.
This gem apparently sets the mime-type guessed from the file extension in the filename. Stack Overflow for Teams — Collaborate and share knowledge with a private group.
Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Asked 8 years, 9 months ago. Active 4 years, 8 months ago. Viewed 8k times. I'm running: Rails 3. Improve this question. The Whiz of Oz 6, 8 8 gold badges 46 46 silver badges 80 80 bronze badges. Thank you so much. When retrieving versions, CarrierWave returns a list of declared versions which may or may not have been generated.
In contrast, Shrine persists data of uploaded processed files into the database including any extracted metadata , which then becomes the source of truth on which versions have been generated.
Shrine doesn't have a built-in way of regenerating versions, because that has to be written and optimized differently depending on what versions have changed which persistence library you're using, how many records there are in the table etc. However, there is an extensive guide for Managing Derivatives , which provides instructions on how to make these changes safely and with zero downtime.
Shrine doesn't have support for multiple uploads out-of-the-box like CarrierWave does. Instead, you can implement them using a separate table with a one-to-many relationship to which the files will be attached. The Multiple Files guide explains this setup in more detail. You have an existing app using CarrierWave and you want to transfer it to Shrine.
Let's assume we have a Photo model with the "image" attachment. This can be done by including the below module to all models that have CarrierWave attachments:. Now you should be able to rewrite your application so that it uses Shrine instead of CarrierWave you can consult the reference in the next section. You can remove the CarrierwaveShrineSynchronization module as well.
You'll notice that Shrine metadata will be absent from the migrated files' data. You can run a script that will fill in any missing metadata defined in your Shrine uploader:. When using models, by default all storages use :cache for cache, and :store for store.
0コメント