Skip navigation
All Places > Developer > Blog > 2018 > January
2018

Attention developers!  We’ve released Winter '18!  This is our second quarterly On-Demand only release, and we’re pretty excited about it.  Our Co-Founder & CMO, Clint Oram, discusses the highlights of this release from an end-user's perspective in the video below:

 

Matt Marum and I recently hosted a webinar where we gave an overview of the big things developers need to know about this release:

 

The slides from the webinar are available here .

 

If you’re looking for the CliffsNotes version, I’ve got you covered:

  1. Sugar has a new skin, and it’s fabulous.  No JavaScript changes were made as part of this reskinning.  For more information, check out Matt’s blog post: A new Sugar UX coming in Winter '18 .

    Before:
    Old look
    After:
    New look

  2. The Input Validation Framework that has been implemented since Sugar 7.7.1 is now enforced by default.  Input validation violations will cause FATAL errors.  See Matt’s blog post for more details:  How to fix Sugar input validation failures .  

    As part of enforcing the Input Validation Framework, all custom platforms must be registered.  If you have a customization or integration that uses our REST API, this probably affects you.  Check out my blog post  that has links to get more information about the change and a tutorial to help you register your custom platform.
  3. You now have the option of turning on denormalized team security, which can greatly improve List View performance.  Check out the Developer Release Notes or the webinar recording above for more details.
  4. We’ve added PhaserIO as a new library.  As a result, we’re seeing outstanding performance in the new Product Catalog Dashlet and great potential for speeding up other parts of the app.  Check out the Developer Release Notes for a list of all library changes.
  5. We’ve been working on an Exemplar App (https://github.com/sugarcrm/school) and the Sugar Synchronizer (https://github.com/sugarcrm/project-sync), which we hope will become key resources for everyone.  Watch the blog for more details coming soon!

 

This blog post promised to have just about everything you need to know about the Sugar Winter ‘18 release.  Below are some resources that have the rest of the details.

 

We hope you’re as excited about this release as we are!

What is the Input Validation Framework?

The Input Validation Framework is a centralized security framework used to validate that external input is provided in the expected format. Validating user input is critical because it is the basis for generated HTML and REST API output, used in the construction of SQL queries, used to access files, etc. Malicious input can be used to compromise the security of a Sugar instance and the underlying infrastructure. The validation framework provides better control than the pre-existing input sanitization techniques applied to user input within Sugar.

 

Fixing Input Validation problems

Sugar’s input validation was enabled but only logging failures as warnings into the sugarcrm.log file since the 7.7.1 release. With the Winter ‘18 release, the validation.soft_fail configuration setting will now default to false. This means that input validation checks will be strictly enforced by default instead of simply logging warning messages.

 

For more information about using validation constraints in your own custom code, check out the Sugar Developer Guide, the previous UnCon Security presentation, or the Winter '18 webinar.

 

Identifying input validation violations

Beginning in the Winter ‘18 release, input validation violations are reported as PHP Fatal errors in the PHP error log and Critical error messages in sugarcrm.log file. Invalid requests will generally be terminated with an HTTP 500 error as well.

 

Let’s walk through an example of an input validation violation.

 

In this example, we have a customization that is accessing the Sugar instance at the following URL: sugarcrm/ult/#bwc/index.php?module=xxxxx.

 

If xxxxx is not a registered module, there will be a FATAL error in the PHP error log.

For example,

[15-Jan-2018 22:04:09] WARNING: [pool www] child 1940 said into stderr: "NOTICE: PHP message: PHP Fatal error:  Uncaught exception 'Sugarcrm\Sugarcrm\Security\InputValidation\Exception\ViolationException' with message 'Violation for REQUEST -> module' in /srv/www/<instance>/prebuild/test/ult/sugarcrm/src/Security/InputValidation/Request.php:280"
[15-Jan-2018 22:04:09] WARNING: [pool www] child 1940 said into stderr: "Stack trace:"
[15-Jan-2018 22:04:09] WARNING: [pool www] child 1940 said into stderr: "#0 /srv/www/<instance>/prebuild/test/ult/sugarcrm/src/Security/InputValidation/Request.php(209): Sugarcrm\Sugarcrm\Security\InputValidation\Request->handleViolations('REQUEST', 'module')"...

 

The sugarcrm.log will also show an error.

For example,

Tue Jan 16 06:05:18 2018 [1941][-none-][CRITICAL] InputValidation: [REQUEST] module -> Invalid module xxxxx

 

From the end user perspective, these fatal errors will cause pages to appear blank or stalled during loading. If you inspect the browser console when this happens, you will likely see HTTP errors logged.

 

Fixing input validation violations

The steps to take to fix the violation are going to depend on the exact constraint that you are violating. Luckily the exceptions you find in the PHP error log and the messages in the sugarcrm.log will indicate the constraint that you are violating.

 

In the above example, attempting to access a BWC view for an unregistered custom module “xxxxx” is causing the failure. If you make sure that the module you are using is properly registered in Sugar’s module list, or modify your request to use an existing Sugar module, then this will fix this issue since the constraint is checking if the module name is a known modules installed in this Sugar instance.

 

There are basic Symfony framework PHP constraints that we use. These do not need an in depth explanation. The basic Symfony constraints can be used to validate URLs, date time formats, etc. Check out the Symfony documentation for these basic constraints.

 

In Sugar's implementation, we add our own set of validation constraints. These constraints extend from Symfony's Constraint and ConstraintValidator classes and are located in the ./src/Security/Validator/Constraints directory of your Sugar installation. Each Constraint is enforced using a related Validator class. You can inspect the Validator classes to see the precise logic that needs to be followed. For example, the Bean/ModuleName constraint is implemented by the Bean/ModuleNameValidator class. This constraint is used to ensure that the input is a string that matches the name of a valid module with an associated SugarBean class.

 

One of the basic rules that most of these constraints implement is that an input type should be a scalar. This means we expect most user input to be integer, decimal, string, or boolean values.

 

Sugar Constraints

The list provided below may not be exhaustive.

  • Bean/ModuleName
    • Must be a string. The Module’s SugarBean class must be retrievable using BeanFactory. For example, this is used in legacy Workflow.
  • ComponentName
    • Must start with a letter and may only consist of letters, numbers, hyphens and underscores. For example, this is used throughout Studio and Module Builder for module names, package names, and Sugar Logic functions.
  • Delimited
    • By default, must be comma delimited scalar values. For example, this is used in conjunction with other constraints.
  • DropdownList
    • Dropdown lists must only consist of letters, numbers and underscores. For example, this is applied to dropdown lists during module install.
  • File
    • File must exist in an allowed file path and must not include null characters or any directory traversals. For example, this is used by FileLoader utility class.
  • Guid
    • Must be a string with alphanumeric or dash characters. For example, this is used with SugarMVC Views.
  • InputParameters
    • General input validation for GET, POST, REQUEST superglobals. Must be scalar values and strings should not contain null characters.
  • JSON
    • Must be a string that is JSON decodable. Returns decoded PHP associative array. For example, used in Configure Navigation Bar Quick Create.
  • Language
    • Must be a locale code that matches an installed language. For example, this is applied where languages can be selected in UI.
  • LegacyCleanString
    • Reimplements input sanitization rules previously used with clean_string() function.
  • Mvc/ModuleName
    • Must be a string. A more permissive test than Bean/ModuleName that allows any module name that can be found in global module lists. For example, this is used throughout SugarMVC Views.
  • PhpSerialized
    • Must be a PHP serialized string that does not contain objects. Returns unserialized value.
  • Platform
    • Must be a string that is under 128 characters and contains alphanumeric and dash characters. Must be a known Platform value such as “base”, “mobile”, “portal”, etc., or one registered using Platform extension. For example, this is used to validate REST API login requests.
  • Sql/OrderBy
    • Must be a string that represents a valid ORDER BY SQL clause. For example, this is used in SugarMVC list views.
  • Sql/OrderDirection
    • Must be a string that is uses SQL keywords “ASC” or “DESC”. For example, this is used in SugarMVC list views.
  • SugarLogic/FunctionName
    • Must be a string that only uses word characters and dashes. For example, this is used in Sugar Studio.

 

If you encounter a failure, then you should be able to identify the constraint that you are violating from your error logs. By looking at log messages that appear immediately before the failure, and possibly some exploration in the Sugar user interface, you will be able to identify the failing request. From there, you can use the information above to alter the request to comply with the necessary constraints.

 

This is not a substitute for Sugar field level validation!

An important thing to note about the Input Validation Framework is that it is not the only input validation mechanism available. For example, there is still separate field level validation that occurs when users create or edit records. Sidecar customizations or Studio configuration can still be used to perform validation of user provided input for each field of a record in a user friendly way. For example, Sugar will let you save a record without filling out required fields and will display a user friendly warning that tells user what to correct. The Input Validation Framework is centered around security and does not provide the same usability than you would get validating user input using Sidecar or Studio settings.

 

In Sugar 8 / Spring '18, Sugar administrators can now configure API platforms using the Administration panel. The Platform extension is still available if you want to register a custom API platform as part of a Module Loadable Package.

If you have a REST API integration with Sugar, you are likely using a custom platform as part of that integration. Beginning in the Winter ‘18 release, Sugar is enforcing a rule that all custom platforms must be registered in each Sugar instance where a custom platform is used.  For more details on the rule itself, see Matt’s earlier blog post: Unknown platforms to be restricted in Winter ‘18 release.

 

The bad news?  This change that requires all custom platforms to be registered probably affects you.

 

The good news?  There is an easy fix, and I’ve written a tutorial that walks you step-by-step through how to implement the fix.

 

Check out the tutorial here!

The Sugar Winter '18 release is fast approaching! Hopefully you are as excited about the new Sugar UX as I am!

 

As usual, Lauren Schaefer and I will be hosting a developer webinar to help get you and your customers prepared for the new Winter '18 (7.11) release. Please read below to learn more about the agenda and do not forget to register! We run these webinars twice, so no matter where you are in the world, we hope that one of these times will be convenient for you.

 

Winter '18 Technical Webinar Agenda

 

Technical Training AgendaWebinar Times
  1. Impacts of new interface
  2. Sugar Exemplar app (more below)
  3. Restricted REST API platforms (more below)
  4. Removal of some LESS files
  5. Emails subpanel changes
  6. Input Validation Framework (now the default)

Monday, January 22nd 4-5:00 PM PT
Tuesday, January 23rd 8-9:00 AM PT

Register Here

 

We will be posting the webinar recordings and deck to the Partner Portal for those who are unable to attend the live sessions.

 

Sneak peak of Sugar Exemplar app


The new Sugar Exemplar app is designed to demonstrate best practices for developing Sugar customizations (think DevOps and QA!) and a solid example of what upgrade-safe customizations should look like. We’ll tell you more about the app and how you can get involved during the webinar!

 

Reminder about restricted REST API Platforms


ISVs and developers who use a platform string to connect to a Sugar instance will need to update their existing API integrations. For more information - please refer to this blog post on how to to proceed.

 

Get on our developer mailing list!

 

Remember to opt-in for Sugar Developer communications to make sure you don't miss this and other important updates.