Widgets should distinguish between JSON data needed by editors and JSON data needed for all site visitors

Most data associated with a widget is display-oriented. It is harmless to include it in data attributes whether the user has editing privileges or not, and widget players (such as the JavaScript-driven players that power slideshows and video widgets) rely on this information.

However, there are use cases for putting sensitive credentials in a widget. For instance one might store a user-editable username and password required to access a specific feed in a stock ticker widget.

Look at providing a way to distinguish the editable and non-editable cases when deciding which widget fields to include. Currently the filterForDataAttribute and filterOptionsForDataAttribute methods of widget managers only take an object; they should also accept a flag indicating whether the user can edit the widget in question so they can decide what additional information to omit.

[boutell]

I think I’ve come up with a better proposal.

Quick recap of the issue: right now we push all the editable data of a widget to a JSON data attribute, even if it’s not editable by the user. We do that so the play() method can access data, and we leverage that in the video player, among others. But, the widget data could be big or contain secrets like account credentials to fetch a feed. So exposing all of it all the time to everyone = bad.

I propose a new option for widget modules (not every apos.area call — just configuring the widget module itself, a one-time thing):

playerData: false

If set to false, there’s no data exposed in the JSON at all unless the user has editing privileges. We’d advocate this as a good practice unless you’re writing a javascript-based player that would benefit from some of the data being available to the play() method.

In which case:

playerData: [ 'url' ]

Would expose just that one property (again, unless the user has editing privileges for the widget). You could list as many properties as you wanted.

If you do nothing, playerData defaults to true (expose everything) for backwards compatibility. In 3.x, perhaps, we flip that.

What do you think @stuartromanek @bobclewell @austinstarin @agilbert @abea?

[boutell]

Nothing wrong with the existing way of formatting the attribute I think — as long as we make an explicit playerData array a requirement to get that behavior in 3.x. No playerData, no nothin’ (:

On Mon, Jul 9, 2018 at 6:08 PM, houmark [e-mail] wrote:

Thanks @boutell https://github.com/boutell — I will try to make time for creating a PR that implements the omit and will also try to write improved documentation for this.

In 3.0 this should for sure be refactored even when breaking, to ensure Apostrophe can render playerData in a more correct DOM type way using data attributes of the exact values one would need to use for a player, this way the JSON can be fully omitted for non-logged in users. This may required more configuration by the developer, but better that, than unwanted disclosure of information.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/apostrophecms/apostrophe/issues/998#issuecomment-403636132, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB9fUi6sQwCPf8I9GJbR9IHcTVKuMLnks5uE9RygaJpZM4PNnl9 .

–

THOMAS BOUTELL, CHIEF SOFTWARE ARCHITECT P’UNK AVENUE | [phone] | punkave.com