1) MySQL via Homebrew

If you haven’t heard of Homebrew, your world just got a whole lot more kickass (especially if macports drives you nuts). The perfect little package manager for OSX with a great community behind it. They’ve made it so simple that those who have never spent much time in terminal will still feel comfortable installing programs. You’ll need Xcode or Command Line Tools for Xcode, but from there it’s an easy installation. Then, simply open terminal and type “brew install mysql”, follow their post-installation instruction (about the root password and installing database) and viola! Type “mysql start” in terminal and you’re set up. The client I use is Sequel Pro, which is an incredibly clean MySQL client for Mac and it’s free. When you login, remember to use the socket connection, username “root” and the password you set up with mysql’s post-installation instructions.

2) Virtual Hosts

It’s more of a personal choice to use a program to help me set up virtual hosts, really. For those unfamiliar, this gives you the ability to point your browser to local web files via a custom URL, like “codeigniter.site” points to “/Users/dave/Dropbox/Web Sites/CI/user_guide/” – CodeIgniter’s user guide installed to my computer. (Yeah, I use .site and .test, just a personal preference). MAMP did it fairly well before but I really love VirtualHostX. It’s clean, powerful, and just does what it’s supposed to without getting in your way. It plays perfectly with Mac OSX’s built-in Apache. At $40 it’s a little expensive but I always think it’s worth purchasing great software from indie developers. He’s a great guy and I loved his blog post about experimenting with people pirating his software.

3) Code Development Client (bonus)

I love Panic and their web development program Coda. It was a great relief to use such a great piece of software (that didn’t cost a fortune *cough ADOBE cough* that was so clean and worked pretty well. That said, it has it’s quirks which they’re clearly aware of because last I heard they’re completely revamping for Coda 2. One late night I stumbled onto Sublime Text and it was glorious. It supports pretty much everything and is so light weight. I love the cross-platformness too, just in case I ever get roped into using Windows for an employer. It walks the line of a no-frills (yet still beautiful) interface while packing some serious heat under the hood. It has a bunch of quality themes and extensions – even a package manager you can add.

CLOSING NOTES:

• One of my first annoyances with Apache was that errors were turned off. Go to terminal and type “pico /private/etc/php.ini” and change “error_reporting” to “E_ALL | E_STRICT” and “display_errors” to “On” (scroll way down).
• You may get an error when connecting to your database in PHP (and I’m assuming other scripts as well). Connecting to “localhost” doesn’t seem to link to the IP “127.0.0.1″ correctly. You can Google solutions to fix this; I just use the IP instead.
• For what it’s worth, I prefer Chrome for browsing, Transmit for FTP, and backup my web files by saving them to Dropbox.

As you probably know, Jolicloud is a neat little netbook OS built on top  of Ubuntu’s netbook OS to run web apps natively. I opted to run it on an old Dell Inspiron 1720 as an easy-to-use and free OS for my brother to use (as letting him try full-blown Ubuntu wasn’t exactly working out) since he only needs it for the web and music. After taking Jolicloud for a test spin via a burned ISO and meeting my brother’s approval with all systems go (wifi working perfectly fine) I installed it. Everything went smoothly until realizing – uh oh! – the network manager wasn’t showing any nearby wireless networks, nor was I able to connect via manually entering one. Checking all obvious obstacles (hardware switch, BIOS settings, right clicking on the network manager applet and ensuring wireless was enabled, etc) and coming up empty handed, I searched trusty Google for answers to make it all better. While there was no direct answer to my issue with Jolicloud per se (I have to admit, their Help section is rather ridiculous – if you need help, their answer is “ask the Ubuntu guys.” Not exactly the most user friendly support for software directed at the average consumer), fortunately after much searching and reading I was able to piece together the solution for this particular issue.

1. Check that your wireless card is Broadcom

• Press Alt+F1 To bring up Terminal.
• Type “lspci -vvnn | grep 14e4″
• Check to see that your network controller is from Broadcom and take note of the wireless card model (“BCM43xx”). Mine, for instance, is BCM4312.

Click here to view the Blueprint sample page with this jQuery button added (upper right hand corner).

Add this to the head of sample.html (or your own page you want to add this to) …

<script type="text/javascript" src="jquery-1.6.2.min.js"></script>
<script type="text/javascript" src="blueprint-grid.js"></script>

(remember to include your jQuery file)

blueprint-grid.js …

/*
	blueprint grid v1.0 - For Blueprint CSS Framework (http://www.blueprintcss.org/)
	(c) 2011 Dave Rogers (http://shinytype.com), freely distributable under the terms of the MIT license:

		Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated
		documentation files (the "Software"), to deal in the Software without restriction, including without limitation
		the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software,
		and to dpermit persons to whom the Software is furnished to do so, subject to the following conditions:

		THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
		THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
		AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
		TORT OR OTHERWISE, ARISING FROM, OUT OF OR 	IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

	Based off less grid v4.0 (c) by Arnau March (http://arnaumarch.com/) - also under MIT License
*/

$(document).ready(function() {
	createSwitch();
});

function createSwitch() {
	$('body').append('<span id="toggle-button">o</span>');

	// floating toggle button
	$('#toggle-button').css({
							position: "absolute",
							top: "0",
							right: "0",
							background: "#3d5fa3",
							border: "2px solid #fff",
							borderTop: 0,
							color: "#fff",
							fontSize: "13px",
							lineHeight: "13px",
							padding: "2px 8px 6px 8px",
							cursor: "pointer",
							"border-radius": "0 0 5px 5px",
							"-moz-border-radius": "0 0 5px 5px",
							zIndex: 1000
	});
	$('#toggle-button').toggle(function() {
		$(this).text("x");
		$(".container").toggleClass("showgrid");
	}, function() {
		$(this).text('o');
		$(".container").toggleClass("showgrid");
	});
}

…or…

Download source files

blueprint-grid-v1.0.zip (173 kb)

CodeIgniter has a lot of great date functions (aka, “helpers“), but none really fit the bill to make it really simple to convert PHP time (seconds since Unix Epoch) to MySQL’s datetime format, which is really the best way to store dates (so you can still leverage all of MySQL’s great date functionalities). So, I made one to extend CodeIgniter’s date helper…

Add “MY_date_helper.php” to ‘/application/helpers/’ with the following code:

<?php  if (!defined('BASEPATH')) exit('No direct script access allowed');
/**
 * Extends date helper to return current time in MySQL datetime format
 * By Dave Rogers
 * Shinytype.com
 *
 * @access	public
 * @param	string (optional)
 * @return	string
 */
function mysql_datetime($date=null) {
	if(!$date) {
		// use now() instead of time() to adhere to user setting
		$date = now();
		}
	if(is_numeric($date) && strlen($date)==10) {
		return mdate("%Y-%m-%d %H:%i:%s", $date);
		}	else	{
		// try to use now()
		return mdate("%Y-%m-%d %H:%i:%s", now());
		}
	}

/* End of file MY_date_helper.php */
/* Location: ./application/helpers/MY_date_helper.php */

Note that it goes in your application helper stack rather than system helper. This will still extend the default helper, but since it’s in your application folder (which I personally abstract from the system folder, which I rename to it’s corresponding version number, to make upgrading CodeIgniter simple as well downgrading in the case of a bug) it will not get lost or overwritten when you upgrade CodeIgniter. Also note the “MY_” prefix. This is the default custom helper prefix, if you have changed it (“$config['subclass_prefix']” in config.php) then cascade that prefix accordingly.

The functionality of this helper is as simple as it looks: take PHP time and reformat it to MySQL’s datetime format. If no date is passed to the function, it simply uses the current time with CodeIgniter’s “now()” function (also available in the date helper), which is essentially a simple wrapper for PHP’s own “time()” function except it takes into account your master time reference setting (“$config['time_reference']” in config.php) and sets the time in accordance.

How you reference this helper:

$this->load->helper('date');
echo "the current datetime is ".mysql_datetime();

Which displays as:

the current datetime is 2010-06-23 00:12:30

Example with a date passed in:

mysql_datetime('1277277150');

Datetime to PHP’s Time Format

If you want to turn a datetime into PHP’s unix epoch format (the opposite of the above), you can add this function to the same file (before the end of file lines):

// --------------------------------------------------------------------

/**
 * Take a MySQL datetime var and turn it into PHP's Unix Epoch time
 *
 * @access	public
 * @param	string
 * @return	int
 */
function datetime_to_unix($date) {
	if(!$date) {
		return false;
		}	else	{
		return date('U', strtotime($date));
		}
	}

With this function, a parameter is required…

$this->load->helper('date');
echo datetime_to_unix('2010-06-23 00:22:23'); // returns 1277277743

Pretty painless, right?

Full Source

Here’s the full file if you’re just looking for a quick copy and paste…

MY_date_helper.php

<?php  if (!defined('BASEPATH')) exit('No direct script access allowed');
/**
 * Extends date helper to return current time in MySQL datetime format
 * By Dave Rogers
 * Shinytype.com
 *
 * @access	public
 * @param	string (optional)
 * @return	string
 */
function mysql_datetime($date=null) {
	if(!$date) {
		// use now() instead of time() to adhere to user setting
		$date = now();
		}
	if(is_numeric($date) && strlen($date)==10) {
		return mdate("%Y-%m-%d %H:%i:%s", $date);
		}	else	{
		// try to use now()
		return mdate("%Y-%m-%d %H:%i:%s", now());
		}
	}

// --------------------------------------------------------------------

/**
 * Take a MySQL datetime var and turn it into PHP's Unix Epoch time
 *
 * @access	public
 * @param	string
 * @return	int
 */
function datetime_to_unix($date) {
	if(!$date) {
		return false;
		}	else	{
		return date('U', strtotime($date));
		}
	}

/* End of file MY_date_helper.php */
/* Location: ./application/helpers/MY_date_helper.php */

Introduction

One feature many popular sites implement is persistent login, or the ability for a user to stay logged in for long periods of time – well beyond the time they last visited the site and subsequently closed their browser. Many basic login protocols web developers put in place either deal with cookies, which is valid until the date the web developer has specified, or sessions, which are only valid until the browser is closed. Clearly, they are very different options, each with their own pitfalls…

Cookies:
Pros – Set it and forget it; simply check for the cookie and make them login if it doesn’t exist
Cons – All data is viewable to the client and can be modified or stolen; a savvy user can easily mimic your cookie pattern and attempt to gain access maliciously

Sessions:
Pros – Completely server-side, users cannot view or modify data; simple for a web developer to set, modify, and reference
Cons – Only lasts as long as the browser is open; no native expiration option if the user leaves their browser open indefinitely

If only there were some way to leverage the better qualities of the two, right? Enter the persistent login protocol. Intertwining cookies, sessions and a database is not a new concept. Drupal, a very popular PHP CMS, uses the same concept in a popular module. While reading up on various protocol designs, I noticed little holes in each of them. Many were good, none were great. My design takes pieces of various protocols and betters them as well as adds a bit of functionality that hadn’t existed in any of them. Ideally the concepts and sample code should plug into any existing system utilizing unique user IDs stored in a database. I’m not going to delve into the concept of persistent login too much here; there are some great articles listed at the bottom of this page for you to read more about them if you’d like.

Requirements:

• PHP 5.2 server
• Intermediary knowledge of PHP (understanding of cookies, arrays, sessions, etc)
• MySQL 5 server
• Comfortability administering MySQL and understanding of database design

General Overview

The overall concepts are simple.

1. User successfully logs in
2. A “token” is issued – cookie, session, database
3. On every page view, the token is verified between the session and cookie
4. When the session has expired, issue a new token
5. Assume token forgery or theft if the three token sources do not match up and remove ALL sessions for this user in the database.

Here is a design of the protocol to help you visualize the whole process flow:
Persistent Login Protocol Design (.png)

Makes sense, right?
You may be thinking “wait, but in PHP, sessions only expire with the browser!” This is true! It’s something that most persistent login protocols do not take into account in a way that is less database intensive than reissuing the token on each page load. I’m definitely not a fan of that, especially when you want your application to scale well. Instead, I have a session set as an array with the following parameters…
- UserID
- Token
- Expiration Time

For the expiration, I set it to “seconds since the Unix Epoch” plus 900 seconds (or 15 minutes) and every time there is a page load, it checks whether that is the current time or not. Fairly simple implementation, no crazy date functions to mess with.

Sample Code

I do want to encourage you to look over sample code and determine whether or not it is secure enough for your system. It may not be. I wanted to avoid putting in too much extra code and functionalities that would overwhelm the subject I’m writing on here. This is why it’s referred to as sample code. Use at your own discretion.

First we’ll build the table in the database to store session tokens. Notice the “Active” field – it’s only purpose is to track legacy tokens and if someone tries to access the system with an inactive token, we know that it’s forged/stolen and we can take action against it.

CREATE TABLE `Users_Sessions` (
  `SessionID` int(10) NOT NULL AUTO_INCREMENT,
  `UserID` int(10) NOT NULL DEFAULT '0',
  `Token` varchar(50) NOT NULL DEFAULT '0',
  `DateIssued` datetime NOT NULL,
  `Active` int(10) NOT NULL,
  PRIMARY KEY (`SessionID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='User session mappings';

We’ll also go ahead and build a table for users and insert a username (with the password “password” that is md5 encrypted) so you can play with this protocol right away…

CREATE TABLE `Users` (
  `UserID` int(11) NOT NULL AUTO_INCREMENT,
  `Username` varchar(50) NOT NULL,
  `Password` varchar(50) NOT NULL,
  PRIMARY KEY (`UserID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

INSERT INTO Users (Username, Password) VALUES ('Bob', '5f4dcc3b5aa765d61d8327deb882cf99');

Now we’ll tailor the settings to whatever we want…
tokenSettings.php

<?php
// database connection settings
$server		= 'localhost';
$username	= 'root';
$password	= 'root';
$database	= 'myDB';

// display errors - for testing only
$ShowErrors	= false;

// general settings
$TokenName		= 'MySiteToken';
$SessionExpire	= '15';		// in minutes
$CookieExpire	= '365';	// in days

//////////
// connect to the database
mysql_connect($server, $username, $password) or die(mysql_error());
mysql_select_db($database) or die(mysql_error());
?>

Here is the rest of the sample code:
Persistent Login Protocol Assets (356 kb)

Included files:

• functions/clearToken.php: function to clear tokens in the database, session and cookie
• functions/issueToken.php: function to issue/reissue tokens
• functions/validateToken.php: heart of the system; it reviews the database, session and cookie tokens and determines what action to take per the protocol flow
• tokenSettings.php: file to modify settings (see above)
• tokenInclude.php: file to include on every page that requires authorization; takes action recommended by validateToken and executes it
• test.php: file for you to view token settings (session, cookie), how long before the session expires, current recommended action (for testing only)
• login.php: login example to aid in your testing
• logout.php: logout example to aid in your testing
• PersistentLoginProtocol.png: design of protocol flow

Unzip to your testing environment, add tables (code above) to database, commence testing. One thing I haven’t included is a way to flush old sessions out of the database after a set period of time. I figure that the developer implementing this process can easily handle that themselves.

Closing Thoughts

a. This is a working sample that should be regarded as a proof of concept rather than a production-ready plugin. Although tested quite a bit, it hasn’t seen production-like usage and so it’s regarded as experimental right now. If you find anything that can be improved upon (within the scope of the exercise) or have a contribution, please comment or contact me.

b. Another thing to keep in mind is that, while rare these days, some users still don’t allow cookies. This protocol depends a great deal on cookies being enabled, so if you run into this situation it would be advisable to make persistent login an option upon login and have the protocol fall back to a session-only login when cookies cannot be set. That’s generally a good fall back rule regardless.

c. While, like I said before, this is a focused prototype, some cool/useful options you can build in could include…

• When a user’s token has been found to be compromised and all tokens for that user have been cleared, upon the next successful login from that user you can display a notice that their session was compromised along with the IP it came from. This can be useful in aiding the user in determining what they have done or where they have been that could be undermining their security.
• Tracking IP addresses to uniquely identify “strains” of sessions so a user or administrator can see how many active sessions a user has and even log out from them.
• Implement a “save state” feature where a user can resume their last session when they login along with what they were last doing. Note that this would require a database call on each page load, nullifying the effort made to keep from doing that with the session expiration functionality; although an ajax call could be made upon modifications to make it a little more intuitive.

d. Lastly, remember that security isn’t just about making an air-tight front line, there’s also a very important concept of security depth. Requiring your user to verify with a login before performing major tasks like editing user information, viewing billing information, etc is a great way to improve security in the case that someone makes it past the first line of defense. Sure, you don’t want to be so locked down that the user isn’t having a good time using your application, but with the sensitivity of those tasks, they’ll understand why it’s important to login.

Thanks for reading this article! If you like it (or have any other comments), please comment below! Thanks!

More great articles on Persistent Login protocols…

• Persistent Login Cookie Best Practice, Charles Miller
• Improved Persistent Login Cookie Best Practice, Barry Jaspan
• Creating a Persistent Login Mechanism, Jeremy Cook
]]> http://www.shinytype.com/php/persistent-login-protocol/feed/ 0 http://www.shinytype.com/php/upload-files-to-a-mysql-database-with-php/ http://www.shinytype.com/php/upload-files-to-a-mysql-database-with-php/#comments Tue, 25 May 2010 05:24:28 +0000 Dave http://shinytype.com/?p=46


There are plenty of tutorials and articles on uploading files to a server, but not quite as many about uploading to a database. Developing database-driven (or at least supported) applications is almost a right of passage for the bonafide PHP developer. As your applications become more ambitious and the database plays a larger role in them, uploading files to your database instead of the file server makes more sense in many scenarios. The grander the scale of your application, the more sense it makes.

Here are some advantages:

• If you’re building an application that has a great deal of user uploaded content, having all of that content stored in one location while being readily available to report on (you can draw reports on who uploads what, etc) is definitely a plus.
• Files stored in a database cannot be executed there.
• User-contributed content can be easily backed up, moved, and copied with the standard database backup jobs you should be already running to keep site content backed up.
• Databases already have the procedures to deal with duplicated data and general data integrity.

In this tutorial, I’m going to use image uploading, which is a fairly common task facing many PHP developers. My example is simple and straight-forward. You can definitely be more fancy and do more things, but this should appeal to a wider audience – most especially beginners.

Before starting, you should have the following:

• A server with PHP and the MySQL extension installed (tested with version 5.2.11)
• A MySQL server
• Credentials for connecting to the MySQL database

First off, let’s prepare a connection file that we can include in ever page that needs to connect to the database.


1) Connect.php

We’ll make an external PHP file and then include it so we don’t have to paste the same thing in multiple pages or edit a bunch of pages if our connection settings change. This is a BIG deal if you have a huge site and suddenly have to change your password, servername, etc.

<?php
$server		= "";	// aka "localhost" or "69.249.73.42"
$username	= "";	// aka "ChuckNorris"
$password	= "";	// aka "Eatsnails4_breakfast"
$database	= "";	// where you want your new table to go

mysql_connect($server, $username, $password) or die(mysql_error());
mysql_select_db($database) or die(mysql_error());
?>

2) Create The Table

To keep it simple, we’re just going to do the basic stuff. You can add other fields if you want to tag more information onto the file record. On one of my past projects, I had fields to track the category it was listed under, the user that uploaded it, and the date it was uploaded.

You might be a little confused asto how the file is physically stored to a database. What happens is the file’s content is put into the content field through the BLOB (Binary Large Object) type. It’s a part of the database now. The BLOB type we’re going to use is MEDIUMBLOB which will allow up to 16 MB files. If you’re thinking “HOLY COW! I don’t want people to be uploading 16 MB files!”, stress not my friend. We’re going to throttle the file size and other filtering in a minute.

CREATE TABLE `files` (
`fid` INT( 11 ) NOT NULL AUTO_INCREMENT PRIMARY KEY COMMENT 'unique id',
`name` VARCHAR( 30 ) NOT NULL COMMENT 'file name',
`type` VARCHAR( 30 ) NOT NULL COMMENT 'MIME type',
`size` INT( 11 ) NOT NULL COMMENT 'file size',
`content` MEDIUMBLOB NOT NULL COMMENT 'actual file'
) ENGINE = MYISAM COMMENT = 'Uploaded files'

You can put this into phpMyAdmin’s query window or run this query in a PHP script.


3) Form.html

So now we have a place to store our files – now it’s time to build the form to upload them. This is pretty simple.

Upload your file to the database...
<form action="upload.php" method="post" enctype="multipart/form-data" name="uploadform">
	<input type="hidden" name="MAX_FILE_SIZE" value="350000">
	<input name="picture" type="file" id="picture" size="50">
	<input name="upload" type="submit" id="upload" value="Upload Picture!">
</form>

Notice “enctype=”multipart/form-data”" – this is vital to uploading the file…without it, the file will not upload. Also take note of the “MAX_FILE_SIZE” – it is set to 350000 bytes, which is 350KB. This is merely our first throttle to check how big the file is. This does not work on all browsers, so we’ll have to double check that and other stuff in the next step in the process.

4) Upload.php

Now, what you’re REALLY here for: the process of uploading files to the database.

A) First we need to make sure this file is to our requirements and kill it if it is not! Since it’s a picture, we’ll be checking the file size, type, and parameters. I’ll try to note everything clearly within the code.

<?php
// if something was posted, start the process...
if(isset($_POST['upload'])) {
	// define the posted file into variables
	$name		= $_FILES['picture']['name'];
	$tmp_name	= $_FILES['picture']['tmp_name'];
	$size		= $_FILES['picture']['size'];

	// get the width & height of the file
	$imageinfo = getimagesize($tmp_name);
	list($width, $height) = $imageinfo;

	// if width is over 600 px or height is over 500 px, kill it
	if($width>600 || $height>500) {
		echo "$name's dimensions exceed the 600x500 pixel limit. ";
		echo "<a href='form.html'>Click here</a> to try again.";
		die();
		}

	// if the mime type is anything other than what we specify below, kill it
	$type = $imageinfo["mime"]; // mime type
	if(!(
		$type=='image/jpeg' ||
		$type=='image/png' ||
		$type=='image/gif'
		)) {
		echo "$type is not an acceptable format. ";
		echo "<a href='form.html'>Click here</a> to try again.";
		die();
		} 

	// if the file size is larger than 350 KB, kill it
	if($size>'350000') {
		echo "$name is over 350KB. Please make it smaller. ";
		echo "<a href='form.html'>Click here</a> to try again.";
		die();
		}

If this checks out, then the file is good to upload!

B) Now we extract the data from the file.

// open up the file and extract the data/content from it
	$extract = fopen($tmp_name, 'r');
	$content = fread($extract, $size);
	fclose($extract);

C) So now all of the file parameters that we need are queued up. Time to put them into the database.

	// connect to the database
	require("connect.php");

	// the query that will add this to the database - notice the sanatized variables
	 // "mysql_real_escape_string" will mess up the content, so just use slashes (I'm assuming magic quotes is off)
	$addfile = sprintf("INSERT INTO files (name, size, type, content) VALUES ('%s', '%s', '%s', '%s')",
			   mysql_real_escape_string($name),
			   mysql_real_escape_string($size),
			   mysql_real_escape_string($type),
			   addslashes($content));

	mysql_query($addfile) or die(mysql_error()); 

	// get the last inserted ID if we're going to display this image next
	$inserted_fid = mysql_insert_id();
	mysql_close();

D) Display the image to the user so they know it has been uploaded successfully.

	// display the image (you can alternatively just display a link or even just a "successfully uploaded" message)
	echo "<div align='center'>
			<strong>$name<br>
			</strong><img name='$name' src='getpicture.php?fid=$inserted_fid' alt='Unable to view image #$inserted_fid'>
			<br>
			<a href='form.html'>upload more images</a>
		</div>";
	}	else	{
	echo "No uploaded file present";
	}
?>

Now that it’s uploaded, we need a way to display the images…


5) GetPicture.php

<?php
if(isset($_GET['fid'])) {
	// connect to the database
	require("connect.php");

	// query the server for the picture
	$query	= sprintf("SELECT name, size, type, content FROM files WHERE fid = %s",
			  mysql_real_escape_string($_GET['fid']));
	$result	= mysql_query($query) or die(mysql_error()); 

	if(mysql_num_rows($result)) {
		$row		= mysql_fetch_array($result, MYSQL_BOTH);
		$name		= $row["name"];
		$size		= $row["size"];
		$type		= $row["type"];
		$content	= $row["content"]; 

		// give our picture the proper headers...otherwise our page will be confused
		header("Content-Disposition: inline; filename=$name");
		header("Content-length: $size");
		header("Content-type: $type");
		print $content;
		}	else	{
		echo "File ID not found";
		}

	mysql_close();
	}	else	{
	echo "No file ID given";
	}
?>

NOTE: if you’re setting up a file sharing site, you’ll want to set the disposition to “attachment” instead of “inline”

Now anytime you use the image tag…

<img src="getpicture.php?fid=1">

…it will display the image, as long as you give it the proper FID number.

Closing Thoughts

Remember, allowing users to upload files to your server (whether it be your web server or database) could potentially be dangerous. Although I’ve made the script as secure as I can while not going overboard as to confuse readers, you should deliberate how to further protect the integrity of your application. In every case I have used this, I required users to register and verify their email as well as created a moderation queue for myself and other moderators to review any uploaded files before allowing them to be accessed publicly. In the scenario used here (adding image files), it’s not as necessary. It’s always best to cover all your bases, though.

Tutorial Assets:
Upload2Database.zip (4kb)

]]> http://www.shinytype.com/php/upload-files-to-a-mysql-database-with-php/feed/ 2 http://www.shinytype.com/general-topics/welcome-to-my-new-blog/ http://www.shinytype.com/general-topics/welcome-to-my-new-blog/#comments Tue, 01 Dec 2009 00:13:51 +0000 Dave http://shinytype.com/?p=26


So, I’ve finally done what I’ve always said I would do (but never made the time to do…) and just set myself up on a blog to share with others my experiences and various projects – typically those involving PHP applications. Hopefully I will make time to blog often enough to make it useful

Here are a few topics one could expect to see in the future:
* PHP – tricks, applications, etc
* Linux – probably nothing too advanced, just posting about things I find interesting
* Databases – MySQL (which I use for personal projects, as is standard for most Open Source/LAMP projects) and MS SQL (what I used to work with and I always noticed there’s not a whole lot of information on it’s interaction with PHP)
* Design – I don’t design nearly as much as I’d like to, hopefully I’ll find things to share that others find useful
* General tech stuff – there are some applications (and software companies) out there that don’t need a sales staff because their customers evangelize their products perfectly…this is where I would be evangelizing their products Also I’ll probably put cool tech articles and interviews here.

I think that’s about it. Fingers crossed!

]]> http://www.shinytype.com/general-topics/welcome-to-my-new-blog/feed/ 0