Actually, I think this is applicable for all versions of Broadleaf.
If you want to disable the XSS protection completely, you can override the blExploitProtectionService bean in the admin. So somewhere in your applicationContext-admin.xml file:
Code: Select all
<bean id="blExploitProtectionService" class="org.broadleafcommerce.common.security.service.ExploitProtectionServiceImpl">
<property name="xssProtectionEnabled" value="false" />
</bean>
This will disable all of that cleaning. Alternatively, you could provide your own antisamy policy file. The one that we are using is at
https://github.com/BroadleafCommerce/Br ... -1.4.4.xml so you could use that for reference. If you go this route, it probably makes the most sense to just copy this file into your own project and modify it as needed.
If you go that route, you'll need to tell the exploit protection service to load this file instead:
Code: Select all
<bean id="blExploitProtectionService" class="org.broadleafcommerce.common.security.service.ExploitProtectionServiceImpl">
<property name="antiSamyPolicyFileLocation" value="classpath:your-antisamy-policy.xml" />
</bean>
Finally, you could just override the bean with your own class and override the cleanString and cleanStringWithResults method to just return the string:
Code: Select all
public class PassThroughExploitProtectionService extends ExploitProtectionServiceImpl {
public String cleanString(String string) throws ServiceException {
return string;
}
public String cleanStringWithResults(String string) throws ServiceException {
return string;
}
}
And then override that bean definition with your custom class:
Code: Select all
<bean id="blExploitProtectionService" class="com.yourcompany.admin.exploit.service.PassThroughExploitProtectionService" />
The first and 3rd are obviously the least restrictive and easiest, while the 2nd option is more difficult but still affords you some protections. What you need depends on your specific use cases.