Monday, March 11, 2019

SugarCRM 101: Authentication

Did you know that Sugar supports 3 different mechanisms for authenticating a user upon them attempting to access the application? 

The authentication options are:


The Sugar option refers to the standard username/password combination an administrator can configure within Sugar, as described here:

If your organization maintains an LDAP capable server, such as Microsoft ActiveDirectory (AD), it is possible to utilize the AD user list to authenticate users attempting to access Sugar. Further details on configuring this option can be found here:

The third option, SAML, is similar in nature to LDAP in that the user list is maintained outside of Sugar, but access to Sugar can be obtained by providing a set of valid SAML credentials. Greater detail on using this option is given in this example:

These options provide a flexible authentication model for Sugar, but the options aren't mutually exclusive and their interaction can sometimes cause a bit of confusion.

For example, it is possible to configure a Sugar instance to use SAML and at the same time allow a user to access the instance by either providing SAML or standard Sugar credentials. It is also possible to configure Sugar such that the LDAP/SAML option is only applicable to certain users.

To alleviate some of that confusion, I have created the below flowchart to describe the process used by Sugar, taking into account the various authentication options that can be configured. 

Figure 1.1 - Authentication Process
I hope this helps answer some of your questions on authentication and Sugar.

Thursday, February 7, 2019

SugarCRM DevOps: Compression

Question: Which would download faster, a 3.5 MB sized file or one approximately 500 KB in size?

It is not a trick question. Without a doubt, our expectation would be that the smaller sized file would download faster, regardless of the speed of our network connection to the server. But how can we reduce the size of payload if we cannot trim the actual contents? A quick and easy way to reduce the size would be to compress the content to be sent in the response.

If we apply this principle to Sugar, the compression of payloads sent from the web server to the browser would result in a snappier user experience, due to faster retrieval of data and other necessary components. As a general rule of thumb, we should always implement a compression methodology in order to help us achieve the best experience possible.

But how can one determine if compression is enabled and being utilized by the web server hosting a Sugar instance?

The image in Figure 1.1 helps us answer that question.

Figure 1.1: Example ListView response

To answer our question we must examine the web requests exchanged between our web browser and the web server. This can be easily accomplished within Chrome by accessing the Developer Tools and reviewing the contents of the Network tab, as illustrated in Figure 1.1.

Wednesday, May 23, 2018

SugarCRM: More Customization Tips

In a previous post on the subject of customizations we explored some general tips and advice that help us avoid a variety of problems. We will continue this discussion, but this time around we will focus on JavaScript. More specifically, we will focus on the manner in which one can handle responses to requests made to the Sugar REST v10 API.

One may have a need to send such a request to:
  • Read an existing record
  • Update a record
  • Load a collection 
The Sidecar framework provides mechanisms for performing all of the above, such as beanObject.fetch(). However, the process for handling responses these methods generate is not readily obvious. Quite often, there is a tendency to rely on raw JavaScript to address such needs, for example, interacting with the xhr object as such:


Rather than using raw JavaScript, one should leverage the parameters that can be defined as part of the method. In the case of .fetch(), it would look similar to the following:

As illustrated in the code, an anonymous function is defined for the success: parameter. This is the code that will be automatically executed upon a response being received and is capable of interacting with the JSON response -- found in the data variable. 

Note that a similar approach can also be used to define an error anonymous.