How To Re Cap Beer Bottles

Privacy & Development Web

Current privacy laws (and common sense) require that application development is done in order to protect access to sensitive data to people who actually do have permission. According to guidelines, the development expected to create the database views and queries that, according to the user level, giving access to a given set of information. This approach, in my opinion, it is very costly in terms of resources and of the time actually available for development, is not easily achievable. What I want to propose here is an alternative method to develop web applications that meet those needs quickly.

The application uses PHP as a programming language as it may be applied to any other programming language. SQL queries are reported by MySQL.

The first phase of this development should be the development of a strong set of functions that carry out the functions of authentication and authorization. This set of functions must perform the tasks proposed below. Assign some functions of names, so you can draw in the sample code that I'm proposing.

authentication function

This feature should always be present. It can not be omitted, it must support a control mechanism that verifies the existence and the correctness of the credentials, the account was activated or not. In terms of application code this feature can be omitted because the handling of credentials can be delegated to the Web Server (basic authentication, etc.). As more manageable and integrated with other authentication systems or single sign on (eg. IIS and Active Directory) that are easier to control and already have a strong system of accounting control user (password expiration, complexity, etc.).

function authorization management

This in contrast to that component, however, is indispensable. The function gives the user a "level" of authorization that across the entire application, provides the user access to certain components or content. The function will load in session (not cookies!) The levels of permission that must be accessible. At the logon user supplied set of credentials will then be compared with the level of the user, and its "Authority token is saved in session. Every time you want to publish a component (an anchor, a record, even a single label), the program will determine whether or not the user is authorized to access that information using the "token" as a method of comparison.

How do we handle the data access?

Suppose you have a master data table structured like this: CREATE TABLE

tbl_pazienti (

ID_paziente INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

nome_paziente VARCHAR (45) NULL,

codice_fiscale CHAR (15) NULL,

address VARCHAR (45) NULL,

location VARCHAR (255) NULL, province CHAR

( 2) NULL,

state CHAR (3) NULL DEFAULT "ITA",

phone VARCHAR (20) NULL,

codice_assistito CHAR (10) NULL, PRIMARY KEY

(ID_paziente)

)

Under the Guidelines, each "level" of authorization should create a view that gives access only to a limited data component. Programmatically, then, should we make a series of control structures that, depending on the user level, loads the appropriate view. The commitment to permission management becoming expensive, while adding a new level of approval would require the least intervention of a DBA (if the code is structured properly).

implement the method described in this article, however, we are going to handle all application layer. Through a configuration panel you can configure the parameters of "authorization." The process of creating a new permission level includes the following steps:

1. Creating the permission level
2. For each table we are going to define which column the user can see and which not (a boolean)
3. Save changes

The above operation can be done easily by any user who has the appropriate credentials for access to the administration, and must not be either a DBA or a programmer. In terms of code instead? All exactly the same. Let's see how.

Starting from the SELECT statement that queries the database, let's load the record of a particular patient.

SELECT t.nome_paziente, t.codice_fiscale, t.indirizzo, t.localita,

t.provincia, t.stato, t.telefono, t. codice_assistito

tbl_pazienti FROM t WHERE

t.ID_paziente

= 25 LIMIT 1;

The query returns a record only with the patient demographics. Now we see the application code.

The rule of RAD (Rapid Application Development) to see data that says we have to make a structure like this:

$ q = "SELECT .....";

$ r = mysql_query ($ q);

$ data = mysql_fetch_array ($ r);

# Other code

print ($ data ["nome_paziente"]);

not want to upset the rule of the rapid application development, rather, we want to keep. Then we replace only one function of the whole set this: the print () function.

Our new feature (which I will call GetElement ") does nothing but make the output of an element's content $ Date, but before doing so, checks whether the user has permission to view this element. According to the above example, therefore, that we wrote the code that we will be more like the following example:

$ sql = "SELECT ....";

$ obj-> query ($ sql);

# Other code

print $ obj-> GetElement ("nome_paziente");

Conclusions

The advantage of this programming method is that the developer can develop applications quickly, without regard for the concept of authorization. The system described can be applied to any element of the program as labels, elements of form, anchors, etc.. Development of the guideline within the administration making a complete split between the user who must receive an application, and the development group that must act on it instead of adding new features. When an end user needs to modify a permission level, the proposed system is sufficient to ask the person who deals with the management level which is normally a person who knows the internal optics business. If we used the views, however, we would have to call a DBA or developer, with the logical consequence of having to wait for a longer period of time for editing (and possibly bug because the change is made on the code).

There are aspects of security and privacy (this one is linked to the health care world that fascinates me a lot lately) I have not covered since they are mainly in arguments Systems. These elements are the communication between database and application servers, and between application servers and network clients, data encryption on the disks of the database, and any encryption data within the database tables. Maybe will be the subject of another article:)