Jeremy Smith's blog

Entry Is Labelled

Case.tv

Okay, I freely admit, when I first heard about Case.TV, I was skeptical. The following thought went through my head:

Oh God, I wonder what bloated vendor's framework that was built with… I wonder if any browser other than IE6 on Windows will work… I doubt it uses anything other than WMV files… *sigh*

Okay… well… I was wrong.

The site is designed in modern web technologies. It has clean markup. Clean use of CSS. It doesn't validate but only because one small closing / didn't make it in (I can forgive that). The site uses unobtrusive Javascript that degrades if JS is turned off (save for one body onload="" call that I can also forgive). It works in every browser and platform I've tested. And, to boot, it has an Accessibility Statement that references Dive Into Accessibility.

All right. All right! I give! Color me impressed. (See also I'm a Snob When it Comes to Companies' and Persons' Web Pages' Markup and CSS.)

Now someone needs to fess up. Who put that site together? Someone in ITS? Paul, was that you? Was it done by a contractor? Someone other than Complex Spiral? If that's the case, I'd like to know which company.

So come on… out yourself&hellip who did it?

<aside>

One minor nit that I can't forgive, though — the login procedure. For example, this JS function — https://mv-web-secure.case.edu/scripts/cp.js:

function fixPwd() {
var password = document.forms[0].pwd.value;
password = password.replace(/&/g, "%26");
password = password.replace(/\+/g, "%2B");
password = password.replace(/=/g, "%3D");
password = password.replace(/ /g, "%20");
password = password.replace(/:/g, "%3A");
password = password.replace(/;/g, "%3B");
password = password.replace(/\?/g, "%3F");
password = password.replace(/\@/g, "%40");
password = password.replace(/\$/g, "%24");
password = password.replace(/\//g, "%2F");

document.forms[0].pwd.value = password;
}

That's… uhh… no good. CAS integration would fix up that problem.

</aside>

Comments

  1. gravatar

    Nope, not me. My first thought when I heard about it was "why not just use YouTube?"

  2. gravatar
    My first thought when I heard about it was "why not just use YouTube?"

    I had thought that, too. There is something to be said for being able to bring some of this video content underneath the "case.edu" brand. In addition to that, underneath the domain, it is easier to restrict access (if that feature where to be added).

  3. gravatar

    Actually... Time to get the ITS programmers together. Sean Maxwell did all the programming with UI design from Megan Linos and UI support from DJ Dohanyos.

    A number of drivers for Case branding... the most important of which was being able to integrate Case's MediaVision courseware into Case TV which includes video content that faculty wish to only have streamed with authenticated Case IDs.

  4. gravatar

    Thanks for all the nice things you had to say about the site. I have been pushing really hard for accessibility in our websites.

    I am a systems programmer, so I don't know HTTP inside and out. Only enough to get by when I am working on things. The minor nit was something I did, because it seemed to me like the form password field was not URL encoded when it was sent, with the form. If I'm wrong I'll just take the script out. I had never really went into researching it. It was 3 years ago when I started handling passwords that way, and I probably was just unpacking the URL in the wrong order, and never went back to look at it. Thanks for drawing my attention...

    I hate CAS. Whatever CAS is doing I can do better and faster. I don't mind integrating with it, but relying on it is a bad idea in my opinion.

    Thank you for the feedback.

  5. gravatar
    Whatever CAS is doing I can do better and faster.

    Better and faster for you to program maybe, but you're undermining my desire to only log in once, and to a site I already trust.

  6. gravatar

    I mean, better and faster for the client.

    Like I said, I don't mind integrating with CAS so if the user already logged in to CAS somewhere else they will be shuttled right in.

    But if they do not like to use CAS, taking the extra time to setup the initial CAS session gets irritating when you have to keep doing it throughout the day. And it does take longer to setup the initial session in CAS than it does to log in directly with a single HTTP request and some LDAP operations. I also do not like having my credentials side stepped by a hashed ticket somewhere. If a resource requires authentication, I want it to require my credentials.

    It depends on user practices whether CAS saves them time, or costs them time. I like to give them the choice. And you are right, I should get it integrated for the CAS fans. I just have not had the time or initiative to do so yet, but now it looks like I have some initiative.

    I do have an issue with the blanket statement that CAS is the way to handle all logins for the university. There is room for each paradigm. Thank you for letting me know how you feel.

  7. gravatar

    I would like to add Jeremy, that using an onload in the body which you cite as bad practice on my site is also used on the CAS login page to change focus. That is an accessibility 101 no no.

    Also, the error on validation for tv.case.edu was a missing alt="" on an image, not a missing close tag, which I think is much worse than missing an alt on an image.

    W3C Validator screen shot

    Either way it is fixed now. Thanks for pointing that out.

  8. gravatar

    "Whatever CAS is doing I can do better and faster."

    Yes, you can probably do it faster. But at what expense?

    Single sign-on is not just about convenience (although it is more convenient once the number of sites you log into is > 1). Single sign-on is about the security more than anything. When I log into CAS, I trust that my secret password is safe along every step of the way. Unless things have changed from when I helped deploy the service, your password is *never* sent over plain text on the network and furthermore, all network traffic is contained within the ITS data centers. Do I get these assurances when I log into any site on the network? From experience, I can tell you most people using LDAP authentication do not use data stream encryption. Also, how am I sure my password is safe with the 3rd party? How do I know that the end service isn't collecting a list of passwords or using the password to check my email or something? I'm not saying you are, but this is the type of thing that CAS can help prevent. For these reasons, it really bothers me to supply my credentials to any site not login.case.edu.

    Regarding the onload in body, it is irrelevant for both examples cites b/c when scripting is disabled, everything falls back gracefully. In the case of login.case.edu, you don't have the cursor on the username input. For tv.case.edu, you get the static images instead of "random" ones. Big deal.

  9. gravatar

    This was not meant to turn into a tear down session on CAS. I just did not like the tone of the implication that simply implementing CAS would fix anything. I thought it was sort of condescending and thus wanted to voice my opinion on why I choose to not make CAS my primary authentication method. I meant no offense.

  10. gravatar

    I checked it out, and besides just doing twice the work of double encoding and double decoding the password, I don't see whay the password script was a standout item. If you would not mind giving me a little more info on why that was really bad I would like to know. fyi, I do use secure sockets when connecting to the LDAP servers. Thank you.

  11. gravatar
    I don't see whay the password script was a standout item. If you would not mind giving me a little more info on why that was really bad I would like to know.

    Sure. I'm happy to help out.

    There are many characters that can require URL encoding/decoding. Having to account for them all would be difficult (what happens when someone's password includes "æ" or a "è" character) and would actually be nearly impossible because the space character " " (the space character is hard to represent when typing). According to the spec, spaces can be represented via "%20" or the plus "+" sign in URLs. It's tricky (and inconsistent) when one happens over the other.

    Attempting to encode/decode all of the different characters that undergo (or can undergo) URL encoding/decoding in Javascript would be a lot of work to make sure you have complete coverage. Unit tests on that code would help (there'd be a lot of tests to write) make sure maximal coverage was achieved.

    Personally, I'm far too lazy to write that much Javascript.

    Javascript does have the built-in functions espace() and unescape() that may help. YMMV with the use of those functions.

  12. gravatar

    I understand what you are saying, however, I think the main point is being missed (the main point being, I was neither helping anything/nor hurting anything, just confused about something)

    - I had the misconception from a few quick hacks that for some reason the password field was not being URL encoded.
    - I wrote a JavaScript to URL encode the characters I was worried about into escapes, and server side wrote a function to decode the escapes.
    This was before I had written my wrapper around HTTP requests, so at the time, it was circumventing a bug in the way I was unpacking
    the form variables. Now that I have a standard sub to do that, I was only doing twice the work, because the password field is in fact encoded, and I was just encoding the encode, and decoding the decode. It did not present a case where a password containing characters I did not escape would not be transmitted correctly, it actually would. I just was adding extra work to the client upon request. Ultimately, it was unecessary, but not harmful. I took out the script on Saturday. Thanks for the feedback.