Page Comparison

Use Case

On the basis of the IP address, we will categorize our users into one of three categories:

We have a different Layout consisting of channels presenting public information that we want to associate with each of these groups.

When a user accesses our portal, he is to be categorized based on his IP address into one of these three categories. The portal must present the layout and content associated with that category. The portal must also offer the opportunity to authenticate. Authentication results in a layout based on the user's authenticated identity: a Yale user visiting Rutgers will receive the Rutgers guest layout but upon authentication will get the Yale layout if he has not personalized or his very own layout if he has edited his layout.

When users truly authenticate, they will do so using CAS.

Implementation

Model the categories of un-authenticated users as dummy users.

We already have a generic "guest" user. Additionally we will have a yale_guest and a rutgers_guest.

We assign these users the layouts we want to present to their respective category of users.

Implement the Authentication

We will have a Union authentication context. That union will be configured to stop on success. In the union will be the YaleCASFilteredContext first. Second it will have the IPAddressContext, which we are about to invent.

YaleCASFilteredContext is well documented elsewhere. It gets first dibs because we want a user's explicit (stong) authentication to override the weak IP-address based "authentication" we're about to implement.

IPAddressContext will examine the user's IP address and authenticate as either yale_guest or rutgers_guest as appropriate. It does some clever pattern matching on the IP address.

Guests users need to be able to truly authenticate

We place channels in the special layouts of yale_guest and rutgers_guest providing an appropriate login UI. Since we're using CAS, we presumably use an image representing a login button that links off to CAS with our uPortal Login URL as the "service" parameter. If we weren't using CAS, we'd have a different UI in this channel, such as a username and password form that posts to the uPortal Login servlet for Simple authentication.

Guests must not change their layouts

We edit the CHeader channel to check for the usernames of our dummy users and fail to present the user preferences UI – e.g., the link to Preferences mode.

Presumably if we're really conscientious we'll also go find the other end of that link we're ommitting and ensure that even a clever hacker who reconstructed the URL to access the preferences UI wouldn't be able to get that UI to render as these users. But first pass, we'll just inconvenience a would-be portal defacer by removing the link.

(Incidentally, this is an example of why it's important that CHeader exist and be a real IChannel – it can consider ChannelData conveying things like the username.)

Hey! We're done!