Archive for May, 2013

As I have mentioned in my previous post, I am working on creating an “universal” OAuth plugin for WordPress.
So far, I have been trying with Facebook, Twitter and Google. I have made the following observations:

FaceBook doesn’t login when the scope is not set, but allows this to be an empty string. However, Google complains about a missing parameter when this is not set. When this is set to an incorrect parameter, such as “email” (which is correct for Facebook btw), the login dialog appears, asking me to grant permissions to my application. However, the application does not receive an access token. I do receive an access token when I use ‘’ as my scope.

Facebook has something like a default scope when I don’t request anything. Therefore, a scope is not required there. It seems, I must request some scope for Google. So, it seems, I should store a default scope to my plugin as well.

The PHP OAuth implementation I am using to generate my WordPress plugin has some services pre-defined. So, I can just tell it to connect to Facebook, Twitter, Google, Tumblr, etc. etc. So, if some scope is required, I might add it as default in the OAuth implementation, or add it as a predefined interface element.

Recently, I’ve been looking at OAuth again. When, in the past, I was checking our Drupal, I had this general OAuth plugin. Just enter the protocol version, urls, client id and secret, and you could use any OAuth provider.

I have been looking for something simular for WordPress, but it doesn’t appear to exist. There exist some plugins specific to a website,
There are plugins line Gigyas and Janrain, which require you to sign up at their site. I don’t trust those kind of services, introducing another party in the login process, which, if compromised, could harm both the user and the website. Depending on a third party to authenticate your users is one thing, but letting a fourth party nagotiate between you and the third party is just asking for trouble if you ask me.

Last time I looked at OAuth, it seemed to me Facebook was the only service using OAuth 2.0. Nowadays, a higher number of services is using the 2.0 version of the protocol. Even Microsoft has adapted to this protocol, depricating it’s proprietary protocols it used when it was still called a Passport account. I know it was a long time ago when it was called this, but still, since when does Microsoft actually use standards (without raping them)?

Anyways… since there doesn’t appear to exist an universal OAuth solution for WordPress, I intent to make such a plugin. I think I’ll base it upon the oauth php library by Manuel Lemos. This library implements OAuth 1.0, 1.0a and 2.0. (For 2.0 some sites might use earlier drafts, not sure if this becomes problematic.) The source code is released under the 3 clause BSD license, so it could be used without a problem. I intend to create WordPress bindings for this library. So, I’ve been looking at the WordPress plugin API as well.

Well… I’m just getting some ideas ;)

P.S. When you think about using OAuth with Twitter, back then, and right now, I’m noticing the problem with the callback URL. You have to specify the callback URL at the application settings at their site.

The last straws of the migration process to the new server. The old server will expire in a few days, so, the last bits are to be migrated.

Migrating the git repository is quite straight forwarded. Just copying the gisosis directory over, and setting the directory. Please note, on debian, gitweb is, unlike on archlinux, a separate package

apt-get install gitosis gitweb

As the installation provided by OVH created two partitions, / and /var, I have to change the home directory of the git user accordingly, as the default location is /srv/gitosis, which would be located on the / directory.

Another thing that’s to be moved are the mailing lists. According to this site migrating mailman is just as simple as copying over the data. However, ISPConfig3 has some mailing list support, to the stuff has to be integrated as well.

To integrate mailman with the ISPConfig3 configuration, add the following to /etc/aliases, then run the newalises command

mailman:             "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin:       "|/var/lib/mailman/mail/mailman admin mailman"
mailman-bounces:     "|/var/lib/mailman/mail/mailman bounces mailman"
mailman-confirm:     "|/var/lib/mailman/mail/mailman confirm mailman"
mailman-join:        "|/var/lib/mailman/mail/mailman join mailman"
mailman-leave:       "|/var/lib/mailman/mail/mailman leave mailman"
mailman-owner:       "|/var/lib/mailman/mail/mailman owner mailman"
mailman-request:     "|/var/lib/mailman/mail/mailman request mailman"
mailman-subscribe:   "|/var/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe: "|/var/lib/mailman/mail/mailman unsubscribe mailman"

And some additonal configuration

# ln -s /etc/mailman/apache.conf /etc/apache2/conf.d/mailman.conf
# /etc/init.d/postfix restart
# /etc/init.d/apache2 restart

Well, ISPConfig3 has to know about the lists, so I guess, I should add the lists first in the web interface, and then copy over the directories (lists and archives). When copying over the directories, keep in mind Arch has a different uid/gid for the mailman user (which it called list) so you have to chown the files accordingly.

Please note, due the new configuration, the URL for the web interface has changed from to

To fix the URL, issue the following command

# /var/lib/mailman/bin/withlist -l -r fix_url bscp -u

I guess I should make up some site at the lists.* subdomains on my server, well, just to redirect to the listinfo page. Anyways… migration of the mailing lists completes. Now, just some more sites, and I’ll also have to take a look at the gitweb, to finally move the BlaatSchaap Coding Projects page.