Posted by moshe weitzman on February 26, 2013 at 6:49am
9 followers
Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | rest.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | WSCCI |
Issue Summary
Imagefields do not currently work with the new REST GET/POST/PATCH/PUT operations.
The plan is to let clients POST a base64 encoded string containing image data. A new deserializer for imagefields will decode that stream and save to temp directory. The deserializer will then return a tempfile uri.
For model code, see how devel_generate does it at http://drupalcode.org/project/devel.git/blob/refs/heads/8.x-1.x:/devel_g... That code does a little trickiness which you can ignore, by pre-creating 5 random images and picking from those.
When implementing this, also note that imagefields support additional properties like alt text (and title text?).
Comments
#1
We had discussed creating this as a temp file stream and then passing that off to the field. When you create a temp file, is there any way it is accessible via HTTP? If so, I believe it could open up a vulnerability where a malicious script could be base64 encoded and then run. I don't know enough about the file system to be sure.
#2
It would be poor practice but I do think some sites put their temp dir within the docroot. So, your worry is well founded. I debugged our current file upload validation and the key function we have to mimic is file_save_upload. We have to mimic it because it is hard coded to work with uploads (i.e. the $_FILES superglobal).
The key bits from that function are
$file = entity_create($values);$validators = file_field_widget_upload_validators($field, $instance);
$errors = file_validate($file, $validators);
Unfortunately, this function seems to do a bit of validation of its own (file_validate_extensions, file_munge_filename(), file_validate_name_length) that are not contained within file_validate() call. As a first pass, I would just ignore this extra validation and rely on the file_validate() call.
Also, you will want a stream wrapper which is inline data, so you don't have to save the file before calling file_validate. See the data:// wrapper at http://php.net/manual/en/wrappers.data.php
#3
Add tag
#4
We discussed this on the REST call today.
I'm pretty sure that image fields are basically a special kind of entity reference, which reference a file entity. Thus, the URI should be a property of the file entity, which means that we can handle the relationship between the file entity and the referencing entity could be handled in the same way.
#5
We discussed this with quicksketch on one of the calls. He agreed that the API interaction should be to create the file entity and then use the entity id from that to make another call to create the node that points to it.
To do this, we need Entity API support for files, #1818568: Convert files to the new Entity Field API.
#6
Because supporting this in serialization is a separate issue, independent of REST, I created #1988426: Support deserialization of file entities in HAL.
For now, we should be able to put in a stub Normalizer that handles the current File class (which is not NG). This approach can be re-evaluated once File in NG.