Information Cards on Drupal

Finally! I’ve got what I hope to be a decent prototype for a Drupal Information Card module.    I’ve made huge changes to the user interface on this one, and as a result, I hope to have streamlined the process for framework owners.   What I haven’t yet got, is a lot of eyeballs from a lot of people on different platforms, in different situations, and with different frames  of mind.  If you have 5 extra minutes, please check out my example site.   There is a poll there to let you give extra-fast feedback, and there is a feedback form if you want to address a specific finding.

Here’s a quick summary of the new features:

User Card Management

  • Once authenticated, users can add and remove cards from their accounts, as well as seeing when the card was associated and when it was last used.

Lost Card Recovery

  • Users can now use an email-based recovery process to attach a card to an account that they’ve lost credentials to.  This is incredibly important in a case where all passwords have been turned off for the site.

Purple “i” means Selector launch

  • Everywhere you see a purple “i”, you should see a selector launch immediately – no more intermediate pages.
  • (Note there is a purple “i” in the card mgmt console, that card will eventually launch the selector to verify the Friendly Identifier)

Minimum clicks

  • The goal is to get the job done in the smallest number of clicks.   There is probably even more to be done here, but we’ve made progress.

Developer Improvements

  • Code is now documented with a standardized, doxygen-compatible format
  • Much more consistency in approach
  • Lots more to do ;)

WordPress users:  I’m upgrading that plugin right now to use the same flows — so if you don’t like them, speak now!

You will need a PamelaWare update for WordPress 2.6

You wouldn’t guess it from the announcement, but WordPress 2.6 completely changes the cookies set when a user authenticates, and in the process breaks quite a few WordPress Authentication Plugins, including Pamelaware for WordPress.

I am fiddling with the fix now, but haven’t quite perfected the process;  I can set the new cookies, using the new cookie setting function, but somehow the cookies I set with the cookie setting function don’t look exactly the same as the cookies WordPress sets when it executes the same function.

There have been a few non-plugin-related panics around the cookies as well – some admins are unable to get to their consoles.  Fixes range from clearing your browser cache and deleting cookies to adding an extra define statement in your wp-config.php file.

If you have already upgraded to WordPress 2.6, you’ll need to disable the Pamelaware for WordPress plugin until I can get this fix out — I hope this will be today.  If you haven’t upgraded to WordPress 2.6, you may want to hold off, or at least to make sure you have time to deal with possible authentication issues like the ones that are cropping up in the forums.

The good news is that I now know that if you develop WordPress authentication plugins, you need to be subscribed to this guy’s blog if you don’t want to be caught by surprise with changes to authentication mechanisms in WordPress.

Update:  I have a working fix now — you can get it from the 0.9 release branch subversion tree, if you want to play.  I have not yet updated the tarball to reflect this change, as I haven’t tested it enough to be sure it won’t break under obscure circumstances.  Contact me if you want more detail prior to a tested release.

PamelaWare gets Reviewed!

Last weekend while I was out at my cabin, Ryan Janssen was trying to install PamelaWare for WordPress. Generally I wouldn’t be too concerned, as my project members and I have worked hard to make the install relatively easy.

I try to make myself available as tech support if I know anyone is trying to get the plugin to work, because I want to make sure everyone has a good experience — but in doing so, it turns out that I was masking a critical flaw in both the documentation and the administrative user interface.

For more details, you should read Ryan’s entry, I recommend it – the entry very clearly describes his frustration around not knowing what format of private key, passphrase, and domain name the plugin was expecting, and his eventual success by brute-forcing all of the possible combinations.

Obviously, this isn’t exactly the review I was expecting :) But luckily, I have just finished Henry Petroski’s book “To Engineer is Human; The Role of Failure in Successful Design” (recommended during Brian Cheess & Gunnar Peterson’s AWESOME RSA talk). As such, I have to note that I did not design to obviate failure in this case — but that the failure Ryan experienced can now be learned from and used as a cautionary tale for the future.

As a result of Ryan’s sacrifice of time and his willingness to describe his pain, I’ve updated my documentation to include an SSL Primer and an SSL Certificate FileType Guide, as well as screenshots of what a typical filled-in interface might include. I’ve also added a page explaining how to tell if your environment is set up for PHP version 5 and mcrypt (prerequisites for PamelaWare). I have not yet improved the user interface, but I will. I also think there is more to do, to explain what happens next once you’ve installed and configured the plugin. The great thing is, I’m now focused. And I can always go back to Ryan’s blog if I need to capture that feeling of “WTF do I do now?” :) Many thanks to Ryan for not just walking away, and for writing it all down.

New Stable Version of PamelaWare

For your holiday hacking fun, I’ve got a new version of PamelaWare for WordPress ready!

Version 0.9 is a big improvement over previous stable releases, but still only allows a single card to be associated with a given account. While you’re messing with this version, I’m hoping to add the ability to associate multiple cards with a given account, as well as the ability to add and remove cards while in an authenticated state.

I have tested this version extensively — but I’m sure I’ve missed things — any of you who might wish to play could go to my test blog: http://pamelaproject.com/pamtest if you want to play with a vanilla install, and to the pwwp main blog: http://pamelaproject.com/pwwp if you want to test a blog upgraded from the original beta.

If you want to see what’s up with the Pamela Project, you should check out our development site: http://code.pamelaproject.com.

I’d like to see a few people (like, oh, say, Kim) give this version the thumbs up before I holler about it too loudly. But I’m really glad it is out. You can get tarballs or go directly to subversion from our development site.

Have fun, drop me a line if you see any problems. I’m away snowmobiling until January 2nd, so until then, enjoy yourself, and Happy New Year!

WP 2.1.3 & PW-wp

WordPress has put out a new upgrade for both the 2.0.x and 2.1.x versions – in case all you beta testers were wondering, the new version is compatible with PW-wp operation.

There is, however, a one-line code difference between the version 2.1.2 wp-login.php file and the version 2.1.3 wp-login.php file, so you will have to re-insert the pamelaware redirect into the login file according to the instructions in the Information Card Options page once the upgrade is complete. I have not tested the 2.0.10 wordpress branch, as I don’t know anyone who is using the 2.0 version — if you are, and you want me to test PW-wp in cases like these, just let me know.

XMLDAP on Mac – the Final Answer

It turns out that my last post was not the end of the XMLDAP on Mac story.

If you couldn’t care less about the why/wherefores and just want the answer – you need to install Kevin Millar’s perpetual motion browser extension along with the XMLDAP extension on the Mac, to be guaranteed that the identity selector will work with all the RPs out there. Big huge thanks to all the people who worked on this problem, I think I would have gone clinically insane at about 11am yesterday without you.

Now – onto the geeky explanations:

After downgrading to FF 2.0.0.1, some subsequent further instability, and a reboot, I found that although I could finally successfully get to Chuck’s RP, I still couldn’t use the PW-wp test blog. I had made the mistake of conflating two issues, and assumed that because one was working, the other should be too.

So I started troubleshooting all over again – but this time with a solid example of a service that worked, to compare to my non-functional service. I copied the page source of Chuck’s form object to my test blog, and started changing it, line by line, to match my form object. Here is the line that eventually caused Chuck’s form to fail:

 <input type="submit" id="submit" value="Invoke Identity Selector"/>

And here is the line that works in Chuck’s RP form:

<img src="../images/cardlogo.gif" onClick="infocard.submit()"/>

Yeah, so a basic, HTML 101 type of form submit fails. No way. But it’s true. Feel free to test this out, if you have a Mac: try this link:
With an html submit (first example above, which fails)
and this link:
With an onClick Javascript event attached to an image(2nd example above, which succeeds)

Even if you embed a document.form.submit() call in the document, it fails:

With an embedded submit call

At this point I had enough solid information to talk to Chuck, and bless his heart, he responded right away with a suggestion – if it was a parsing problem, we could diagnose it by installing Kevin Millar’s perpetual motion Firefox extension – because when that plugin is installed, Chuck’s plugin uses the perpetual motion parser instead of the xmldap parser. Sure enough, when the xmldap and perpetual motion plugins are installed together on Firefox, everything works beautifully. Try the 3 links above with the 2 plugins on a Mac — you’ll find they all work.

I *could* change the PamelaWare login page to use the one type of form submit that is guaranteed to work with Chuck’s plugin, and not push the idea of using both plugins together, however from the user’s perspective, this is only a partial solution. As more and more people start writing RP code, there are going to be a million permutations & combinations of a million different forms out there, and I would rather see people installing that extra plugin, so that they can get everywhere, without having to diagnose issues on an RP by RP basis.

So I’m going to update the documentation on the Pamela Project website, and I would suggest that others do so too, to recommend that if you want to use the xmldap identity selector on a Mac, you install both the xmldap and perpetual motion plugins. Yay, case closed, now onto new feature development…

Firefox 2.0.0.2 on Mac breaks the XMLDAP Plugin

Note:  for anyone searching on this issue – it was resolved in version 2.0.0.9 of Firefox and subsequent versions of the xmldap selector.  More info here:  http://ignisvulpis.blogspot.com/2007/11/new-versions-for-firefox-2009.html

For anyone who is using the “xmldap Identity Selector” Firefox plugin on the Mac and has suddenly found that they are unable to log into the PamelaWare Test Blog or Product Blog or Pat’s or Kim’s blogs, the problem is not with the blogs themselves. The problem appears to be buggy nastiness in the Mac version of Firefox 2.0.0.2, which wreaks havoc with Chuck’s plugin (xmldap Identity Selector v0.8.6) . If you uninstall Firefox 2.0.0.2 and then install Firefox 2.0.0.1 from mozilla.com (get release 2.0.0.1 here), you will again be able to authenticate to everyone’s blogs once again. The Safari plugin works as well, so if you want to remain on Firefox 2.0.0.2, you could satisfy your Information Card needs by using that plugin on your Mac instead.

We now return you to your regularly scheduled blog commenting :)