Fragments and Freemarker

thumbnail
Christoph Rabel, modified 6 Years ago. Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
I just realized that I can write some freemarker code into a fragment template. But only some.

<div class="fragment_34426">
   <#assign name = 'Robert Paulson' /><br>
   His name is ${4 + 5}.<br>
   ${contentAccessorUtil}<br>
</div>

This shows:
<#assign name = 'Robert Paulson' />
com.liferay.asset.info.display.contributor.util.ContentAccessorUtil@64bf3b94
His name is 9.

I looked into the code (that's why I know that ContentAccessorUtil was injected) and I don't understand where the restriction comes from.
thumbnail
Olaf Kock, modified 6 Years ago. Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
Christoph RabelI just realized that I can write some freemarker code into a fragment template. But only some.

<div class="fragment_34426">
   <#assign name = 'Robert Paulson' /><br>
   His name is ${4 + 5}.<br>
   ${contentAccessorUtil}<br>
</div>
Quite annoying, if not critical: While typing this fragment, if you're not typing contentAccessorUtil in a single stroke, you'll find 27K of error message with stacktrace barfed into the console (started tomcat with "catalina.sh run"). I'd argue that it's not that critical that I'll need the full stacktrace, or not even a logged error message. The message should surface on the UI, not in the logs.

Currently, the UI only shows "An unexpected error occurred." (which is not selectable, thus not copyable). See attachment for screenshot (I'm about to type "themeDisplay.scopeGroupId", but haven't typed the final "d" yet). The other attachment is the full, over-ambitious, log message from my console.
thumbnail
Jorge Ferrer, modified 6 Years ago. Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
The usage of freemarker within fragments is considered experimental, which is why it is not documented. We were discussing adding a note in the documentation about it where we explain that it's experimental and also that you must use freemarker's alternative syntax to be able to use it. The reason is that the HTML code is parsed (using jsoup) and that doesn't play well with freemarker's default syntax.
thumbnail
Olaf Kock, modified 6 Years ago. Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
As the stacktrace in the log (see above) is quite significant, and the error message not helpful, and more than twice the size in DXP 7.1 SP1, I've filed LPS-94864 to at least get rid of the stacktrace, and hopefully get a more helpful error message.
thumbnail
Christoph Rabel, modified 6 Years ago. Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
That's quite interesting. But I think you should disable it for now.

As an editor, I can currently enter ${bla} and BAM, the fragment is broken. Or actually write freemarker code. The problem is that not only the html from the backend, but also the text entered by an editor is parsed. An editor simply should not be allowed to write freemarker code into a page.


Freemarker could be very useful, but only if I the data (including properties (image url, target) entered by the editor is added solely as variables. It should never be processed.
thumbnail
Jorge Ferrer, modified 6 Years ago. Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
Unfortunately it's not possible to entirely dissable it, because it's used by some aspects of the internal implementation.

I would like to revisit it and probably consider using a less powerful and easier to learn templating mechanism like Handle Bars. Any thought on that?
thumbnail
Christoph Rabel, modified 6 Years ago. Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
I am not sure you understand my concerns. It's not about the template language. Freemarker is just fine.
But any editor can enter freemarker code. In the text.

I can click on "10 users included" and start typing freemarker code. I don't need to have the right to create fragments or templates. No, I just need edit rights on a fragment page.

While there is always a certain element of trust necessary, since editors could add javascript to webcontent and when an admin clicks, use restcalls, ... But this is still a quite different league. To execute their own code on the server should not be possible for simple page editors.
thumbnail
Jorge Ferrer, modified 6 Years ago. Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
Ouch, I understand you now. It's definitely an undesired effect.

I've just reported it as https://issues.liferay.com/browse/LPS-94910 and have asked the team to prioritize its resolution.
thumbnail
Christoph Rabel, modified 6 Years ago. Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
This is not easy to fix, since the userinput is merged into the html before _processTemplate is called. So it is in general impossible to distinguish between userinput and backend code.

You can't even do things like adding <#noparse> to the content, since it will mess with other FragmentEntryProcessors and I could simply close it in the content. For "10 users included"  I enter  "</#noparse>...<#noparse> and defeat the protection.