[Vtigercrm-developers] email double encoding

[Joe Bordes]

We ran into a case once with one of our clients where this happened from 
time to time. They couldn't reproduce it consistently and there was a 
modified customer portal present too, so we couldn't debug it. It could 
be the same problem or not.
In the end we ended up doing something similar to what you propose but 
we pass it through the vtlib_purify() function before sending it to the 
browser because that function uses http://htmlpurifier.org to clean the 
code.

In case you want to add that.

Joe
TSolucio


El 28/01/14 11:08, Alan Bell escribió:
> Hi all,
> not sure if anyone has seen this situation, but we have some emails 
> that we think were probably caused by a Microsoft Word to Outlook mail 
> merge that have been encoded as html entities, then added to vtiger 
> with the outlook plugin, so opening the email in the vtiger UI 
> presents the html source. I don't have a reproduceable scenario as I 
> don't use Windows, but the description field in vtiger_crmentity 
> starts with:
>
> <!--[if gte mso 9]><xml>
>  <o:OfficeDocumentSettings>
>   <o:AllowPNG/>
>
> so that is rendered when you click on the email in vtiger as
> <!--[if gte mso 9]><xml>
>  <o:OfficeDocumentSettings>
>   <o:AllowPNG/>
>
> which the users don't really want to see.
> To fix this I have edited Smarty/templates/EmailDetailView.tpl and 
> changed the rendering of the description (line 70) to show:
> {$elements.value|html_entity_decode:2:"utf-8"}
>
> rather than just {$elements.value}. This means it decodes the text 
> before rendering it, this appears to be a harmless operation on emails 
> that contain actual HTML rather than escaped HTML so all the mails 
> display right. I suspect this might create a security problem though, 
> any escaped javascript would now be executed in the browser, which is 
> probably bad.
>
> Has anyone else seen this, and does anyone have a better solution to it?
>
> Alan.
>