And he was referring to a post we did where we did some raw SQL queries in the code example. I’ve updated the code examples since then to be correct. And Jeff don’t worry, as you rightfully so called us out on slipping a bit from our normal quality here :-).
But to start off, why is this important? Here’s a few reasons…
Code portability. Even the most conservative SQL code can have issues on a DB you haven’t tested you add-on against. If…
You have found yourself in a bind, and you need to query the database directly. There is no other recourse than to write a query to get the data you need. This cookbook entry is going to give you some examples on how to use our new SugarQuery API instead of direct SQL.
1. What is SugarQuery?
SugarQuery is a SQL query builder for retrieving data directly from the database. It is used extensively within the core of the application. For instance, the FilterAPI uses it.
It uses a bean, the beans relationships, and visibility models to build a SQL query that can be used to retrieve data.
2. The Basics
SugarQuery has a very simple interface for building queries.
The basic methods you will need to create a query are:
select($fields) – accepts an array of fields you would like to select
from($bean) – validates the query against a SugarBean at generation
Many of you who develop modules on SugarForge or for your own Sugar instance often find the need to add in administration functionality for it. This maybe use to control features or functionality of the module, or perhaps define some defaults that are used in the module. Fortunately, the ability to add these panels as a part of the existing admin section is a very easy and upgrade-safe task.
You can define new admin items in the custom/Extension/modules/Administration/Ext/Administration/ directory, creating a new .php file in that directory to hold the admin items. There are two parts to defining this; in the first part we will define the actual admin panels we will be adding.
You may recall seeing this field in the various activity modules in Sugar:
This is what’s known as the “Flex Relate” field, which allows you to relate a record to one in a different module that you specify. This allows you to create a relationship where the target entity is flexible, which allows you to represent all sorts of business logic clearly. A great example of this the various activity entities in the app ( Calls, Meetings, Tasks ), which make it so you can relate the activity to one of many different record types.
The only downside of this field, is there’s no good way to build it using Module Builder or Studio ( or least in a very useful way ). However, it’s a pretty easy code customization you can do which is upgrade-safe. Let’s look at how.
We’ll assume we made a new custom module via Module…
An XSS attack is one of the top most tried out attacks on a PHP enabled system and your PHP script may not be immune.
Sadly , many developers fails to deliver a secure code thus open to attacks.Every programmer should consider such attacks and vulnerabilities and try to make the program or script free from getting attacked.
Let me give you an example which will explain you how does such attacks happen.
Below is an index.php page with the following code.
<form method="post" action="save.php">
<input type = "text" name = "name">
<input type="submit" name="submit" value="Save">
In the above html code there is a simple form with a textbox and submit button.On click of the button the form is submitted to save.php for further processing.
A genuine user will fillup his/her name but an attacker can inject code instead of name.
Suppose on save.php just prints out the name.
Suppose instead of writing a plane name the attacker inputs <script>alert(‘HaHa You are attacked!!’);</script>.
If the scripts are not filtered the user will see the popup with message “HaHa You are attacked!! “.
Types of XSS Attacks
Non-Persistent : The kind of attack shown in the above example falls under this category.It means attacks in which the code is not actually stored on the server but is rather presented to the user.
Persistent : This attack is more dangerous one in which the code is actually injected into server.
Hopefully this article gave you a good explanation of what cross-site scripting attacks are.Never trust data coming from the user or from any other third party sources.In my next post I’ll explain how these attacks can be prevented.