Archives For REST

Posts about the Sugar 7 REST API

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 7.7.0.0 and 7.7.1.0. 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…

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 7.8.0.0

Continue Reading…

Important security changes in Sugar 7.8

As we near the release of Sugar 7.8, we wanted to update the Sugar Developer community on a couple of important security changes that are coming in this release.

Continue Reading…

Sugar REST PHP Client

A new open source library for working with Sugar 7’s powerful REST API has just been published! You can view the library in our GitHub account here: https://github.com/sugarcrm/rest-php-client

Full instructions for installation, usage, current included API Endpoints, and ways to contribute can all be found in the GitHub Wiki on the repository.

Who should use it?

The Sugar REST PHP Client was built initially to make working with Sugar instances easier for some of our internal tools. I wanted to provide a quick, easy, and object oriented, way to access Sugar 7’s REST API that could be used by all PHP developers. Any developer who is developing PHP applications that integrate with Sugar 7 should be interested in using the new library. The simplified architecture takes away the hassle of setting up and managing Curl connections, and allows the developer to focus on what matters most, which is working with the data in their Sugar application.

Continue Reading…

At SugarCRM, we have been accelerating the rate at which we share technology with the Sugar Developer community. Back in June at UnCon, we shared more open source code examples and tools than ever before. In April, we announced Sucrose Charts and the Sugar REST Harness. I am pleased to announce that we have open sourced three more projects under the Apache-2 license!

Continue Reading…

UPDATE July 24 2017

Sugar 7.9.0 introduced a Platform extension. This should be used for registering new platform identifiers for Sugar 7.9.0 and beyond.

What does the platform parameter mean in v10 REST API?

If you open your web browser’s network tools, a login request to the v10 REST API used in Sugar 7.6 will typically look something like the example below.

POST /rest/v10/oauth2/token HTTP/1.1
Host: localhost
Cache-Control: no-cache
Content-Type: application/json
{
     "grant_type": "password",
     "username": "admin",
     "password": "admin",
     "client_id": "sugar",
     "platform": "base",
     "client_secret": "",
     "current_language": "en_us",
     "client_info": {
         "current_language": "en_us"
     }
}

You can see in the request that we have specified a platform parameter called “base”. This parameter is optional (the default is base) so even if you have used the v10 REST API before you may not have been aware of it or what it means.

Continue Reading…