First: The facts of life.

1. UMBC has the concept of a “student ID number.” This number is used in SIS as the primary key for almost every table. All students have these IDs, as do faculty members who teach courses, etc.
2. uPortal itself does not use or require this number to do its work.
3. The legacy myUMBC portal uses this number to do its internal session management. Also, we need to know this number to look up any SIS data on behalf of the user.
4. uPortal proxies to the legacy portal to do most of its “real work” involving SIS functionality.
5. When a user logs into either portal, they provide only a username and password. We need to be able to take that username and map it to a student ID. To do this, we query our campus LDAP directory.
6. Not all users have student ID attributes in LDAP, for various reasons. In particular, if the help desk manually enters someone into the directory, they sometimes leave out the ID.
7. These users have problems accessing the portal.

Now, in the old portal, we handled these cases by prompting the user to manually enter the student ID and a 4-digit PIN (don’t go there). In uPortal, we don’t have this logic. So, it just breaks. In fact, it breaks in such a way that “bad” HTML is generated, so the channels in question don’t render at all.

Well, the rendering issue is fixed now, but it was tricker than I thought it would be. It wasn’t just a matter of tidying the HTML in the legacy Perl code. The problem was actually happening in my local connection context code. Basically in these cases, the connection context can’t generate a valid legacy portal session at all. And when that happened, it was crapping out before it added a couple of necessary URI parameters to the web proxy URL. Long story short, it was trying to bring up a legacy portal login screen, complete with navigation, decoration, and lotsa sloppy HTML to boot, and uPortal of course was refusing to render it.

Fortunately it appears that the solution to this is going to be human-engineered, meaning I will just display some appropriate wording that tells the user how to remedy the problem. So, I shouldn’t need to do anything fancier than what I’ve already done.

As an aside, I’m still working on the best way to fix these HTML-tidy issues with the web proxy channels. First trick I try, is masquerading as the user with the problem, finding the bad channel, and examining it outside the portal by passing the same arguments to the legacy myUMBC web app. Then I can view the document source, paste it into emacs, and look for problems. Once I think I have it fixed, I save it as static HTML and point another web proxy channel at it, to see if it’ll render. That usually works. Sometimes I need a Java stack trace, which can be problematic because “ordinary” users don’t have the ability to display stack traces within channels (there might be something in portal.log, but it’s often hard to sift through this and correlate log entries with individual problems). In these cases, I hack the code to force the error condition to occur with my own account. Then I can see the stack trace, find out the nature of the evil, and fix it. Yeah, it’s klunky, but it gets the job done.