Characters altered when saving custom data.

[tgramil]

I recently upgraded from beta 2 to beta 5, and only found this behavior after the update.
(the update went fine, by the way)

I have a set of custom data fields which include files and alphanumeric items.
I update the entries in a tab under the appropriate organizational contact without having made a profile.
When I include the character < or the character > in the alphanumeric item  and then save, this character gets translated
to  &lt; or &gt; in the mysql database.  This conversion prints correctly (as < or >) when viewed on the contact page, (but is clearly not correct in the database).  If I then save some other item, the character is further altered and becomes &amp;lt; etc.
and it no longer prints correctly on the contact's page.  Each time I save something another &amp; gets added in front,
I have managed to get up to a dozen &amp; 's

For beta 2, the < just stayed as it was  -- which was good for me, since I acces this data in some custom drupal forms, and embedding a <br> in my data allows me to put linebreaks in my forms.

Any ideas or suggestions?  Thanks in advance....
Tom G.

[Dave Greenberg]

Tom - This behavior is caused by new code which was added as an extra safety against the possibility of cross-site scripting strings being added across multiple fields.

http://issues.civicrm.org/jira/browse/CRM-5667

What type(s) of custom fields are you adding HTML tags to?

(I'll need to discuss this with other folks on the team to see if there's some way to accommodate this, other than having you disable this protection.)

[tgramil]

Hi Dave, thanks for the quick info.

The Data Type is Alphanumeric, and the Field Type is Text.

This seems to also preclude text like: '6 < 7'
which gets converted also....

The data is getting referenced in a complex, multi-form (pdf), multi step registration
process that I have put together as a custom drupal module.

It was really nice to format some of it using embedded html tags as stored in those custom data variables....

I look forward to hearing whatever advice you eventually might be able to provide!

[tgramil]

So I'm wondering how I go about disabling this protection. 
(ie. CRM-5667 Fix potential XSS vulnerabilities related to adjacent fields)

It seems to also prevent html tags from being included  in the Pay Later Instructions  of event configuration --
which makes formatting an address really problematic.

Please let me know....
     Thanks!  Tom G.

[Dave Greenberg]

Tom - I've just committed a change (which will be part of 3.1 stable) which skips encoding on Pay Later Instructions (events and contribs). Side note that this text is used both on Confirm / Thankyou pages AND in email receipts - so HTML formatting isn't a good idea if you are sending text emails to some participants. However, since 3.1 will send HTML formatted emails to folks unless their Mail Format pref is Text only - this would work for you.

Folks are thinking about a solution for your custom TEXT field issue - but not sure if there will be a solution other than modifying the code. The functions which control the encoding are exportValues() and filterValues() in packages/HTML/QuickForm.php.