Oscar Merida has a recent post to his blog about using the bcrypt functionality to more securely store the password information for your application's users.

The linkedin password breach highlighted once again the risks associated with storing user passwords. I hope you are not still storing passwords in the clear and are using a one-way salted hash before storing them. But, the algorithm you choose to use is also important. [...] The choice, at the moment, seems to come down to SHA512 versus Bcrypt encryption.

[...] I wanted to switch one of my personal apps to use bcrypt, which on php means using Blowfish encryption via the crypt() function. There's no shortage of classes and examples for using bcrypts to hash a string. But I didn't find anything that outlined how to setup a database table to store usernames and passwords, salt and store passwords, and then verify a login request.

He shows you how to set up a simple "users" table and the code for a "save_user" method that takes in the username/password and generates a salt and calls crypt on it with the Blowfish prefix on the string ($2a$). His login check function ("validate_user") then takes the user's input, does the same hashing and checks the result.

Evert Pot has a quick new post to his blog today talking about how to push encrypted information into a cookie for storage.

There have been a couple of approaches I've been considering [to replace sessions being stored in the database], one of which is simply storing all the information in a browser cookie. First I want to make clear I don't necessarily condone this. The reason I'm writing this post, is because I'm hoping for some more community feedback. Is this a really bad idea? I would love to know.

He includes some code to make it happen - a class that uses the hash_hmac function and a SHA1 encryption type (along with a salt) to convert the information into a string that can be (relatively) safely stored in a cookie. Be sure to read the comments for more opinions on the method.

Alvaro Videla has submitted a new post he's written up combining PHP and Erlang yet again, but this time he's using it to just store key/value pairs rather than for session data.

In this post I want to show you some of the neat things that can be done with the PHP-Erlang Bridge extension: A Key Value Store. Erlang comes packed with a Key Value store in the form of the ETS module. This is database is pretty fast and efficient for storing the Erlang terms in memory.

He tried a proof of concept to see how well the system would respond and was able to push over 150k items into the storage in one second. Sample code and instructions on getting the bridge working are included in the post.

On Till Klampaeckel's blog this recent post shows you how to (quick and easy) set up multiple Magento stores on different domains with the same codebase.

Multiple stores is probably the killer feature of the Magento Commerce store. It enables the needy to manage multiple stores through a single interface. Your very own mall in a box. It's also a management/deployment nightmaredream come true. A single piece of software powering multiple websites.

He sets up his directory structure and shows how to alias certain directories to ones in the local document root so that the application will find things correctly. Drop in a custom index.php "bootstrap" file to run the application and you should be all set.

David Goodwin has a suggestion for those developers that think storing objects in a database is a good idea - don't do it!

Short answer: DO NOT DO IT. Longer answer:....I hate seeing serialized PHP objects within a database.

Some of his reasons include:

• It's difficult to index/search - you'll probably need to use a regexp.
• PHP Specific - good luck doing much with the data in a.n.other language
• If the objects are large, you're likely to have a text or a blob field - this will suck from a performance point of view (at least in MySQL)
• Why bother storing serialized objects in a database - surely to the filesystem would be better?

Several opinions are expressed in the comments including some that agree with David and some that still defend the idea.

Jani Hartikainen has posted the third part of his series looking at access control and the Zend_Acl component of the Zend Framework. This article focuses on creating and storing dynamic ACL lists in a database.

As we have previously looked at ACLs which are hardcoded, we will now look at building a "dynamic" ACL. Previously shown "static" ACLs are good for quick and simple sites, but when you actually require the ability for administrators to define access rights on the fly using an admin panel, they quickly lose their usefulness.

Dynamic lists provide more flexibility in handling the access control of your site - it allows you to only pull what you need (just that user) when you need it. His method uses an ACL factory class to create the Zend_Acl objects for each request. He includes an example of protecting an application used to serve out files to visitors. You can download the code if you'd like to mess around with it yourself.

Etienne Kneuss has posted a look at using the SplObjectStorage functionality of the Standard PHP Library as a safe place to tuck away and protect your objects.

In PHP, you basically need two things to safely identify an object: a object index, the handle, and the class handlers which is how the object will react internally. This set of handlers is actually a pointer, and since disclosing valid pointers is not something that should be done, spl_object_hash is simply providing a MD5 hash of those two values concatenated.

Since arrays are hashed when they are created as well, your script is doubling the amount of work it has to do behind the scenes. Instead, Etienne suggests that you use a SplObjectStorage object instead of an array to keep objects inside. The unique identifier for it is then used directly (instead of rehashed, leaving it open for possible referencing collisions) to reference the object.

In a five part series on the symfony blog, Fabien Potencier relates a call to the expert, a refactoring story where he helped out a fellow symfony developer with their first application.

Some time ago, Vince, a seasoned PHP developer, asked me to have a look at his very first symfony project, a product store. As the mistakes he did were quite common, I decided to tell you the story of this refactoring session in the hope you will learn as much as Vince did

Here's links to each of the five parts:

• Part 1
• Part 2
• Part 3
• Part 4
• Part 5

Michael Kimsal points out the posting of the latest part of his "Grails for PHP developers" series to his blog site - Part Five of the series.

I've put up the latest installment in my "Grails for PHP developers". Rather than delve too much more in to Grails head on, I'm taking this installment (and at least the next one) to delve more in to the Groovy language itself. Groovy offers similarities to PHP, but also many differences which can trip you up if you're not careful. I'll try to lay those out as best I can in the next couple of installments.

This new part of the series goes back and puts the spotlight on GRoovy, the base of the Groovy/Grails combo. He talks about working with variables and arrays as containers for multiple pieces of data and some possible gotchas that could come up along the way.

In a recent blog post, Brian Moon talks about doing something he never thought he'd do - storing files in a database. He does, however, have two legitimate places he's found it useful.

Now, most people will say you should never do this. And lots of time they are right. And once upon a time I agreed with them without question. Then I started living in the real world where sometimes you have to do things you never thought you would. Here are the two places where I stores files in a database.

His places are in Phorum, using the method to keep the system's database and file attachments contained and easier to move around, and in the replication of their databases, making it simple to have images for the deals on dealnews transferable to the various slave databases.