Shorter URI's for web apps

Some non serious IT service cos develop web apps and roll it out to customers without paying attention to little details like URI's, UI component names they choose in HTTP communication, information they drop in cookies, etc., They little realize these oversights pose potential security risk to their application, especially when they are exposed over internet not to mention how silly it looks to expose your class name or object responsibility to users of the system. Some common examples look like,

http://my.domain.com/myapp/RegistrationServlet?userid=abc&password=bbb&address=blah

Issue 1: You indicate what technology you implement and which object is working your request; the complex your app the longer the url normally tend to be.
Issue 2: Whether you do FORM POST or pass it in as URL args, attaching element names like userid, password, etc., provide obvious clues to what you intend to do. Not a good practice.

With such apps the common dilemma we all face is not wanting to invest time working on nomenclatures. Luckily, webservers come to our rescue

Based on your deployment architecture, whether you have an application server + webserver or just webserver, one can use either mod_rewrite or mod_proxy modules of apache that can shield longer URL's from user with a short one.

If your app lives only on webserver, say a php or asp based application you can rewrite the above example like,

RewriteEngine on
RewriteRule ^/reg$ /myapp/RegistrationServlet
RewriteCond %{QUERY_STRING} id=([-a-zA-Z0-9_+]+)
RewriteRule ^/?reg$ %1? [R=301,L]

which is basically same as http://my.domain.com/reg/abc/abb/blah

If your app has webserver fronting an application server you cannot just rewrite, you may have to forward proxy short url requests to long one internally before some kind of plugin can forward that request to application server.


SQL Gotchas

While skimming my old zip drives I came across this interesting note that I had written years back related to SQL statements and prepared statements using iBatis framework. It was something to do with datatype of columns and implicit joins using prepared statement.

Problem: Issue of a static sql statement returns expected results, same statement issued as a prepared statment with parameters fails.

Static statement:

SELECT
nvl(sum(BATCHREL), 0) as CNT
FROM
userapplications a,
users b,
customers c
WHERE
a.USERRID = b.RID and
b.CUSTOMERKEY = c.RID AND
lower(c.ID) = '900100ev' AND
lower(b.ID) = 'admin1'

Prepared statment template:

SELECT
nvl(sum(BATCHREL), 0) as CNT
FROM
userapplications a,
users b,
customers c
WHERE
a.USERRID = b.RID and
b.CUSTOMERKEY = c.RID AND
lower(c.ID) = ? AND
lower(b.ID) = ?

Parameter values: '900100ev','admin1'



What I saw happening:

The c.id metadata was CHAR(20) and did not match the parameter passed in using prepared stmt, unless I padded it with spaces (to meet the length), however when I chose a literal string it worked w/out issues. I had to modify the prepared statement as follows (and it works)

SELECT
nvl(sum(BATCHREL), 0) as CNT
FROM
userapplications a,
users b,
customers c
WHERE
a.USERRID = b.RID and
b.CUSTOMERKEY = c.RID AND
RTRIM(lower(c.ID)) = #companyid# AND
lower(b.ID) = #operatorid#

Parameter values: '900100ev','admin1'

Mobile Web Applications

Recently a colleague of mine was discussing developing mobile apps for smartphones when I recollected my past engagement where I had to architect a digital coupon system running on web and mobile platforms with single code base. It presented quite a challenge given that your web apps are content rich and mobile devices had limited real estate and each device had different ergonomics.

Here are some lessons learnt from my experience -

Before you dive on mobile enabling consumer, read these design constraints and please come up design notes/solutions that will address each one of them.

Web and mobile are different media serving different requirements and different fields of application. Web mobile will be targetted towards 3 segments: Feature phones, smart phones, PDA's

• Feature phones usually come in candy bar, clamshell or slider form. They have a 12-key layout.
• Smart phones share the same features as a feature phone with two primary differences: Its ability to run additional third-party applications and a slightly larger screen. Smart phones typically use a more full featured operating system.
• PDAs often include QWERTY keyboard and stylus in place of the 12-key layout on normal phones.They also feature a larger screen.
  

Design constraints:

• Mobile browsers may stop scrolling vertically on pressing the down key when a link appears in the currently viewed section of the page.
• Some user plans may be tied to data bandwidth and therefore keep the data traffic to a minimum.
• Mobile devices have limited memory, limited CPU and run on slower networks than desktop computers, running scripts on client side will drain the battery. Keep such stuff to a minimum.
• Mobiles do not support popups/frames/etc. Not all mobiles support scripting/styling. Identify mobile device and then render pages as per device support features. Page Design will need to take account for diff. screen sizes, devices.
• The W3C suggest that all the images on a page should total less than 10KB. Keep page size to less than 25kb.
• You should consider how your page will render when the images are not available
  

Rules to Follow:

• Use HTML Validator firefox extn to validate markups for every page.
• Use style based layout instead of tables to produce pages. Page layout will be split as header, content. while you should state the dimensions of your images (width="120" height="107") when designing for mobile devices, don't state the pixel units. Keep dimensions dynamic that will be supplied from, say a DeviceBean.
• Use accesskeys to links and limit links to less than 10. Navigation can be performed using keys instead of browsing.
• Use Wireless CSS
• Adopt a short URL
• Do not mask user input when entering a password.
• Read http://www.w3.org/TR/mobile-bp/
  

IBM WESB tips and aches - I

SOA support in IBM has improved a lot in their current release WESB7.x compared with earlier one, however it still is mired with issues that cause frustration. We were at v6.x struggling to figure out why's and where's of our friendly WID tool, a resource gobbler that would bring your development machine to its knees, when sudden developments beyond our control forced us to move to v7.x. The oddity being our Dev, staging and prod environments were to be rebuilt rather than running an upgrade raising eyebrows and suspicions.

Instead of building from Dev-> QA ->Staging->Prod in that order, our learned friends chose the reverse order so that development was not impacted. They were assuming repeatable and reliable behavior of topology images from a tool they had no prior experience. Alas, surprise in store, all went well in Prod but when executing the same instructions in Staging we noticed weird issues pointing to SpringFramework and J2C transactions. The surprise initially was not the failure issues but the springframework in IBM, our corporate folks always shunned from open source tools and were a big fan of IBM, EJB, et al and vehemently opposed introducing Spring. Now here it is backed by the big blue spewing errors that no one can make sense.

After couple of days of research the issue was nailed to datasources "jdbc/mediationMessageLog" and "jdbc/WPSDB", where both share connections and enlist in XA transaction. For some reason enlistment was failing even though XA was enabled at datasource and backend. Once we changed datasource property to use non-sharable and non transactional connection the problem went away. Ofcourse, as a side effect we were not able to use messagelog primitive which uses jdbc/mediationMessageLog for database logging. No big deal, we used trace log as a workaround to meet deadlines while waiting on IBM to figure out this anomaly.