(Coming out of @yched's Twitter post, http://twitter.com/#!/yched/status/172871664059686913 re: formatters and sanitization).

The Services REST server/node resource currently responds to REST request's with a full JSON dump of the node property, including unformatted, unsanitized values, etc. This is not desirable for a few reason: it means the client could have access to unsanitized code, so a script could hijack the Backbone app render to print XSS exploits etc. into the page w/in a user's session, and site developers can't control the way content is displayed using field formatters, display modes, etc.

My sense of the ideal state is that admins would be able to specify a display mode for node's rendered via REST calls, and alternate display modes could also be retrieved using an argument sent with the REST GET request.

This seems like more of an issue on the Services/server side, since it involves updating the way Services responds to REST requests. We can also patch a solution on the client side, sanitizing the code as soon as we get it using the Backbone.Model.parse() method, but this could still be vulnerable to exploits.

Comments

yched’s picture

yched commented

including unformatted, unsanitized values, etc. This is not desirable for a few reason: it means the client could have access to unsanitized code, so a script could hijack the Backbone app render to print XSS exploits

Not only that, but also the fact that only drupal PHP runtime's check_markup() can make sense of a (text raw value + format) pair.
It so happens that text fields prepopulate a 'safe_value' key containing the check_markup()'ed value on field load, which then becomes available in the JSON sent to backbone - but that's only for text fields, and only for input formats in which all filters are 'cacheable'.

So yeah, having a way to leverage formatters sounds like a good idea, and using a dedicated view mode makes sense - for extra points, the view mode should probably be a parameter in the request

Although, formatters come with a catch too : some formatters can embed additional CSS or JS into the page (through '#attached' properties in render arrays), which I guess need to be accounted for in the returned JSON too.

This approach also means that the server side gets to generate the HTML for the individual fields - which does reduce the benefits of "client side rendering". But as (I think) you mentioned somewhere, we can't really expect to force formatters to provide a JS version in addition to the PHP version...

ethanw’s picture

ethanw commented

The safe_value property does look like the first place to look with this...perhaps in conjunction with some sort of _alter hook on the Services side?

In terms of JS, I think some "structured data" formatter could make a lot of sense for a range of applications. JSON might be one instance of many in which a Drupal backend is serving up a data format instead of markup.

yched’s picture

yched commented

Also, those very issues of "what to present in a JSON export of a node" have been debated for quite some time now, with no really satisfying outcome so far.

- #1136362: add metadata for image styles (for RESTful Web Services, which overlaps some of your solution, except it chose to stay away from the Services module)
- #1133984: Formatting fields values not only for html output.
- The long standing #145551: Enable loading and rendering into multiple formats (html, xml, json, atom, etc.)

What makes your case a little better is that the end goal is still to produce HTML in a web page, though. So formatters are an option.

yched’s picture

yched commented

Crosspost :-)

ethanw’s picture

ethanw commented

Thanks for the links, @yched. Reviewing those posts, as well as the threads comparing the two modules at #1042512: Why not use Services Module? and #745046: make use of entity metadata, I think this is certainly a crosspost of something, the question is what...and whether or not that ticket exists yet.

Following #145551: Enable loading and rendering into multiple formats (html, xml, json, atom, etc.), I think this module could provide some informative use cases. For functionality such as in-place editing, for instance, both formatted and unformatted field data values may be required, depending on the user's access level and desired action (e.g. formatted for displaying, raw for changing). Thus, I think the ideal solution here is permissioned access to raw entity data, with formatted entity data the default for users without "Access Full Object Data" permissions, or similar.

Unfortunately, at the moment we have Services for case 1 (full permissions) and RestWS for case 2 (formatted data), but I don't think either solution can provide for both use cases at present. The short-term solution to this will most likely be to provide both Services/Services Views and RestWS/Views Datasource flavors of Drupal Backbone (see http://echodittolabs.org/blog/2012/02/introducing-backbone-module-drupal...), with longer term solutions being working toward support for the above functionality in either of those contrib modules or the Field API/Entity API themselves.

ethanw’s picture

ethanw commented
Component: Code » Drupal/PHP Code

Changed component.