-
Notifications
You must be signed in to change notification settings - Fork 19
Previewing markdown #292
Comments
Taking the POST body seems fine, switching the content type from HTML to JSON is something I'd want to avoid. |
So you would prefer the simple solution, i.e. posting to |
we need to post to the action that is actually doing the transformation. I don't see the I think this should be a generic feature of the pipeline, to suppress the |
I wouldn't do this, otherwise you can never request a preview with a different selector or extension. |
If we do this, we need to be careful on the Fastly side. Making the first request with an Accept header can poison the cache, unless we vary on Accept (which reduces cache efficiency). We can handle it in VCL, just need to be aware of it. |
also, this issue is about how the pipeline should handle the request, and not how this is mapped in fastly :-) |
@rofe I think you can start with the POST reading-part and we can decide if JSON responses are really needed later. |
I think this is all wrong :-) operations like this, should actually be made against a (yet to be defined) helix-content API. |
we already have the POST part,. it works when we POST directly to the action. the problem is:
|
What's so bad about calling the action directly?
What's so bad about responding HTML? |
correct, see adobe/helix-simulator#179 and #235 |
how does the editing tool (or worse, the end user) know the action URL?
CORS. |
We can set the
Ask Fastly? Maybe through a |
The things that I'd look at for editing-optimized HTML output is:
|
for completeness: we don't have to set the |
Not sure if we really want to keep it that easy to find out the backend URL... |
Because by making your browser post to the preview action, an attacker can get it to render arbitrary HTML (potentially even JS), served from a trustworthy domain. If the response is JSON, which gets only rendered by the extension this would not work. |
@lkrapf I don't share the assumption that the editor is running on the same domain as the site and I'd also assume that the preview function itself requires authentication. |
Ah, so CORS is a different issue, independent of the content-type. Sorry for the confusion. |
Neither do I. The attack works as follows:
If the response is HTML you will get it rendered in the browser served from (even signed by) trusteddomain.com, with no indication where the content is originally coming from.
Then this attack turns into CSRF - which is yet another issue. I agree with @tripodsan. The best option would be to turn this into an API. |
Closed during backlog grooming session during hackathon. Reopen if needed or open a new one. |
(spin-off from #251)
Add either a dedicated pipe or extend the existing html pipe to take markdown from the POSTed request.body, proxy the html pipe, and wrap the generated output in a JSON object:
This would be a safe way to support live (read: "as you type") previewing of markdown using Helix (for example using a browser extension).
The simplest and most transparent solution would be to register a new pipeline to a
.preview.json
selector/extension combo, and have editing tools POST there.A more sophisticated solution would be to use a vendor specific mime-type like
application/vnd.helix.preview+json
in theAccept
header, so the POST could be made to the original (.html
) path, and pipe resolution would be handled by Fastly based on the header.The text was updated successfully, but these errors were encountered: