I've been a busy contributor to the Symfony framework
Academic folks are increasingly excited about Shibboleth
, a system that allows students, faculty and staff to log on to many different web applications and even permits schools to authenticate logins by students at other schools. It does lots of other stuff too, but those are the basics. One of our primary clients is big on Shibboleth, and we've integrated it with Symfony... more than once, in different ways, on different projects.
Doing stuff more than once, of course, is usually a big waste of time and a violation of the DRY rule (Don't Repeat Yourself). So this week we released sfShibbolethPlugin
, which builds on the well-known sfGuardPlugin, making it easy to add Shibboleth authentication to a Symfony application. In English, that means students can log in without the need for a separate database of usernames and passwords just for your application.
Shibboleth can do a lot of things and sfShibbolethPlugin doesn't support all of them, not even close. But it's quite useful out of the box. And it has some nice features, including support for snagging the user's display name ("real" name) from Shibboleth if you have access to that... and features that make it easy to add a "registration page" where users can provide any information you consider essential that is not provided by Shibboleth. When users first log in, they are firmly directed to the registration page, and can't do anything else until they complete it (well, they can log out and go away). This comes in especially handy if Shibboleth is providing only a username and you need a full name and an email address.
Speaking of sfGuardPlugin, that plugin provides a reasonable interface for managing users: you can easily grant them membership in various groups and so forth. But at the moment, I'm building a system that will likely have thousands of users. And the thought of not being able to filter those users by group didn't give me a warm fuzzy feeling. So I added that feature, and realized I wouldn't be the only one who needed it.
Today I received commit privileges on sfGuardPlugin itself
(thank you, Fabien) and contributed support for filtering the list of users by group
back to the sfGuardUser module. That code hasn't appeared in a new official release of the plugin yet, but those who use Symfony 1.0 can get it right now by fetching the current 1.0 branch directly from subversion (this part, I won't even try to translate into normal-glish).
And of course there's last month's sfTagtoolsPlugin
, which allows for typeahead (auto-complete) of tags, much like that Flicker provides as you're typing in the tags field.
So far I've been coding in Symfony 1.0, and my plugins haven't been tried in a Symfony 1.1 or 1.2 environment. I'm watching the newer versions of Symfony with interest, but so far too many things we need in our work are undocumented or absent. That will change soon, I'm sure. Meanwhile 1.0 is rock-solid for us.