-
Notifications
You must be signed in to change notification settings - Fork 0
How upload images in thumbor
Thumbor provides a /image REST end-point to upload your images and manage it.
This way you can send thumbor your original images by doing a simple post to its urls.
The table below show all configuration parameters to manage image upload :
| Configuration parameter | Default | Description |
|---|---|---|
| UPLOAD_ENABLED | False | Indicates whether thumbor should enable File uploads |
| UPLOAD_PUT_ALLOWED | False | Indicates whether image overwrite should be allowed |
| UPLOAD_DELETE_ALLOWED | False | Indicates whether image deletion should be allowed |
| UPLOAD_PHOTO_STORAGE | thumbor.storages.file_storage | The type of storage to store uploaded images with |
| UPLOAD_DEFAULT_FILENAME | image | Default filename for image uploaded |
| UPLOAD_MAX_SIZE | 0 | Max size in Kb for images uploaded to thumbor |
| MIN_WIDTH | 1 | Min width in pixels for images uplaoded |
| MIN_HEIGHT | 1 | Min width in pixels for images uploaded |
Thumbor comes with the /image REST end-point to upload disabled by default. In order to enable it, just set the UPLOAD_ENABLED configuration in your thumbor.conf file to True.
Thumbor will then use the storage specified in the UPLOAD_PHOTO_STORAGE configuration to save your image. You can use an existing storage (filesytem, redis, mongo, hbase...) or create your own storage if needed Creating my own Storage.
You can manage image putting and upload deletions simply set the the configuration parameters UPLOAD_PUT_ALLOWED and UPLOAD_DELETE_ALLOWED to True. This parameters are set to False by default for security reasons.
Assuming the thumbor server is located at : http://thumbor-server
When using the /image REST end-point to upload your image via the REST API :
curl -i -H "Content-Type: image/jpeg" -XPOST http://thumbor-server/image --data-binary "@vows/crocodile.jpg"
HTTP/1.1 201 Created
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Location: /image/05b2eda857314e559630c6f3334d818d
Server: TornadoServer/2.1.1
The image is created at http://thumbor-server/image/05b2eda857314e559630c6f3334d818d. It can be retrieve, modify or delete via this URI.
Assuming the thumbor server is located at : http://thumbor-server
When using the /image REST end-point to upload your images via a form, the user is free to choose the id of the image via the filename field :
POST /image
Content-Disposition: form-data; name=crocodile.jpg; filename=croco.jpg
Content-Type: image/jpeg
Content-Length: 822
should return :
HTTP/1.1 201 Created
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Location: /image/05b2eda857314e559630c6f3334d818d/croco.jpg
The image is created at http://thumbor-server/image/05b2eda857314e559630c6f3334d818d/croco.jpg. It can be retrieve, modify or delete via this URI using the REST API.
Note : a second POST will overwrite the created image, if the property UPLOAD_PUT_ALLOWED is true. A 403 Forbidden is return if UPLOAD_PUT_ALLOWED is false.
The first catch is security. You most surely don't want people all over the web messing around with your upload end-point. If you do want it to be open, skip to the next catch.
In order to ensure that thumbor remains secure, you must do something like only allowing the /upload route in your nginx or apache webserver for the local network, or something like that. Just be advised that the /upload route is NOT safe to expose to the web (specially if you allow PUTting to it).
The second catch relates to how thumbor stores loaded files. When an image request arrives, thumbor calls on the specified storage to find out if it needs to load it from a remote source (possibly Http which is really slow).
If it does not have it stored already it will load it from the remote source and then call on the specified storage to store it. The next time around, thumbor will already have the original, thus eliminating one round-trip to a remote source.
The problem here is that if you are using the upload end-point you possibly have the images in the local network and thus don't need to store them AGAIN. If that's your scenario, just use a mixed storage and set the MIXED_STORAGE_FILE_STORAGE to thumbor's null storage (thumbor.storage.no_storage).
On the other hand, if you are storing your originals in a cloud service like Amazon's S3, then it might be really good for thumbor if you use local storage (filesytem, redis, mongo or anything you can come up with) to improve the speed of the most recent images. If you come up with a cool storage, please feel free to contribute back.
The third and minor catch is about the verbs. You can read more about it in Posting, Putting and Deleting. It's important to understand each verb way of working.
If you need to save additional metadata (author, title, etc.) you need to store that information elsewhere. thumbor will only store image binaries.