Netsensei

Much Ado About Nothing

Openid

WP Mollom 0.5.2

So, I wrapped up version 0.5.2 of WP Mollom today. This release is all about fixing several bugs.

  • fixed: passing $comment instead of the direct input from $_POST to the show_captcha() and check_captcha() functions.
  • improved: implemented wpdb->prepare() in vunerable queries
  • improved: mollom_activate() function now more robust
  • changed: mollom_author_ip() reflects changes in the API documentation. This is to catch up on the abuse of proxies by spammers. If your host uses a reverse proxy and you know the ip(‘s), just enter them in the dashboard. The plugin takes care of the rest.

I tried to make the plugin compatible with the WP OpenID plugin over the past weeks. But no dice. Stable version 2.1.9 of WP OpenID doesn’t deal with extra fields added to the HTTP POST by other plugins when a request is send to wp-comments-post.php. This causes WP Mollom’s CAPTCHA form and subsequent checks to malfunction.

The good news is that Will Norris of WP OpenID is aware of the problem. The development version does contain a fix for this problem and is actually compatible with WP Mollom. You can check out a copy from the DiSo Project’s Google Code repository if you really want OpenID and Mollom support on your site.

As always: refer to the documentation regarding all the in’s and out’s.

Release of WP Mollom

So. I scheduled a first public beta release of my Mollom plugin somewhere tonight (CET/UTC+1). The plugin runs quite stable on my own weblog and spam is happily being blocked. I didn’t receive major complaints from testers or users on my own blog in the past week. Yesterday, I cleared the code with Dries who took a glance at the major functionality.

Of course, it wouldn’t be a first beta release if there aren’t still some irks lurking around in the code. This morning, Leo Arias mailed me that the plugin won’t work together with the WP OpenId plugin. Having toyed with my own OpenID implementation for WordPress, I’m not a great proponent of this technology. The way you have to design a plugin implies using several shortcuts. I’m not going to push my release back now, though. I will try to fix this issue in the next release.

My code will also be thoroughly reviewed by the Mollom people.

Thanks to all the testers and those who just listed to become a tester!

Is OpenID wel zo fantastisch?

Wie wil er nu honderd paswoorden en accounts bijhouden? Niemand toch? Of je gebruikt telkens hetzelfde paswoord. Knappe koppen denken natuurlijk wat verder en kwamen met een oplossing: OpenID. Ideaal, zo leek het. Eén paswoord/login combo onthouden en de rest gebeurt automagisch op elke site die OpenID ondersteunt.

Maar is OpenID wel zo fantastisch? De voornaamste kritiek op OpenID valt samen te vatten als deze: “On the Internet, nobody knows you’re a dog.” Of beter, het decentrale karakter van OpenID betekent verzwakte de sterkte de identiteit die je claimt. Meer hierover vind je hier.

Los van die discussies, heb ik zelf uit harde ervaring geleerd dat OpenID niet het nirvana betekent. Mijn kritiek is eerder technisch van aard en beperkt zich tot het protocol zelf. De laatste maanden heb ik mij gebezigd met een OpenID plugin voor WordPress. Dat betekende dus een OpenID consumer implementeren en die koppelen met één van de API haken van WordPress. Om precies te zijn: in het wp-comments-post.php script. De OpenID specificatie leert ons dat alle oproepen tussen een consumer en een identity provider via HTTP GET requests moeten worden afgehandeld. Helaas hebben de makers van WordPress het bewuste script zo gepatched dat HTTP GET requests worden afgeblokt. Helaas betekent het ook meteen het afblokken van OpenID in comments op een propere manier. Ik kan via allerlei truken de nieuwe beveiliging omzeilen. Maar echt ideaal is dat niet.

Hadden de makers van WordPress die patch moeten doorvoeren? Vanuit het standpunt van beveiliging en anti-spam: zeker. Een script dat HTTP GET requests aanvaardt kan vrij gemakkelijk worden misbruikt. Zeker als het gaat om het dumpen van spam is er geen kunst aan om code te schrijven dat massaal HTTP GET requests afstuurt op onbeveiligde webscripts. Neen. Het probleem ligt in de OpenID specificatie. Die legt juist het gebruik van HTTP GET requests op en laat geen ruimte voor mogelijke alternatieven. In mijn ogen dwingt OpenID dus hier een mogelijk veiligheidsrisico af. Nochtans zijn er andere, betere alternatieven om data over HTTP door te sturen zonder gebruik te maken van de onveilige HTTP GET requests. Ik denk dan aan RPC protocollen zoals XML-RPC (er zit een XML-RPC module in WordPress!) en SOAP.

Persoonlijk sluit ik daarom dus liever mijn OpenID experiment voorlopig af en kijk ik de kat wat uit de boom vooraleer ik er verder mee ga.

Simple OpeniD plugin @ WordPress.org

Kijkt! Tegen mijn eigen verwachtingen in heeft Simple OpenID plugin een stekje gekregen in de officiële WordPress.org Plugin database.

Ik had in de vooravond vlak voor vertrek op het werk een request geplaatst. Toen ik van stappen met kameraad WebsterMC terug kwam vond ik een mailtje met de approval! Fijn! Het mooie is dat WordPress.org Subversion ondersteunt. Ideaal voor versiebeheer. Meer zelfs, er wordt dynamisch een ZIP file getrokken van de laatste versie. Deze wordt vervolgens geheel automagisch aangeboden. Downloaden die hap!

(ja, ik ga nu toch van de gelegenheid gebruik maken om mijn winkel te promoten.)

Simple OpenID plugin 0.1 beta

Ik denk dat ik de eerste beta versie van mijn plugin nu wel kan vrijgeven. Ik ben op het punt gekomen dat ik er lang genoeg aan heb gewerkt. Without much ado: je kan hieronder alles terugvinden…

Simple OpenID plugin 0.1 beta

Let wel: dit is een zeer vroege beta release. In het beste geval werkt het meteen, in het slechtste geval zal je even moeten zoeken. Ik heb mijn best gedaan om het uit te testen op verschillende configuraties en de moeilijkheden wat te documenteren. Opmerkingen, patches, code en dergelijke mag je mij toesturen op matthias [apestaartje] netsensei [puntje] nl. Uiteraard hoe meer hoe liever dus wie mij weet te helpen met een bepaald probleem krijgt er immers credits voor!

Veel plezier ermee!

OpenID @ Barcamp3

Hoewel ik er zelf niet bij kon zijn was er blijkbaar op BarcampBrussels3 heel wat interessants te zien en boeiend volk te ontmoeten! Ook OpenID maakte er blijkbaar een niet onopgemerkte entrée. De presentatie van Frank werd was naar het schijnt druk bezet. Het is fijn te weten dat er zoveel interesse is voor OpenID.

Frank was zo vriendelijk om gelijk zijn presentatie op het net te gooien. Het is een mooi overzicht voor wat OpenID staat en wat je ermee kan doen. Het bekijken waard.

Mijn eigen wapenfeiten op het OpenID front lagen dit weekend wat stil. Ondertussen heb ik mijn plugin sinds het begin van de week verder bijgewerkt. Het belangrijkste zeer blijft echter: akismet verwijst elke OpenID comment richting prullenmand. Een OpenID comment die door de plugin wordt gegeneerd bevat nochtans zoveel mogelijk relevante info (e-mail, nickname, url, comment inhoud) Toch wordt gebruik van OpenID afgestraft. Dit moet ik nog nader onderzoeken. Verder blijf ik input appreciëren. De plugin blijft op dit blogje actief. Ik ben vooral geïnteresseerd in mensen die de plugin reeds gebruikt hebben om hier een comment te plaatsen. Ik heb die comments uit de prullenbak opgevist maar ik zou graag willen weten of akismet daaruit geleerd heeft en ze bij een tweede poging al dan niet opnieuw richting spambox worden gestuurd.

OpenID enabled!

Een drietal dagen noeste arbeid later heb ik een eigen OpenID plugin voor WordPress geschreven. Veel ga ik er nog niet over zeggen, laat staan code vrijgeven: ik heb nog flink wat debug werk voor de boeg. Maar dit is zo ongeveer het resultaat:

Ik heb het zaakje ook even op dit blogje geïnstalleerd. Wie zin heeft kan alvast even spelen met zijn OpenID. Dat doe je door in plaats van je naam/e-mail adres op te geven in het commentaarformulier, het OpenID veld te voorzien van je OpenID. Voor een buitenstaanders is een OpenID trouwens niet meer dan een URL. Bijvoorbeeld: http://openid.openminds.be/netsensei.

Wie nog geen OpenID heeft:

  • Als je een wordpress.com blog hebt, dan heb je automatisch ook een OpenID login. Gewoon de URL van je blog ingeven volstaat.
  • Geen WordPress.com blogje? Geen nood! Je kan altijd snel en eenvoudig hier een account aanmaken!

Opmerkingen, suggesties en bugreports kan je sturen naar matthias [apestaartje] netsensei [puntje] nl

Update: You can download the beta version of the plugin!

Verlof

Eén van mijn betere ideeën was om verlof te nemen deze week. Schoon weer, geen regen, niet te warm en niet te koud. Ideaal! Wilde plannen heb ik niet. Voorlopig heb ik mij eigenlijk voornamelijk bezig gehouden om openid te doorgronden.

Ik heb mij gelijk de JanRain PHP library gedownload om er wat mee te spelen. De uitleg in de API documentatie was zo duidelijk dat ik meteen een eenvoudige consumer kon maken en via mijn blog (een openid delegate in het jargon) mijn openid verifiëren. Meer zelfs, toen ik mijn implementatie even vergeleek met één van de voorbeelden van JanRain bleken die quasi krek hetzelfde te zijn! En zelf een server opzetten en laten draaien is ook niet zo heel erg moeilijk.

Alle technische mumbjumbo goed en wel, maar wat wil ik er nu mee aanvangen? Ik denk aan een aantal dingen. Maar laten we beginnen met openid support in WordPress. Het zou al mooi zijn moest ik een eenvoudige plugin kunnen schrijven die OpenID toevoegt aan comments. Het idee is om zo OpenID nog wat verder te leren kennen. Daarna zien we wel weer…

Openid

Hm. Ik heb de voorbije dagen mij wat verder proberen te verdiepen in Openid. Very impressive stuff. Ga ik nu te ver om te zeggen dat dit zo’n beetje het hippe speeltje van 2007 zou kunnen worden? Het heeft alvast heel erg veel potentieel. Open, gedecentraliseerd, altijd beschikbaar,…

Ik heb dan maar eens even de JanRain PHP library gedownload en wat met de voorbeelden gepeeld. Natuurlijk heb ik mij gelijk een OpenID accountje aangemaakt. Ik heb links en rechts wat moeten aanpassen maar ik kreeg het vanaf de XAMPP installatie op mijn externe harde schijf gemakkelijk aan de klap. Enkele tips voor avonturiers:

  • Onder windows moet je de juiste padaanduiding gebruiken om de bibliotheek de FileStore directory te laten vinden.
  • Auth/CryptUtil.php maakt gebruik van een bron met random bytes. Dat staat standaard ingesteld op /dev/urandom. Onder windows moet je dit wijzigen naar een willekeurige file. Dat mag gelijk wat zijn. Ik heb een foto gebruikt. Ook hier weer opletten op de juiste padaanduiding.

Mijn openid vind je alvast terug in de header van mijn blog. Dus ik ben volop openid enabled zullen we maar zeggen. Ik ga mij er alvast wat verder in proberen verdiepen. O ja, voor een visuele uitleg van wat OpenID is en wat het kan: hieronder een demofilmpje

You thinkin’ what I’m thinkin’?

De laatste week zit ik met volgend idee in mijn hoofd. Pas op, want het wordt daarna wel serieus techy-geeky…

OpenID + (Gr)Avatar = ???

Ik neem aan dat ik niet de enige ben die ondertussen op deze combinatie kom. Ik vraag mij hoe dit zou kunnen werken. Ik zie het ongeveer zo:

Een OpenID provider zorgt er niet alleen voor veilige storage van je credentials, maar koppelt daar ook nog een aantal andere zaken aan. In dit geval een avatar die eveneens op een centrale, toegankelijke locatie worden bewaard. Eenmaal geauthenticeerd gebruikt de website van waarop werd ingelogd de credentials niet alleen om data (comments, forumposts,…) te ondertekenen, maar haalt ook nog eens de avatar op en toont die op de website.

Natuurlijk kan je avatars ook lokaal bewaren. Bij de website zelf. Alleen wordt de referentie naar die avatar gekoppeld op het niveau van de OpenID provider. Eenmaal ingelogd wordt de avatar vervolgens lokaal opgezocht en gekoppeld aan de data.

Ik vraag mij enkel af of de OpenID specificatie wat dat betreft uitbreidbaar is met optionele elementen zonder de specificatie te breken. Waarmee ik bedoel: extra meegestuurde informatie zou een OpenID provider volgens mij veilig moeten negeren indien niet geïmplementeerd. Natuurlijk, je kan ook een schil rond OpenID aanleggen en OpenID requests en responses kunnen inkapselen in containers waarin je verder ook optionele informatie steekt. Tenslotte zorg je ervoor dat die transparant worden verwerkt. Alleen lijkt me dat wat overkill.

Alles ik het zo bekijk zit ik hier serieus te freewheelen. Voor wie het interesseert that is…

« Vorige blogposts Pagina 1 van 1 pagina's