Last week Google announced the PHP support for Google App Engine (GAE). PHPStorm, the great IDE for PHP development, also announced support for Google App Engine PHP. Because of that now is time to hack a little bit with this new toy. [...] To build a simple Silex application over Google App Engine is pretty straightforward (more info here). Because of that we're going to go a little further. We are going to use the log-in framework provided by GAE to log-in with our Goggle account within our Silex application. In fact we can use the standard OAuth authentication process but Google provides a simple way to use our gmail account.

He includes the code showing what the end result will look like as well as what's needed for the "LoginProvider" class. He also creates an "Auth" class where most of the work is done - creating the login URL, redirecting the user and checking to see if the user is logged in. He's made a screencast of the full process so you can see the authentication flow as its happening.

Testing is an iterative part of the development process that we carry out to ensure the quality of our code. A large portion of this entails writing test cases and testing each unit of our application using random test data. Actual data for our application comes in when we release it to production, but during the development process we need fake data similar to real data for testing purposes. The popular open source library Faker provides us with the ability to generate different data suitable for a wide range of scenarios.

Faker uses built-in data providers like "Person", "Company", "DateTime" and "UserAgent" to give you randomized output from the data sets you define. Code is included showing how to create the provider in your objects, extending the correct provider and making a request for a property. A real-world example is also included about testing an email marketing engine for address, title, name and content. There's also a little bit added at the end showing how you can increase the randomness of the results returned by "seeding" the Faker engine.

Oracle announced today that it has made a strategic minority investment in Engine Yard, a leading cloud development platform that supports Ruby, PHP and Node.js, popular web development languages. [...] In conjunction with this investment, Oracle and Engine Yard expect to work closely together to provide cloud application developers with a greater choice of development and deployment options. The two companies are expected to connect their respective PaaS offerings to enable more rapid development of applications in a secure, reliable and scalable environment.

No word yet on how this will integrate with Oracle's own cloud solutions but it should be interesting to see what comes out of it. Congratulations to the Engine Yard folks on the investment!

We are currently building yet another PHP Cloud Platform ourselves. Of course we looked around to see what the others are up to. This is my (Franks) personal point of view of the current market situation showcasing my favorite services. I try not to judge, neither i will compare features nor prices.

Services on his list include:

• Heroku
• phpFog/appFog
• PagodaBox
• CloudControl
• EngineYard

I will be focusing on some of these free cloud hosting options available out there. One thing to note before you proceed - these free cloud hosting options are very good to develop and test your applications (in dev+staging environment) and it may not be wise to deploy the production version of your application with any free plan (Except Amazon AWS's free tier, its production ready).

He has four different services on his list, ranging anywhere from small to industrial strength, depending on your needs:

• Amazon's AWS
• PHPFog
• PHPCloud (from Zend)
• Heroku (traditionally Ruby, now supports PHP too)

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.

Zend Framework has pretty good OAuth consumer implementation. However, it has no support for implementing OAuth provider, and it turns out that there aren't many other libraries for it. Most examples out there base on PECL oauth extension, which works just fine, with one caveat - you have to have this PECL extension installed, while ZF implementation does not require that. So I went ahead and wrote some code that allows to easily add OAuth provider to your ZF-based or ZF-using application. That should make writing OAuth provider easier.

His code just fleshes out the server portion of the provider, not all of the token generation and key handling it'll need on the backend - that'll still be the job of your scripts. You can find the library over on github in his Zend_OAuth_Provider repository.

This phase is probably the most familiar to us as developers, as it's simply a login form. The consumer will send the user to us at the URL we provided in the request token, and the user will have the request token key as a parameter. The access control on this page will look the same as on the rest of the website; if the user has a session already then the page is displayed, otherwise they must be logged in to see it.

She talks about verifying the authentication token passed in (from the value already generated and put into a database table), the grant/deny process and the information to update in her sample table when the user falls into the "granted" side of things. She also briefly mentions the optional callback that can be passed to a service like this and how to handle its value.

The consumer requests a request token (see my earlier post about consuming OAuth), and as a provider, we need to handle that request. In my example, I chose to pass the variables as GET parameters, but you could adapt this to handle POST variables or information contained in HTTP headers.

She includes the code (using the functionality of the pecl_oauth extension) to provide a token and the three functions you'll need to define to get things working - the consumerHandler, the tokenHandler and timestampNonceHandler. She also includes a sample database table structure for storing the OAuth information for a user.

This article uses the pecl_oauth extension and builds on Rasmus' OAuth Provider post. [...] OAuth has a little more baggage with it than just passing a username and password to an API.

She lists the five things you'll need for your service and talks a bit about the registration process and how the consumer key/consumer secret keys are generated. There's no strict definition on them, so her example uses a combination of sha1, mt_rand and substr to get the job done. She also includes a sample "consumers" table for your reference.