Style definition in Wiki pages no longer works

[rschmidt]

Hi all,
we use alfresco share and we have updated to version 3.2r2.
After that, it seems, that if you create a wiki page and you use a style formatter (e.g. to change the font size or to color a specific word) this style definition will not be saved with the page.
It is a bug or is there anywhere a configuration setting to change this behaviour?

/Rainer

[mikeh]

I took a quick look at this. It's due to the stripUnsafeHTML() function in stringUtils being updated to a third party solution. I guess it's stripping too much now.

[update] Note this is only a workaround. The style attribute is open to XSS attacks in Internet Explorer. We'll look at putting TinyMCE in a different mode to use css classes instead of the style attribute.

The workaround is as follows…

Create the following folder structure for the Tomcat where Share is deployed:

shared/classes/alfresco/web-extension/site-webscripts/org/alfresco/components/wiki‍

In the wiki folder, create a file called page.get.config.xml containing the following:

<wiki>
   <allowUnfilteredHTML>true</allowUnfilteredHTML>
</wiki>‍‍‍

If you had the web-extension folder before this fix, you should just be able to reset Share web-scripts, otherwise restart Tomcat in order for the extensions classpath to be picked up.

Thanks,
Mike

[durrell]

That does the trick for the formatting. Thanks a lot.

Any idea when the Share dashlet problem might be fixed?

This:

[img]http://imgur.com/A3Hee.png[/img]

[mikeh]

Good point! Do the same thing for the dashlet, but using:

shared/classes/alfresco/web-extension/site-webscripts/org/alfresco/components/dashlet‍

In the dashlet folder, create a file called wiki.get.config.xml containing the following:

<wiki>
   <allowUnfilteredHTML>true</allowUnfilteredHTML>
</wiki>‍‍‍

Thanks,
Mike

[kevinr]

This issue has now been resolved (without a work-around). Latest code in HEAD (for 3.3 release) and will also be available in the 3.2.1 Enterprise service pack.

Thanks,

Kev

[durrell]

This is broken again in 3.2r, even with the work-around in place. I've restarted Tomcat several times and it just refuses to work. Any ideas?

[kevinr]

It was not fixed in 3.2r - as per my post above. It will be available in 3.2.1 (Enterprise) or 3.3 Community or current HEAD codeline. I haven't tried the workaround so I can't comment on that.

Kev

[durrell]

Thanks for the info. Any info on a release date for 3.2.1 Enterprise?

In the interim..it would be nice to get the workaround working again.

[durrell]

I dug around a little in the webscripts and found what it was calling.

File: org/alfresco/components/dashlets/wiki.get.config.xml

Changed the value to true and that fixed it.

[analyzediz]

Along the same lines, I'm not quite sure the logic behind not including <pre> tags as one of the safe HTML tags. I was looking at org.alfresco.web.ui.common.StringUtils and sure enough it was excluded from the list.

I'm trying to add the capability for users to post code samples into the tinyMCE control. I have created a plugin that work just as expected and when I save my edited content it makes it all the way into Alfresco. I know this because I can preview the content from the Alfresco Web Client. But once retrieved, the stripUnsafeHTML calls in out of the box FreeMarker templates just discards the <pre> tags. Is there a minimally invasive approach to extending the behavior of this class to allow additional html tags to be cosidered "safe"?

Thanks for any pointers.

[kevinr]

I will update the whitelist to include PRE for 3.2.1E/3.3, from my investigations and testing it is safe to include. There is no way to add tags to the list via config yet - it is something we can look at adding, if you raise a request in JIRA.

Thanks,

Kevin