patrickburke.de

I enrolled for a Java Certification (OCJP OCJA), which is quite cool. The problem  now is that I have to learn Java, therefore I’m not able to update this blog as often as I would like to, let alone to write the Zend_OpenId based consumer and provider. That sucks. But I want to publish those (relatively unspectacular) classes and how they’re used, and I will do that some time in the future! I promise.

Hopefully I can write some Java related posts in the future too, at least I’m planning to do so. This could even aid in learning the new language.

I struggled really hard at getting in touch with OpenID, especially with Zend_OpenId. Let’s face it: The Zend documentation looks more like a Klingon manual on how to slice up a Kirk. But Zend_OpenId is not the point now.

This article is the first part of  a little series on OpenID (since all programming blogs have series, I thought it’d be cool to have one too). This part is about explaining OpenID in general and how it works (in more detail, but language unspecific).

So, what is OpenID?

OpenID is an authentication technique. Authorization is not part of OpenID. Just a word or more about the difference: Authentication is about determining who you are. Authorization is about defining what you’re allowed to do. Both can be done separately. You don’t need to know the guy who is drinking YOUR Bacardi in order to disallow him to do so (yeah, really stupid example).

First, let’s define some terms:

OpenID Consumer

• This is a so called “OpenID enabled site”, a website which allows it’s visitors to authenticate with OpenID.

OpenID Provider

• The OpenID server. Here you register yourself to get an OpenID, such as google.com. The consumer also requests this website in order to authenticate the user, I’ll come to that further down.

OpenID

• The OpenID itself is the URI you get from the provider.

OpenID allows you to use an existing account to sign in to multiple websites, without needing to create new passwords.

This is what openid.net says about the technique. What one might think now is that you register yourself at openid.net and get some kind of identifier, such as an email address, which then has to be passed to the website you actually want to sign in to.

As for the principle of OpenID, this is correct. That is, you register at a website ( = OpenID Provider) and get  an URI as an identifier. That one needs to be entered into an OpenID enabled site and voilà: You’re logged in. It’s that simple. Well, at least on this site, that is, the user site. Depending on the provider, you may also be asked whether you trust the website you want to sign in to.

There are several OpenID providers out there, a list of some more popular ones can be found on the OpenID website itself. If you have a Google account, (one of) your OpenID(s) is https://www.google.com/accounts/o8/id. Some more experienced users now might miss the unique part in the URL. That’s right. The identification of the user is not done with the URL itself, but by the website (or webapp) behind that URI.

A little more detail, please.

In the OpenID authentication process, there are two separate authentications taking place. The first one is the obvious one: The OpenID authentication. The user signs in to the OpenID enabled site by passing his OpenID in. Then, the user must authenticate at the OpenID provider. The second one for example is when you sign-in into your Google account. As I said, the identification is not done with the URL itself, it is done by having the user to authenticate to the provider. The second authentication usually won’t happen every time you sign-in with OpenID, but this depends on the provider.

Basically, OpenID is fairly simple. The consumer sends a request to the OpenID (Provider) with specific parameters which define what the consumer wants know from the provider. Then the provider asks if the user trusts the consumer and, if so, responds with a success message. What these parameters are will be described later on, but for now, this is enough. After the consumer received the success message, he will verify the message by sending a request back to the provider. The messages are encrypted with a key which is defined upon the first request of the consumer to the provider. With the verifying request, the consumer makes sure the key is correct and that the message is authentic.

Also, the consumer may ask for more informations about the user. The provider then asks the user whether he wants to give the consumer these informations and sends them back together with the successful authentication message. This is the “Simple Registration Extension”. What informations may be passed and most notably how to do that is described in a later article.

Ok, I think I didn’t forget anything important :)

Next time, I’ll write an OpenID Consumer based on Zend_OpenId (yes, I learned Klingon).

One of my classmates said today that web programming isn’t “real programming”. I’m not quite sure about how serious he was about it, but it looked like a statement right out of his stomach. This tells me that he thinks this for real in one way or another.

But what is it? “Fake programming”? Without somebody who writes for the web (or who actually writes THE web), nobody could use a computer anymore.

Maybe some aren’t even able to look up words, plan a route or write to a friend without the internet. The web is far more important than most of the “real programmers” think. Of course this also applies for other people not working on the web. If the internet would be switched off from this moment on, and if it was only for the normal people (I just made myself abnormal), which do not work in the IT or something similar, life would never be the same.

Of course most of you knew that already, but I had to get rid of that. Writing about it has something therapeutical to it.

One thing which comes to my mind right now is that he maybe wasn’t talking about the importance of programming (for) the web. Something like “Hihi, PHP isn’t a programming language, it’s only a scripting language!” Or he pointed to the early days of PHP & co. Back than, PHP differed from C, C++, Java, etc. even more than today and one really couldn’t consider it as a programming language. Of course PHP just serves as an exmaple here.

Probably I should’ve asked him.

Naaaahh, that would be too easy.

Great article about using Java-like interfaces in PHP for better sorting  (sorry english folks, this one’s in german):

http://blog.ebene7.com/2010/09/06/besser-sortieren-mit-php-dank-java-interfaces/

Know what time it is? Time for an update!

I was too busy to write something over here. But since this is about to change (hopefully), I thought it is the right time for a relaunch of patrickburke.de

• Everything’s in English now. No german version anymore. I decied to kick the german version because the audience for non-english speaking guys is soooo tiny in this biz, that I won’t waste my time on writing everything twice anymore. Furthermore I have to say that this was a fairly dumb idea, but whatever.
• The blog is now based directly under patrickburke.de, any other projects will get their own subdirectory. The blog is the main purpose, that’s why it belongs where it is now.
• New design, you may noticed it already.
• More posts, yeah I know, sounds like an empty promise, but I’ll try it for real. Seriously :)
• More Zend Framework, I noticed most people which get here are searching for Zend Framework resources, so I thought it would be a good idea to post more about this masterpiece of PHP.

My busyness was caused by a fairly big project at work (I should write about that…). This project is about to get finished anytime soon, thus flushing my brain in order to be able to pay attention to some less important things.

So stay tuned for some code snippets, shit happening to me or anyhting else which is worth taking notice.

I just pissed myself laughing. I read the spam comments just for fun and found this little masterpiece:

Porn? I have seen the blogmaster in a gay gangbang movie the other day, he was high on pills and was taking cock in every hole, that horny gayass cocksucker son of a bitch.
The author of this blog is dumbass motherfucker, he is a faggyass pillpopping maniac.

And I’m still laughing, these guys really have humour :)

But to make that clear: That’s just not true.

UPDATE: Google Wave Now Open For All!
Thus: Invitations aren’t needed anymore; log in and feel great :)

UPDATE: 13 left.

UPDATE: It seems like everyone who is already registered at Google Wave gets eight more invitations to give away. Therefore I’ve got a total of 14 invitations for you guys.

A few weeks ago I got an invitation to Google Wave. Now that I’ve shared most of my invitations I thought “do something noble!”. There are 9 invitations left.

I don’t like quizzes and the like, therefore I’ll do it quick and easy: The first nine visitors which find this article and comment to it will recieve an invitation. Of course I need an eMail adress, otherwise I won’t be able to invote you. You need to create a Google account in order to use Google Wave, either after being invited or prior to that.

Google recommends these browser: Internet Explorer 6, Firefox 3.5, Safari 4 und Google Chrome.

Just kidding, of course the IE isn’t able to handle Wave, neither 6 nor 7 nor 8, only the other three browsers are recommended by Google. Opera (10.01) has some problems displaying Wave. I for one recommend using Iron, the none-Google version of Chrome. Why? Because of the fast JavaScript Engine and because of the none-Google. Seriously, I myself installed Iron, Firefox just isn’t that fast, at least when it comes to executing JS. Probably a fast PC helps out, I don’t know because of the lack of the latter.

But when chatting over Wave with an appropriate performance you can see the others typing, which I didn’t believe at first. Just a little advice: Google Wave is in preview status, this means it breaks sometimes, lags a little, etc.

Now let the games begin!

Again about Zend Framework.

When I read the documentation of  Zend_Acl for the first time, I thought “My god, you want me to load the whole ACL structure at each request? You can’t be serious.”

Of course not. Again asking Google for help I quickly found a dynamic ACL loader in the framework’s Wiki. That’s it! Works great, but it was a little difficult to use objects as resource/role IDs, even if they implemented  Zend_Acl_Resource_Interface and Zend_Acl_Role_Interface respectively. Therefore I simply overwrote the according method and added the missing desired functionality.

Nonsense! Why? Quite simply: I already had written my own version of Zend_Acl::isAllowed() (not overwritten, my version is part of an ACL plugin which doesn’t inherit from Zend_Acl), which in turn uses Zend_Acl::isAllowed() to determine whether Peter has acces or not (A placeholder which I use all the time, you can type it so fast. No, my password don’t contain it. ;) ).

Anyway, my version of ::isAlllowed() loads all needed roles and resources when invoked (of course with a check whether this has been done already), fetches the rights data from database, uses Zend_Acl::allow() and -::deny() respectively to set the user rights and at the end it uses Zend_Acl::isAllowed() to finally determine what Peter’s rights are. The ACL object should be declared as static to not reinvent the wheel each time the method is invoked.

Today I was confronted with the problem to assign a single layout.phtml to each module of a Zend Application. At first I thought it’d be done easily with an application.ini line like this one:

admin.resources.layout.layoutPath = path/to/layout

(whereas “admin” is the module name). But as often, pressing F5 brought disillusion, it doesn’t work this way.

A quick Google search said, that writing a Front Controller plugin which searches for a layout.phtml file by module name is the solution to all my problems. Actually this was exactly what I wanted, but there had to be a way without adding extra code to the application.

So I didn’t settle with this plugin and tried some other things until an error message opened my eyes. In fact, Zend also searches for layout files in the /scripts/views/ dir of each module. Everything I had to do was removing the “resources.layout.*” settings from my application.ini and adding a layout.phtml file to each of the latter named dirs and – voilà – each module used his own layout script; awesome, isn’t it?

Again, it’s just about a Website, but hey: Writing articles is for free.

This time it’s phpbench.com. Chris Vincent compares a lot of frequent PHP code snippets in terms of speed. Often, only milliseconds do the difference, but every little helps ;)

I will try to stick to some rules to get even the very last millisecond.