Category Archives: php

PHP Frameworks

Posted on by
Reply

I’ve been coding in PHP off and on for years now.  Each project I’ve done thus far has always been by hand.  Doing the architecture of your site by hand is the easiest way to introduce bugs and end up with sloppy code.   For the first time I’ve started a project where I used a framework in PHP.  My framework? Codeigniter.  I like it’s simplicity, MFC design and how it’s not like Rails.  I thought Rails was a bit too complicated and involved hacking the internal code way too much to get anything done, but that’s a whole other rant.

Anyway, the project I’m working on?  Just a twitter clone.  Why?  For the sake of learning, that’s all.  It’s actually for a project in school.  The idea is to implement this idea in something that I’m already familiar with (PHP) and then implement it again in another language I’m not familiar with at all.  After I’m doing with the first part I want to implement it in Python using the Django framework.  Python has always been one of those languages I’ve been meaning to learn.  In fact it seems I try to learn it every summer, but I just don’t seem to have the dedication to sit in doors learning it.

Regardless, I hope to use this knowledge in my professional life.  The last PHP project I worked on was stressful just because of some of the design decisisons I made (Doing a half-assed MVC implementation…didn’t do the best job of dividing up the view and controller).  However, I’ve learned from those mistakes and I might be taking up a new project at work where I’ll probably be using this framework.

OpenID + uF epiphany

Posted on by
2

UPDATE: After an email discussion with Adam Darowski, I revised this post to make it a bit more user-friendly.

I think I might be going about this idea of consolidating your online identity with the OpenID simple registration extension and microformats wrong. I found this microformat library for PHP; It works by by retrieving the microformatted data (in this case hCard) by simply feeding it a URL and it then saves the hCard data for future manipulation. I’m starting to realize this same practice may be another way to consolidate your online identity with OpenID.

Before we get ahead of ourselves, let’s see how the applicable portion of the OpenID protocol works. The first step is to supply our OpenID URL to the consumer site and hit “submit.” For example, I would enter “nickpeters.net” as my OpenID URL to the consumer site ma.gnolia. What is a consumer site exactly? According to the OpenID Specification, the consumer is:

A web service that wants proof that the End User owns the Claimed Identifier.

Pretty much it means a site that wants to find out whether or not we are who we say we are by first asking for our OpenID URL.

After we hit the “Submit” button, an internal script on the consumer site will redirect itself to the given URL and look for two link tags in the head of the given HTML document. For the sake of simplicity, we’re only going to discuss the one of them: rel=”openid.server.” The href value of this link tag is going to be the script that actually authenticates you by asking you for the username and password you use on all OpenID-enabled sites. This practice is useful because you can offload the authentication process to a site like Vox or livejournal instead of setting up a server on your own server. This means I can enter the URL for the livejournal authentication script or a script hosted on my site. It also means your username and password isn’t sent to the consumer site and is only sent to the specified script.

That should be enough information for now, so let’s see how hCards can fit into this. Let’s say we log in to our OpenID consumer site (ma.gnolia) and go through the login process as normal. While the consumer site looks for the and OpenID.server URL in the head of our page, it would also look for some sort of clue as to the location of your hCard information. Perhaps this “clue” could follow in the steps of the existing OpenID protocol and also be a link tag, such as rel=”hcard” in the head of the document. From there, the consumer-site script can retrieve the hCard location by looking at the href value, properly redirect itself, and retrieve your information (Perhaps even using the hKit library).

The pros of this is that you can add as much or as little information as you want about yourself in your hCard. The simple registration data fields are very limited and there maybe some information in there that you don’t want to be shared (such as email address).

The cons is that it requires more administrative overhead. You’ll have to edit the header information of your site. You may not even be able to do this on all OpenID identifiers (such as ones on livejournal) because you don’t have permission to edit the header information.

Right now there are discussions going on in the microformat community about authoritative hCards that could possibly guide this idea in the right direction. I will continue to think about this and would appreciate any ideas from others.