Results tagged “announce”

For the past few months or so I've been dinking around with CAS
and OpenID
and a few other protocols for web single sign-on
. The reason for this is primarily because at work we run a multi-platform web site. For the main content portion of our web site we've been using Magnolia
and for the community side of the site we've been using Drupal
.

It's kind of an odd setup, but it works. The structure might change in the near future, but that's a different story. We've got a few other products and services that we're also building. However, we don't really want members to login multiple times whenever accessing a different segment of the web site. This is where single sign-on comes in.

For the initial revision of the work I created a homebrew solution of single sign-on. It's immature, it doesn't really handle some of the security concerns it really ought to, and it's maintained only be me. Needless to say, this was a quick and dirty rather than ideal solution. The plan all along was to create a tool that could provide a single sign-on service in a standard way so that we didn't have to do much, if any, of the maintenance.

My research led me to conclude that CAS (Central Authentication Service), created by Yale, is really the best solution available. There are several others out there including Cosign, Crowd, OpenSSO, and others. CAS is the most widely supported of these schemes and it implements a very robust, simple, and functional protocol.

The major drawback to CAS, for me, is that it is written in Java. This isn't a terrible issue at work since we already use a J2EE server to support Magnolia. Yet, my experience with J2EE servers (even the ones that are just servlet containers) has led me to believe that they tend to be more difficult maintain than Apache with CGI or FastCGI add ons. Furthermore, I have some interest in using CAS on my own web site, but don't have the means to host a J2EE server without changing how I host my site (and I'm very happy with DreamHost
).

Therefore, I decided to see how difficult an implementation of the CAS server protocol would be in a different language. It was not difficult. The protocol requires fewer than 10 HTTP request/responses to be implemented and the processing required to build those actions is straightforward. Viola, we have CAS+.

CAS+ implements the complete CAS 2.0 protocol. As far as I can tell (without asking as I haven't contacted anyone in the CAS realm), the CAS 3.0 protocol does not exist or does not differ from the core of CAS 2.0 in that it consists only of aspect-oriented hooks to extend CAS+.

My plans branch further in that I want CAS+ to be a more general solution to this problem than CAS is. CAS is meant for use in a totally secure environment, whereas I'm willing to sacrifice a few things for additional flexibility. I've implemented CAS+ in Jifty
and am using CAS+ as a test bed for the work I'm doing with Jesse Vincent on the "virtual-models" branch of that product. Finally, I am thinking of building CAS+ into a more general authentication solution. There's no reason why it couldn't also support some of the other SSO protocols that exist and I would love for it to be an authentication source and sink for distributed authentication protocols like OpenID.

Okay, so that was kind of a meandering way to introduce CAS+. If you're at all interested, feel free to check out the Subversion repository where it's hosted. This is the only project resource I currently have for accessing anything about it. If you want help with it, you can use the Jifty developers mailing list (see Jifty.org
for information) or see me, zostay, in "#jifty" of the freenode IRC server.

Here are the important links:

• Via Subversion: //svn.jifty.org/svn/jifty.org/CASPlus/trunk
• Brows the Web: //svn.jifty.org/jifty.org/CASPlus/trunk

I'm kind of excited to have an article
listed on the front page of Perl.com
, one of the sites run by O'Reilly & Associated
publishers. I hope it will be the first of several and my employer has offered to let me spend time during work developing articles such as this.

Anyway, if you have any interest in using Java, Perl, or just the Content Repository API for Java from Perl, read my article on Perl.com: Using Java Classes in Perl
.

Cheers.

I am never satisfied. I've been working on this thing for more than six years now. I finally rewrote it and rewrote it and rewrote it until I actually had something useful for the CIS Support Site. I think I've counted about ten major rewrites (or sometimes full do-overs) up to this point, so this makes the latest rewrite I embarked on two weeks ago number eleven.

In April, I suggested that I was Outgrowing Mason. Assuming that I complete the 0.11 branch of Contentment, Contentment is no longer Mason-based. Mason is really a nifty thing that I will use again, but Contentment was really abusing it. Mason is kind of a mini-CMS with a custom templating language, rudimentary file handling, and some other extras. The templates use Perl embedded in text which is neat-o for rapid templating of stuff—which is what I wanted with Contentment in the first few revisions (especially back before I knew that what I was doing would become Contentment 0.7—a do-over since 0.5 was a completely different code base). Mason mirrored some of the features I needed.

What I wanted at the time, was a way to easily identify the type of a file and dynamically convert that into HTML and then render that HTML in a custom theme. I also wanted the ability to auto-generate indexes of the files. The system used no database and, though I experimented with it a couple times, no caching. However, as I moved through Contentment 0.9 to add database support, form-handling, improved theming, etc. things started to get messy. The layered file system Mason wants to use is really not very flexible. Technically, you're supposed to be able to replace the file system resolver module with a custom handler, but that doesn't work very well. I did it, but had to hack in a couple of ugly spots to get it to work.

Also, embedding programming languages into text is my idea of a bad idea for anything but the simple. In my opinion, logic and content should not mix whenever possible. Thus, most of my Mason components were either 95% Perl or %95 HTML with a smattering of Perl. I don't need Mason in this case, I can just use Perl scripts directly or a templating language that doesn't mess up my HTML with embedded Perl.

Finally, Mason really hates handling non-Mason content. I'd managed to do it through creative use of autohandlers and dhandlers, but the solution was slow and unsatisfying. Contentment doesn't care what kind of file it's serving, so Contentment and Mason were again mismatched.

Without Mason, I was suddenly freed of several restrictions. Before I had organized the entire layout of the web documents under a directory named "docroots" which contained a "master" document root and a "site" document root, which were layered on top of each other in the usual Mason way. This was ugly. It made it hard for anyone unfamiliar with the system to find the files they were looking for and it resulted in all the features of Contentment being mixed together with a minimum of encapsulation. (I'm a computer scientist, I must have encapsulation!)

Additionally, each installation of Contentment required it's install directory to work well (including a generated Contentment::Config module to tell the system where to find it). This meant that the typical CPAN installation could not work well. I want this module to install with the usual CPAN way because it makes adoption of Contentment that much easier:

cpan Contentment

WIth the 0.11 rewrite, I now have a single document root, named "htdocs" (a familiar title). I have moved all of the Contentment specific stuff into a folder named "plugins" that separates the functionality into logical groups that can be loaded or not. This layout also eliminates the need for a custom library install and configuration module. Now, you just need to know where your plugin directory is kept.

The CPAN install thing is still a little iffy because while just running the above command should work (once I make a release), you won't have a working install without a plugins directory, the htdocs put into the correct place, and some other configuration. I'm working on a post-install setup script that will help with the rest. Since we have to configure a web server to use the app, I can't see how we can get it any simpler than this. At this point, the install looks more like:

cpan Contentment
cd ~/.cpan/build/Contentment-*/
bin/setup-contentment

That won't work everywhere, so I'll probably come up with directions assuming a direct download and let the CPAN'ers figure out the rest from that. You'll have to read the docs to get anything useful anyway, so it's probably not a big deal.

Anyway, I really, really like where this is going currently. I'm hoping to have the old system dropped into 0.11 in another couple weeks and to have my web site operating off of it shortly thereafter. We'll see. I also need to update all the documentation. It's mostly right still, but the changes will require some tweaking.

Cheers.

Well, the migration of mail from CIS to CNS is done. Our IMAP is handled by them. Our SMTP is handled by them. Our authenticated, off-campus SMTP is handled through them (via the as-yet-undocumented server). Our Webmail is handled by them. Mailing lists are handled by them through the LISTSERV.

I've setup MX records for the important hosts and working on setting up the rest. We've reconfigured Pine and Mutt on the local system to use them. (Pine presents a nice view of both their folders and old CIS local folders. Mutt has always offered the ability to read any folder you hand, so getting local is just "c ~/Maildir/"). I've updated the documentation on how to setup email so that everyone can set up their own clients. And I've spammed most of the faculty, staff, students a few times to let them know. Speaking of, I probably need to spam the students again...

Okay, I've been using SF.net for a long time for the Contentment project for almost four years to the day (started August 5, 2001). Well, today I said good-bye. I'm not requesting a project removal or anything that drastic. Think of this as more of a separated married couple rather than a divorce, but I'm contemplating the divorce.

Anyway, the event that actually brought it on was the fact that I was having a hell of a time trying to get Brian D. Foy's extra-handy release script to login to SF.net. I still don't know what was wrong. I dug for about an hour and began to evaluate the value SF.net was adding to my project and decided I was getting too emotional about it. SF.net wasn't providing me an hour's worth of effort in value.

What do I need in project management? Well, I need a source code repository. I've quit using CVS for the most part in preference of Subversion. However, SF.net has stated plans for, but not an implementation of Subversion, yet. So, I'm not using any of the public CVS facilities.

I need a way to make source tarballs and release them for download, preferrably on a mirror, in case my project ever gets popular. As a Perl project, the most natural choice for this is CPAN anyway. Uploads to CPAN require a two-step process that is so easily automated (in about 30 lines of code after the FTP upload), it's laughable to see that the same process on SF.net takes over 200 lines of code (again, after the FTP upload). CPAN also offers anyone who wants to give Contentment a shot the ability to just install it like:

cpan Contentment

that will download the latest version, unpack, build it, test it, and install it. SF.net can't do that (nor should it, really), but again, I don't really need them as another mirror. (Btw, at this time, this isn't the best possible way to install it, but it does work. I hope to make this a fine way to install eventually...)

I need a web site. Well, I need a web site I can control to a greater extent than SF.net offers. I have hosting through Dreamhost and can even use FastCGI to make database connections persistent. SF.net doesn't offer any such thing (of course, I pay for DreamHost). In any case, I don't use SF.net's web hosting, database, etc.

I need to post news. Well, heck, this blog can do that and I don't have to use the pathetic little "News" thing SF.net offers. No. No way.

I need to have bug posts. The "tracker" on SF.net is not what I consider bug tracking. It's more like a headache. My favorite bug tracker is RT. Handily enough, CPAN offers an RT bug tracker.

What else might they have? Hmm... donations. Well, that's easy enough to setup through PayPal directly. Why do I need them for this? PayPal also skims less off the top. I'm not getting any donations anyway. Mailing lists are also nice, but I don't really have anyone to talk to just now and I can get a list through Perl.org and have my project identified with Perl directly or I can setup my own mailing lists with DreamHost.

The SF.net web site is ad-ridden, slow, and doesn't really provide anything I can't either provide myself (Subversion repository and public mirror) or can get through CPAN (most the rest). Anyway, I'll keep my project alive there for now, but unless SF.net makes some drastic improvements, I imagine I'll ask for project removal.

SF.net was a neat idea 4 years ago, but the improvements that have been made haven't really impressed me that much. They've been very incremental and not very drastic. The paid side of things sounded like a great idea when they announced it, but they offer things like a better search tool and more ways to get project news. Bah. Who cares? I want better project management tools. If you gave me some compelling features, sure, but not for what they offer.

It seems to me that SF.net needs some innovators to come in and revamp the place. It doesn't even look that different than it did 4 years ago. Stagnate. They should fix that. If they do, perhaps I'll come back. In the meantime, I'm headed over CPAN where real changes have taken place in the last 4 years.

I finally got a new release of Contentment out yesterday. I've been working on this for almost two months as I'd created bunches of nasty bugs with a few big changes I'd made recently. I've got to start using the inards of Subversion a little better (temporary branching would have made this a much smaller problem).

Anyway, with this new release the Contentment web site is again running the latest version of the software and has the latest documentation available online. Now that Contentment is working again and that I've gotten the VFS system to a very nice point, I'm going to start porting this blog and such to it. Once done, Contentment should be very nice and I'll probably start promoting it a bit more.

The latest version uses File::System as the basis for the VFS, which is much more advanced that the previous VFS system. I hope to expand the use of this system in the next release to allow for arbitrary SPOPS objects to be used as backends for the VFS.

This version also features a hooks system, which is used to implement session and context creation and also the transformation and filtering system (or rather the request has hooks that these systems are added on to). This means that themes, transformations, filters, etc. can be replaced or removed if someone doesn't like them. I think I will place the caching system here as well. Furthermore, I think the filter and transformation systems will utilize the hooks rather than the rather stupid module loading system used now. The file typing system (both for input types and for output types) will also be reimplemented using the hooks system.

Those are the two biggest changes as of this release besides the bug fixes allowing the system to actually work now. I will try to make releases more frequently in the future and will try to break the system less often. (And I need to port the old aggregator so that the Contentment web site can pull these blog entries...)

Phew. If possible, in the future, I'm going to avoid making a major web launch on the first weekend of Daylight Savings Time—quite easily Benjamin Franklin's worst idea.

Essentially, the latest and greatest update for NewHopeKS.org is online. I cut over to the new software last night at 10:00. Anyway, I thought I'd mention a few details of this endeavor.

The new site is Drupal-based. Drupal is the same software that runs this blog, as of this writing. We picked it for a number of reasons. Drupal is popular, easy to understand, easy to extend, has lots of existing extensions, and is probably going to be around for awhile. Thus, if the three of us who are responsible for the web site suddenly moved away, it shouldn't be hard to find someone else to take over. (One must always be careful of volunteer commitments, because volunteers often fail to keep commitments. While Tim, Eric, and I are actually committed, we've gone through this process on the assumption the next person in charge might not be.)

Now, the web site isn't just Drupal—it's the CivicSpace-based distribution of Drupal. For those who know the history of this project, CivicSpace is the decendent of the DeanSpace, which is the software that was used by Howard Dean's presidential campaign web site. At first, it may seem a little odd for an evangelical church to be using this software, but evangelicals are advocates as much as any other CivicSpace site. We just happen to advocate for spiritual change rather than social change. Because of this and other factors (primarily Biblical guidance), we have quite a different M.O. for performing this advocacy, but there are still many similarities.

Anyway, at this time, we're barely scratching the surface of what we can do. As of this morning, the web site is a collection of events, announcements, and informational pages on New Hope. The web site will probably start being updated by church staff in another week or two. Parts of the web site will be modified by other volunteers starting today (especially, the SHAPE section). I am also going to start seeing what we can do about uploading our recorded messages. There's really a lot of work to be done still, but it's a great start.

I'd like to mention that the design of the web site is mostly due to the handiwork of Eric Benson. Unfortunately, he has no current personal web presence I can link to—many domains but no content. ;) I think it looks slick, though, as he tells me, most of the work isn't his, but he's got big-big plans. I can't wait.

Now, for the problems. The biggest and baddest problem of all is that the taxonomy system of Drupal is both awesome and a pile a poo. I'm probably going to patch Drupal according to the recommendations of GreenAsh in his three part series on taxonomy. It's either that or we see if Drupal figured some more stuff out when 4.6 becomes a stable release. The main issue is, that it seems obvious to arrange the New Hope web site into ministries: LIFE Groups (small group Bible studies), SHAPE Groups (small group studies of personal gifts), Construction Zone (children's church), Youth Group, etc. In fact, these things really could be mini web sites in their own rite. LIFE Groups could feature pages specific to each life group. Construction Zone could feature pages specific to each class.

However, Drupal is terrible at this. The problem is that the taxonomy system is too flexible. It can do a breadcrumb trail, but almost all documents show up in "Home". Gah! The reason this happens is because breadcrumb trails are single-inheritence heirarchies, just like a typical directory or file system. The taxonomy system of Drupal allows for mutliple-inheritance heirarchies and even more complicated structures, so a simple breadcrumb isn't possible without enforcing some sort of policy on this system. Honestly, this isn't a problem for me, but it might be for someone else. However, there's no reason I couldn't volunteer to be put under that policy and another site could decide not to be.

Anyway, GreenAsh has found some resolution to this by doing just that, he's established a policy that says that every page must be categorized into a top-level single-inheritance heirarchy. Then, he patched the Drupal source to make it work. I'm trying to decide if we want to do this or not. It would make a nice breadcrumb trail along with making new nodes a little simpler to organize based on the primary category. He also has some nifty stuff for cross-category breadcrumbing, which would be handy in our case too. I think I'll probably do this or some variation to make the New Hope web nicer to browse.

The biggest issue is, what happens at upgrade? Well, as far as I can tell, we're not actually doing anything bad to tables themselves. His patch just seems to nudge the behavior of Drupal in a slightly different direction, and then only in the places of taxonomies and breadcrumbs. The actual data stored in the system is unchanged. I imagine, we could lose some of the features for a time during upgrade, but still have all the raw materials to do it again. On the other hand, if Drupal actually implements this policy or something like it, but chooses to do so in a different way in a future version, this will be difficult to deal with.

However, I think it should be doable.

Nifty. After a harrowing week of work between putting out fires, keeping up on other projects, writing an exam, and dealing with some other class related issues, I finally managed to get the major changes need to the forms API complete. Because of these changes, I was able to move the CIS Knowledge Base over to Contentment this afternoon.

The major "coolness factor" for the CISKB is that the new form handling API will allow us (or principally, me) to add handy new features to the CISKB. Currently, there are only two forms on the site: change password and account application. The new account application is neat because it uses our newly acquired access to KEAS to verify that every account has a matching KSU eID and then attaches the user's unique identifier to the application, which will be used to create the account (once I make the minor changes needed in the account management software).

I plan to better integrate the Knowledge Base into RT to allow us to post a "Known Issues" page to help keep those pesky repeat tickets away. I also want to add some specialized forms for things like requesting file recovery, requesting help when email and account access aren't available, etc. I also want to setup a form for allowing students to automatically reinstate their account if it becomes disabled because of printer fees, password expiration, lost password, etc. There are a lot of mundane things that the systems staff deals with on a daily basis (especially around the start of each semester) that we can drop onto the web site.

As for Contentment proper, I want to port one more web site to it before a formal release, i.e. Andrew.Sterling.Hanenkamp.com. In the process, I also hope to improve the Contentment.org web site and drop some decent documentation in (er...create the documentation that is largely non-existent).