If you check out the master branch, you can use the new Encrypt strategy to encrypt your session data automatically. This means that you can read and write session data in cleartext and they will be encrypted on the fly before getting stored (in a cookie, for example).

You'll need the mcrypt extension installed for it to work correctly, but it makes storing the encrypted version of your data more or less automatic. Just set up your Session configuration to use it as a strategy and any time you call a "read" or "write" the hard work is handled for you. For those more interests in what's "under the hood" he goes on to talk about how the strategy works, what cipher it uses by default, how to change it and the default string to use in hashing.

I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I thought I'd share my experience in this series of articles. [...] This entry follows on from the ones about the initial requirements, how to how to handle request tokens, and authenticating users.

In this latest post, she talks about the three different types of tokens - consumer, request and verififier - and how to use them to locate a user in your app's users. Her code validates the request token and verifier against the database and, if successful, inserts the rest of the token information for the user.

OAuth is great - there's no need to save users' passwords, it's - in theory - a consistent way to interact with other services, and it's hopefully something that your users are familiar and comfortable using. But if you're not just interacting with your users' accounts - for example, your application uses a single account on a service to broadcast messages, or analyze data - getting or renewing the access token can be painful.

He illustrates the problem with an example connecting to Twitter and even points out a script that makes bridging this gap simpler. Unfortunately, it's not exactly what he needed, so he reworked the idea with a call to the Twitter API using a Zend_Oauth_Consumer and a custom callback. The script is then set up with some command line options for inputting the key and secret information. Also included is functionality letting you define a configuration file. You can see the final result here on github.

There is no front end at all. It just collects info and stores it in a database so I can query it later. (I'm an old-school database guy and love just writing ad-hoc queries to see what I can see) Twitter wants to redirect you to a site once you have authorized access. Since I don't actually have a site to redirect it to, this was a problem.

His solution ("in two parts") involves tips from two different blog posts - this tutorial from Michelangelo van Dam and the other from Jaisen Mathai about using OAuth with Twitter. He's not releasing the source for his script just yet, though, so you'll have to do a little research on your own.

I've been looking into OAuth recently and really like what I see, so I started looking at actually starting to play with something that uses it (and isn't twitter). In the pursuit of this, I spent some time walking through the process of how to actually authenticate using OAuth, as a client.

She briefly touches on the consumer key and secret and how those are passed along with the OAuth object creation to grab a request token, complete with details on setting a callback. She also mentions how to grab an access token - a piece of information you include in your API calls to let the remote service know who you are. All of her examples are using Yahoo! OAuth services.

WordPress seems to be everywhere these days, and it's no wonder with it's ease of use and ease of customization. In this tutorial, I'll be dissecting the default WordPress theme's comments.php structure and giving you various snippets of code to make your skinning easier.

The guide breaks down the major parts of the file - some of the general code, how it displays comments, the comment submission form and some "little tricks" it does to handle things like comment numbers, links and the alternating colors.

The slides [pdf] summarizes his talk, described as:

PHP 5's ext/SOAP extension is an excellent web services client. However, while the easy things are easy, lack of documentation means the hard things can appear downright impossible. Starting with SOAPClient basics and building upwards, learn the hidden secrets necessary to conquer even the strangest WSDL.

In the presentation, he not only describes the functionality the PHP 5 extension offers, but provides a few simple code examples to help with the explaination.

Today, I ran across Ruby Secret Santa. I couldn't help but think to myself, "That's sort of nice looking but wow, for a little thing like Secret Santa, how much overkill is that?" Here's the same thing in PHP, minus the database fetch (add it in two lines).

That's less than half the code. I think this is a fair comparison because it directly compares PHP to Ruby, without any "frameworks" or other middleware in between. Which one do you think is extremely simple?

I like how he puts it as well:

I think that Rails is a phenomenal tool, but it's tooling '" not a language. I am sure that great tools will come for PHP as well, and that PHP itself will always be a language that is both highly productive and high performance. Do you Yahoo!? ]]> Fri, 16 Dec 2005 07:40:48 -0600