How we use Weceem CMS at NoticeLocal

We have an online notice boards startup called NoticeLocal that we’ve written with Grails.

In my experience over the years it became obvious that one of the major pain-points of using Java to deploy web apps is the hassle of updating a bit of content here or there, replacing an image – those kinds of things that should be simple but aren’t. Also a lot of the time this stuff is not subject to the same strict versioning processes that we are using for our code.

As you may know I am paid to work on the Weceem CMS plugin and application, that is also Grails based.

For NoticeLocal I decided that it would suit us well to use an instance of Weceem CMS running on one Tomcat, to supply the marketing/PR site for the service, as well as the multi-language content for UI elements in the main application.

It turned out this was really easy to do, even though Weceem currently has no API to speak of.

To do this we:

1. Have a vanilla WeceemApp WAR running in one Tomcat instance
2. Have our NoticeLocal application WAR running in another Tomcat instance
3. Wrote a trivial taglib in the NoticeLocal application to retrieve content nodes from the CMS instance using vanilla HTTP requests to URLs with a predefined prefix, and stores the text them in a local ehcache.

So, in Weceem we have a bunch of HTML content nodes that represent different elements of the main NoticeLocal app’s UI – we have several different Weceem templates that these different nodes use – e.g. one for side panels, one for full page content (but laid out inside the main NoticeLocal app sitemesh layout, and one for inline UI messages such as those shown on demand when the user performs some action.

So in our NoticeLocal application we use our taglib to render a “remote CMS message” in our pages using the not-so-well-known Grails/SiteMesh g:applyLayout tag that, just like Grails layouts, will parse out the body of the content that we’ve cached, and render it in situ.

Oh, and for bonus points we use a simple regex replace to give us GSP-like variable expansion when rendering the content from the local cache, so we can perform variable substitutions like ${userName} – so you can write that in a HTML node in Weceem, and by the time the NoticeLocal app renders it, it has your name in it.

At any point we can log into the CMS, update some UI message, and when the cache expires the users see the new updated stuff. No app redeploys.

Oh, and because its in a CMS we solve the hard problem – i18n translations of rich content with styling, images etc.

In a nutshell, it’s great!

OS X 10.6.5 update kills Safari cookies set on IP address

Last night I was developing my Grails app locally, which uses cookies. We always had some trouble cross-browser with setting cookies on localhost or 127.0.0.1, so we updated our code many months ago to use the local interface’s default IP address. This worked fine.

Until I installed OS X 10.6.5 update last night.

Safari under 10.6.5 does not handle cookies stored against IP addresses in the same way anymore, presumably as a side effect of a cookie-related security “fix”.

So to state it simply, if you have a web app that sets a cookie with the Domain attribute set to an IP address, this cookie will be stored but never sent to your server. What appears to happen is that cookies without a domain set e.g. JSESSIONID set by Tomcat, are successfully stored against the IP.

However as soon as you include domain= in your Set-Cookie header, this is stored with a “.” at the start of the domain in the browser cookie list (even if you didn’t put a “.” at the start of your domain) and it is then never sent to the server on subsequent requests.

The workaround is to update your code to not set the domain to the IP address of your host, but to the local host name. This is not normally a problem except when you are using a development tool locally.

By changing your code to use the bonjour name of the local host e.g. “marcmacbook.local” the problem goes away again – provided you browse to marcmacbook.local to test your site.

Something tells me this is a regression in OS X, not a deliberate change relating to the CFNetwork security bug.

Weceem Tip: How to render items from an RSS feed

Last night I was working on a Weceem site and had cause to render some links to articles from an external RSS feed. I have a Weceem Widget node already for this “news” panel, but the RSS comes from another site. Turns out even without direct support for rendering feeds (Weceem does support producing feeds out of the box), using Groovy’s magic methods on java.net.URL and the XmlSlurper you can easily do this.

Here’s a complete example:

This will render five news articles from the BBC news feed. It is incredibly naïve:

1. It doesn’t make any attempt at error handling
2. It will likely blow up if there are less than 5 items in the feed
3. It doesn’t do any caching – the feed is retrieved (by the server) every time the widget is rendered

However with a few tweaks this can be turned into something more robust. I imagine we will add a specific tag for this that hides the error handling and caching issues into a future build of Weceem.