Sunday, November 7, 2010

Setting Locale via URL – good or bad?

One of the lessons of web development is “use GET to retrieve, POST to modify”. Using GET to delete data can lead to being attacked by vicious black-hat hackers web crawlers. There are some solid explanations on StackOverflow, summarized as “Use POST to modify data. Use GET to receive data.”

However, what isn’t really covered, is changing state on the client side. Ektron sets the client locale via URL. Once the new locale is set, nothing is changed on the server – no bits written to disk, no memory changed. The client’s cookie, however, is updated with the new locale and the web server serves up different content now and the user’s experience completely changes, especially if the new locale is not supported.

For example, Ektron’s new site in mono-lingual, restricted to en-US (id=1033). However, if you browse to http://www.ektron.com/?LangType=3081 (en-AU = 3081), you will see an error, as the Ektron site does not have any Australian content.

This is sort of expected – I’ve asked for an Australian homepage and there is none. (Ideally, your en-AU locale would degrade to a generic en locale, then optionally degrade to a specified default language. Ektron supports neither of these). Where the problem arises is in the relationship between locale and URL/aliasing in Ektron. Now, with your locale set to en-AU, most of the site will be broken. One of the goals (and strengths) of URLs is universality, that links are perpectual. If I tattoo my forehead with www.example.com/EatAtJoes , it is entirely within my power as to whether that URL lives or dies (notwithstanding domain name hosting fees, DNS poisioning)

So I guess I don’t like the idea of losing control over how my site visitors experience my site. What if one of Ektron’s competitors sent out a newsletter with an obfuscated link like
www.ektron.com/?AdvancesInIntranets=true&LangType=3081&ImportantWhitepaper=AmazingInsights .
“Oh 404, no worries, I’ll find the article from the homepage. Wait, the homepage doesn’t work either?”

 

What are your thoughts on setting locale via GET URL? Personally, I think Ektron should-

  • Require confirmation to change locale
  • Locale change should be via POST at very least
  • Provide better aliasing support for multilingual sites, such as-
    • allowing for a locale specifier in the URL, e.g. en.example.com or www.example.com/en
    • Show foreign language content for valid URLs in a different language, e.g. if your locale is en-US, www.example.com/Bonjour.aspx should show same or translated content as www.example.com/Hello.aspx .
  • Provide better multilingual support in general, such as-
    • allow proper language degradation
    • allow generic language content

 

What you can do to stop this-

  • Especially if you’re using a single language, set the locale back to the default on every request.
  • Customise the 404 error page to change the locale back to the default (if it isn’t already) and resubmit the request (watch out for cyclic requests).

 

Antidote: If you’ve clicked on any of the links above and wish to get your Ektron site experience back to normal, just browse to http://www.ektron.com/?LangType=1033

 

Repro steps-

  1. Browse to http://www.ektron.com/News-And-Events/ and confirm that it works.
  2. Browse to http://www.ektron.com/?LangType=3081 , which gives a 404, but sets your locale to en-AU
  3. Once again, browse to http://www.ektron.com/News-And-Events/ which now gives you a 404
  4. The majority of the Ektron site is now broken, until either clear your site cookie or browse to http://www.ektron.com/?LangType=1033

No comments:

Post a Comment