Securing SkySales With Rules

December 22nd, 2008

Version 1.3 of New Skies brought about a radical change in how SkySales handles page security. Instead of restricting access based on the previous page, conditions can now checked before the page and it’s controls are processed and rendered. In transitioning to SkySales 1.3 and above, I’ve found that page security is often overlooked. In the
cases where security is addressed, I’ve seen many attempts (even a custom attempt to whitelist pages the way the old versions of SkySales worked). I hope to address rules here and provide airlines the ability to secure their pages correctly.

Why a World With Rules?

An unsecured SkySales instance can allow customers to do unexpected things with a booking. Here’s a real-world scenario that would make marketing teams roll over [in their sleep]:

3rd Party Travel Reseller (Screen Scraper) uses automated tools to book the lowest fares for highly desired markets as soon as the fares are made available. Reseller then sells the fares on their site, Ebay, Craigslist, or some other channel for a nice markup. Once the fare is purchased by the actual customer, the reseller retrieves the booking, changes the name through the booking process and commits it through the wait page. (This scenario is assuming that name change fees are not set)

Strange things can happen when a customer retrieves a booking then types in a booking flow page name. Most of the controls used in SkySales don’t care if the booking they are operating on is brand new or if it is a previously committed one. This is not a fault of
the product. The SkySales developers were counting on the proper configuration of rules in the various flows a carrier sets up. If Quality Assurance isn’t on top of their game, it’s entirely possible to overlook the implementation of rules during a conversion to New Skies.

Rule Philosophy

The most effective rule philosophy is to keep you rules very simple and descriptive. This allows developers the ability to understand the rule by just reading the name. For instance, if we had a rule that required a booking to have at least one new flight, our rule should
only be checking for a single, non-committed flight and should be called something like NonCommittedFlightRule.cs. Don’t combine logic in rules, remember we can stack them in order of precedence!

Proper rule configuration allows us to not be concerned about what page the users are linking to. If a user had, for instance, bookmarked their confirmation page – we could redirect them to the home page which would have a widget for the user to retrieve their booking. Without a rule on the confirmation page, we may get a
strange-looking page or a nasty error from the controls attempting to
retrieve a booking in session that was empty. If we decided to
get really customer-centric and bookmark friendly, we could store the
state we were attempting to access when the committed booking rule
failed, take the visitor to a custom page that collects enough
information for us to retrieve the booking, then take them back to the
page they were attempting to link to (where it makes sense).

Rule Bouncing

While rules should not be overlooked, they can cause “bouncing” that may be hard to trace. If you have a tiered set of rules that bounces the person back in a process flow until it reaches an acceptable state, it’s difficult (without some tracing or debug help) to know how many states the user has passed through or the rules that have failed. Here’s an example of a bouncing flow:

User types in: [airlinesite.com]/Payment.aspx in a new browser

The site attempts to load Payment.aspx, but it has a rule that there must be Flights on the booking. The flights rule redirects to the Select.aspx page where the user may select a flight.

However, on entering the flight select page, a rule is run that looks for a flight search request in the session and it redirects to the homepage.

The effect is that we type in Payment.aspx and the homepage loads (with payment.aspx still sitting in the address bar). It can be helpful to write in some rudimentary logging so that web testers can check that the rules are working.

Custom Base Rule

The best way I’ve found to gain control over the rules framework is to write your own abstract base rule inherited directly from the Navitaire BaseRule. What the out-of-the-box Navitaire SkySales rules fail to do is to supply a good base rule that gives you ready
access to all of the objects you’ll need when writing your own rules, namely: UserSession, Controllers, runtime attributes, ResourceCache, etc. Child classes should not have to override
methods just to store critical objects like the ObjectManager themselves.

Below is a link to a base rule I’ve created and a simple rule that checks the booking state to demonstrate how simple custom rules are that use that base class:

WebBaseRule.cs File

NonCommittedBookingRule.cs

I hope this has been a decent introduction to the concept of rules. If you’d like some help setting up rules on your site or have comments on the rules I’ve provided above, don’t hesitate to contact me.

Filed under SkySales