Model View Controller - PHP

The MVC(Model View Controller) design breaks an application into three distinct layers:

1. Data management
2. User Interface
3. Logic

Model
Users, products, prices, messages catalogs, sitemaps e.t.c, it's all just data. You make sure the data is what you want, it goes into a database, then you have to get it back out. It will be useful for all the data-handling aspects to live in one place. That where model comes in.

Model is primarily concerned with handling data. Getting data from a database, inserting data into a database, validating data — all of this takes place within the model.

Best example is you have a User class, having variables such as username, password, email address, and other things. Some of its methods might be a new user creation function, a login function, an authentication function, and a logout function.
Later on, we will see how User objects will be used in the Controller part of your application. The Model, in essence, tells you what methods are available — what can you do to the data in the database. I thought I should just clarify (if it wasn’t clear already) — this should be all PHP code, just as what you should do in OO-programming even without MVC. There should be no HTML or any kinds of outputs (redirection, etc.) here. If doing an action means that a redirection is needed or some output is needed, pass it as an argument or a return value.

Here’s an example of the Model part of your code.

class student
{
var $name;
var $password;
var $class;
function student($u, $p, $e) // constructor
{
$this->name = $u;
$this->password = $p;
$this->class = $e;
}
function create()
{
// creates user in the db
}
function login()
{
// checks against db, does login procedures
}
static function authenticate($u, $p)
{
// checks against db
}
function logout()
{
// does logout procedures
}
}

View

Being able to save, retrieve, and validate your data is pretty useless without some means of displaying the data. By putting all display and presentation code in one place, you can change the look and feel of your application without having to work around application logic and data-related code.
View is primarily concerned with formatting data for presentation to the user. The view represents any and all UI work, including all templates and HTML.
Note:It is important that whatever PHP code in here is only what needs to be used to display the interface correctly. No additional “action” code belongs to the View — that is the Controller’s job, which we’ll see next.

<?php
require_once('student.php');
// Checking wherther student has been logged in or not
if (User::authenticate($_COOKIE['name'], $_COOKIE['password']))
{
header(”Location:/studentprofile.php”);
exit();
}
?>

<h1>Login</h1>
<?
if ($_GET['error'] == 1)
{
echo ‘Login incorrect. Please try again. ’;
}
?>
<form action=”login_action.php” method=”post”>
Student Name: <input type=”text” name=”name” />
Student Password: <input type=”password” name=”password” />
<input type=”submit” value=”Login” />

Controller
With data handling all contained within in the model, and the presentation layer all contained within the view, the rest of the application is going to live in the controller. This is where the application 'does' things — logic, decision-making, workflow, etc. The model manages your data, the view shows it to you, the controller does everything else.
The controller manages server requests. It accepts user input (URL requests, form POSTs, GET requests, etc.), applies logic where necessary, invokes models where data handling is required, and sends output through the appropriate view.Generally, a controller will manage logic for a single model. A controller contains any number of functions, referred to as actions. An action typically applies logic and displays a view.

For example you have a login page setup. The login HTML form has to submit to somewhere, right? (Even if you’re using AJAX) You don’t submit directly to the Model class file (say, User.php), because that file only contains the class code, and no actual procedural code is there, so it won’t do anything. You certainly don’t submit directly back to the View file (say, login.php), even if it ends with a .php extension! Because its job is only to display the interface.

This is what the Controller is. Your form will submit to a file, say, login_action.php. In this file, you create an instance of the User class, running whatever initialization you need, and calling the appropriate methods that need to be run (login).

<?php
require_once('student.php');
// in reality, a lot more error checking needs to be done.
$currentuser = new User($_POST['username'], $_POST['password'], ”);
if ($currentuser->login())
{
// set cookies for login info
header(”Location:/studentprofile.php”);
exit();
}
else
{
header(”Location:/login.php?error=1″);
exit();
}
?>

Leia Mais…

Read post array data

When working with the forms we are required to get all the form fields names and values at some point of time. In PHP the form values are returned in the form of array. We need to retrieve all the values in the form of pair(name,value) type.
This type of task will be used when we have hundred of variabes in a single form and we are confused with what form name the value is associated.

There are two ways to find the solutions:

1 method:

if ($_POST) {
echo htmlspecialchars(print_r($_POST, true));
}

2 Method:

foreach (array_keys($_POST) as $key) {
$$key = $_POST[$key];
print "$key is ${$key}
";
}

Leia Mais…

Php hacking techniques part 1

Techniques for securing user input, then extended those techniques to applications where database input and output is required, looking at some SQL security issues. next is to deal with file operations and file uploads, looking specifically at the security issues involved with accessing files based on some user supplied filename, and user-supplied files (uploaded files).


What Are Sessions?
Sessions are a PHP construct allowing persistent data to be retained across HTTP connections. In English, sessions allow you to store the values of certain variables across page visits. This is achieved by serializing the data (converting it to some binary representation) and writing it out to a file (or a database, or wherever you tell it), when a page is finished processing in PHP. When the next page (or that same page some time later) is processed, and PHP is told to start a session, it will check if the user already has a session, and read their data back in, unserializing it and assigning the variables. This allows you to keep track of a user across multiple visits, or while browsing multiple pages on your site.

For example, you can create a shopping cart using sessions, storing an array of items added to the cart in a session variable, and loading it on every page. When the user clicks 'Add to cart' you can add the item to the array, and it will be saved for the next page the user goes to. The whole array can be fetched on your checkout page and appropriate processing will take place.

How Do Sessions Work?
As many probably know, HTTP is a stateless protocol. By stateless, I mean that any HTTP connection is unaware of previous connections made by the same client, to the same server (persistent connections excepting). There are two useful ways in which PHP can pass identification information between pages in order to uniquely associate a user with a session.

PHP can use cookies to store a session ID. The cookie value is sent on every request, so PHP can match that up to its session data and retrieve the correct set of variables for that user. Another way is to pass the session ID in URLs. In order to do this, URL rewriting must be enabled.

Passing session data in URLs is not recommended since it is possible to pass your session onto another user if you give them a link which contains your session ID, and the session ID data is more easily attackable than in a cookie. URL-based session tracking should be used only where cookies cannot.

Using $_SESSION
PHP provides a super-global variable named $_SESSION. By super-global I mean it is a global variable which you may access without going via $_GLOBALS or stating global $_SESSION within a function. In this way, it behaves like $_GET and $_POST.

$_SESSION is, in fact, an associative array. The keys are variable names, and the values are the stored session data for that variable name.

Using $_SESSION is preferred over the use of session_register() to register ordinary global variables as session variables, especially when register_globals is enabled, since global variables may be more easily changed inadvertently than the contents of $_SESSION. It is still possible to alias ordinary global variables to their equivalents within $_SESSION,

$username = &$_SESSION["username"];

Here, the & indicates a reference, or alias. It is then possible to use $username instead of $_SESSION["username"], but note that $username is an ordinary variable, and you will have to access as $_GLOBALS["username"] or global $username from within a function.

Trusting Session Data
Since a session ID can be spoofed, it is always wise to perform some extra validation where possible. The simplest mechanism would be to store the IP address of the client to whom the session ID was issued, and compare the client IP against that stored IP every session. This will prevent the basic security problems associated with passing links between computers (though not if the computers are on a private network and share a single public IP address).

Session data is also stored in files on the server. The default location is /tmp on UNIX, or the system temporary file directory on Windows. If /tmp is world-writable (or, in some cases, world-readable), or there are multiple websites hosted on a single server, storing session data in a public location is not secure. PHP provides a way to change the way session data is stored.

Changing The Session File Path
The location in which PHP saves session data can be set using the php.ini directive session.save_path, or the string below in httpd.conf or a virtual host configuration.

php_value session.save_path "/home/test/sessions/"

It is important to ensure that your session data path is included in the paths allowed by open_basedir, if you have open_basedir settings or PHP Safe Mode enabled.

The data representation used for saving session data to files can be controlled with the session.serialize_handler directive in php.ini. By default, PHP uses its own built in format, but the WDDX ( http://www.wddx.org ) format can be used also. Set the type using one of the lines below.

(in php.ini ...)

session.serialize_handler wddx

or

session.serialize_handler php

(or in httpd.conf ...)

php_value session.serialize_handler wddx

or

php_value session.serialize_handler php

Storing Session Data In A Database
When you use on-disk files to store session data, those files must be readable and writeable by PHP. On a multi-user hosting system, it is possible for other users to access your session data through the PHP process (but see the commentary on open_basedir in part 5 of this series. The best way to secure your session data is to store it in a database.

Unfortunately, there is no direct way to store session data in a database using the php.ini directives, but luckily PHP provides a mechanism for customised session storage handlers. The function session_set_save_handler() allows you to register handler functions for session management. These functions must be written in PHP (or made available as a PHP extension).

session_set_save_handler(open_fn, close_fn, read_fn, write_fn,

destroy_fn, gc_fn)

To use these user-supplied session storage handlers, you must set session.save_handler to the value user, and the value of session.save_path should be the name of the database into which you're saving session data (so that the session save handler functions you define can locate and use that database). The value of session.name can be used as the name of the table within the database.

(httpd.conf)



php_value session.save_handler user

php_value session.save_path dbname

php_value session.name session_data



Next, a table for storing session data must exist in the database. At the minimum, your session handler should keep track of the session ID, the expiration time, and the serialized session data. The SQL below creates a simple table for storing this data.

CREATE TABLE session_data (

sessionid text not null PRIMARY KEY,

expiration timestamp,

sessiondata text not null

);

The final task is to create the functions which manage this session store, and register them with session_set_save_handler(). The open_fn must open the database connection, the close_fn must close it and perform any associated cleanup tasks, and the read_fn and write_fn functions must read and write session data respectively. destroy_fn is called when a session ends and is destroyed, and gc_fn is called when session data is garbage collected. These operations must be mapped into database queries by your PHP code. The prototypes for the functions are given below, and parameters passed are explained.

function open_fn($save_path, $session_name)

$save_path is the value of session.save_path, $session_name is the value of session.name

function close_fn()

Takes no arguments

function read_fn($session_id, $data)

$session_id is the session ID for which PHP requests the associated session data to be returned

function write_fn($session_id)

$session_id is the session ID for which PHP requests that $data be associated with in the session store (database)

function destroy_fn($session_id)

$session_id is the ID of a session which may be removed from the store

function gc_fn($max_time)

$max_time is the oldest last modified time to retain in the session store. Sessions with an older modified time than this are to be removed from the store.
-- Continued in Next pPrt

Leia Mais…

Php check File exists

When we are working with the directory structure we are in need of checking the files whether the file exists in the particular directory structure or not. In PHP we have the predefined function called file_exists() which checks the directory structure and returns a Boolean variable as the output. We can also check the file extension of the selected file also.
Here we may need only certain type of files to be displayed in a list of files. Like we may have the file name starting with "testing".

Below is an example which demonstrates the file_exists function and if the file exists then it checks for the file extension condition.


//==========
// Configuration
//==========
$directory = '/var/www/'; //Folder path
$lookingfor = 'testing'; //what to look for


$flag = false;
$ext = array( '.jpg' , '.gif' , '.png' );
for( $i = 0; count( $ext ) > $i; $i++ )
{
if( file_exists( $directory . $lookingfor . $ext[$i] ) )
{
$flag = true;
$name = $lookingfor . $ext[$i];
}
}

if( $flag == true )
{
echo 'found file!';
//echo $name;
}
?>

Leia Mais…