Archives For PHP

In our most recent set of security releases, we made some changes in Sugar that address input sanitization issues reported by a 3rd party security researcher. Conveniently, these issues can be addressed with the input validation and CSRF form authentication frameworks added in Sugar and Both of these frameworks offer “soft” failure modes that will log warnings into the sugarcrm.log instead of fatal exceptions.

Input Sanitization Soft Failures

CSRF form authentication is strictly enforced by default. But, up until now, the default for the input validation framework has been to use soft failure mode. Choosing to make soft failure mode the default was a pragmatic decision to maximize compatibility for Sugar customizations while developers updated customizations and integrations. However, these recent reported vulnerabilities make it clear that it is time to take the next step to more strictly enforce input sanitization.

SugarCRM plans to strictly enforce input validation in upcoming releases. We will also remove the soft failure mode options at that time which will break customizations or integrations that have not adopted CSRF form authentication or pass that do not pass input validation.

Strict enforcement of Input Validation and CSRF Form Authentication

You should enable strict enforcement of the Input Validation and CSRF Form Authentication checks now for two reasons: (1) to ensure that your Sugar customizations and integrations work properly after upgrading to our winter releases and (2) to create the most secure environment for your current users. The configuration settings in question are the Input Validation ‘validation.soft_fail’ flag as well as the CSRF ‘csrf.soft_fail_form‘ flag.

Sugar Cloud has disabled soft failure modes by default but for Sugar On-Site you can adjust these settings for yourself. Add the following lines to your config_override.php file.

$sugar_config['validation']['soft_fail'] = false;
$sugar_config['csrf']['soft_fail_form'] = false;

Strictly enforced checks

In response to security issues, there are now strictly enforced input validation checks that ignore the validation.soft_fail configuration setting. In particular, we added strict validation to the platform authentication parameter used in our REST API. This can have an impact on platform identifiers using characters that are not part of the POSIX portable filename character set.

Also recall the disable_unknown_platforms configuration setting affects the use of platforms. Custom platforms should be registered using the Platforms extension. This check is planned to be enforced in Sugar On-Demand in the future as well.

What you need to do to prepare customizations

In development instances,

Set validation.soft_fail setting to false.

Set disable_unknown_platforms setting to true.

Then run regression tests on your integrations and customizations to very they still work.

In production instances,

Enable warn log level to collect and analyze any input validation or platform name violation warnings.

Other Resources

Slides from the UnCon 2016 session on Sugar’s input validation framework are also available in the Sugar Community.

More information about best practices for using the Platform parameter can also be found on a previous post on this blog.


Here is an important message from David Wheeler, a long time Software Engineer and Architect at SugarCRM, about using e-mail fields correctly.

E-mail handling is core to CRM software. Almost everyone we know uses multiple e-mail addresses every single day for both personal or work purposes. So it goes without saying that managing a person’s multiple e-mail addresses correctly is essential in your Sugar customizations and integrations.

History of Sugar E-Mail fields

Several years ago, Sugar changed from using email# named text fields (like email1, email2, etc.) to using an e-mail relationship. This was done to better handle multiple e-mails, multiple relationships, and e-mail attributes like opt in or invalid.

However, use of the email1 field remains particularly persistent. We observe many examples of custom code (and some core code) that still use the old email# fields. This is probably because it is convenient to use the email1 field like a regular text field.

But this is out of date, inaccurate, deprecated, and subject to removal in upcoming Sugar releases.

Below we will describe the proper method for using e-mail fields within Sugar customizations and integrations.

Continue Reading…

An Advanced Workflow process can only be triggered once per PHP process or HTTP request. This is intended to prevent Sugar Administrators from defining infinitely looping processes. (A real catastrophe!) But what does this mean for PHP customizations?

Assume that you have an Advanced Workflow process enabled for the Contacts module that performs an update on this Contact each time it is saved. If you have an Accounts after_save logic hook that performs an update on each related Contact SugarBean then the process will only run against the first related Contact. Any other related Contact that gets saved during your logic hook execution will not have a process run.

This affects not just logic hooks but any other class of PHP customization such as custom API endpoints or jobs.


If you really need to run that process more than once in the same request, here is a workaround:

use Sugarcrm\Sugarcrm\ProcessManager\Registry;

Calling this method will clear the internal Advanced Workflow registry that keeps track of the triggered process starts. After calling this method, the same process can then be triggered again inside the same PHP process or HTTP request.

Careful use of this method can make sure that PHP customizations play nicely with processes defined in Advanced Workflow.

What are Prepared Statements?

Prepared Statements, also known as parameterized statements, is a database feature that allows the same or similar queries to be executed with more efficiency and greater security. It has also been a common Sugar platform feature request for some time.

A prepared statement looks something like this:

SELECT * FROM table WHERE id = ?

As you can see, a prepared statement is basically a SQL template that allows you to identify parameters that can be bound later. The database engine can parse, optimize, and cache this statement without executing it.

This reduces the overhead associated with parsing complex queries that are used frequently by applications like Sugar. For example, you can imagine that List View queries would benefit from prepared statements since they are often complex and executed each time a list is displayed, searched, filtered, or paginated. With prepared statements, the database will do less work each time one of these actions is repeated.

Continue Reading…

This post originally appeared on the SynoLab blog hosted by Synolia, an Elite SugarCRM Partner. Yann Bergès describes how you can use a relate filter with the Filter API. He also explores how Sugar does it as well as identifying a drawback to be considered when using this feature.

We all know the moment when you are roaming through source code to find something for a particular purpose and you come across that feature you didn’t expect but you absolutely want to test. This is how I came into the related link filter feature. What do I mean by related link filter? It is a derivative way to filter related data on a One-to-Many relationship by specifying a link name and a target field:

I want all Contacts filtered on their related Account with « Industry » value « Electronics » (use « one » side of the relationship)
I want all Accounts filtered on their related Contacts with « Title » value « President » (use « many » side of the relationship)

This is an advanced use of Sugar 7 Filter API, if you never used it before, have a look at this documentation for detailed information about how filters work:
– SugarCRM Cookbook – The School of REST – Part 3
– Sugar 7.8 Developer Guide – Architecture – Filters
Examples and tests have been made with a Sugar instance PRO

Continue Reading…

This blog will be the first in a two part series on building Charts components for Sugar 7. This post is targeted at beginner to intermediate Sugar Developers who want to learn how to build their first Chart component.

This post assumes some basic knowledge of Sugar 7 development, Sugar 7 administration, JavaScript, and PHP.  This information should be useful to anyone who has an interest in Sugar 7 development.

The examples in this post were created on an out-of-the-box installation of Sugar Professional  But this technique should work on any on-premise Sugar 7 instance.


You may have noticed that a number of out of the box dashlets and views contain various fancy charts and visualizations.  This is possible because Sugar has a charting component build into it.  You can make use of this to display charts within your own custom dashlets, views or layouts.

In this post, we will focus on the “LineChart” type. There are other chart types that use different data formats and chart options but the general techniques covered here will work for all chart types.  These examples were implemented in a basic custom view but they will also work within dashlets.

Continue Reading…

Here is another Francesca Shiekh guest post! She is a Sugar Developer from Wolfram Research.

We had the need to notify the assigned user when an email was received that was related to a Case record. To make our application more flexible we extended this concept to be reusable for email received that was related to any module. We then further broke out the notification functions to be reusable in other scenarios.

Continue Reading…