Wednesday, January 18, 2017

Elasticsearch: Heed the Warnings

A few posts on this blog have talked about different topologies one can use to deploy Sugar, either for development purposes or production use. Perhaps the most important point in those posts is the matter of ensuring that one should not expose the Elasticsearch server to any other machine besides the one where the web server is running.

Because Elasticsearch data can be read without any sort of user authentication, exposing an Elasticsearch server means one is allowing potentially malicious users to view sensitive data. Despite this risk, it is not uncommon to hear of Sugar implementations that are configured in ways where Elasticsearch can be directly accessed via the internet or local network. 

A few days ago, the dangers of such a configuration were further highlighted by ransomware makers. Reports have recently surfaced that data from exposed Elasticsearch servers is indeed being compromised and held hostage.

This threat may leave some Sugar administrators wondering about the impact this could have on their Sugar implementations and data. 

Thursday, December 22, 2016

SugarCRM Reference: Analyzing a Record page

As a continuation of a prior post, below is a diagram depicting the various components used on the record page within Sugar 7.

Not unlike other areas of Sugar 7, a variety of layouts and views are used to render this screen. In a follow-up post we will take a closer look at specific areas of this same diagram as there is more info to be had.

Wednesday, May 18, 2016

SugarCRM: Working with Sugar 7 Sessions

One of the changes that was introduced in Sugar 7 relates to the manner in which user sessions are managed. 

In older versions of Sugar, the length of a user session was determined by a PHP parameter that controls the lifetime of a PHP session. For all intents and purposes, a Sugar session was equivalent to a PHP session and deleting the latter would in turn cause your Sugar session to also be destroyed.

For the Sugar 7 release, this process was changed and a Sugar user session is now primarily controlled by means of a series of OAuth tokens. Those of you that have worked with the REST v10 API should be familiar with the topic, but even if you have not, the information contained herein should still be of help. 

A common question that is asked in relation to sessions in Sugar 7 is: how does one change the lifetime of an OAuth token? 

By default, the access_token has a lifespan of 1 hour and the refresh_token, used to obtain a new access_token, lives for 2 weeks.

A brief description of the manner in which the tokens are used follows...