accessibility (2) ADF (1) archiver (3) cmu (1) contributor (13) cookie (1) DAM (3) date (3) download (3) dynamic list (4) ephox (5) fatwire (1) fck (1) filters (1) folders (4) headers (2) IBR (3) ImageAlchemy (3) java (4) javascript (2) layout/template (4) link (6) locale (2) multilingual (1) rendition (3) replicator (4) rules (1) schema (1) search (11) sites (1) sitestudio (24) ssp/sspu (5) SSUrlFieldName (2) stellent (4) timezone (1) urm (1) weblogic (1) workflow (2)

Saturday, 21 November 2009

Cookie monster

Something I've never bothered to do until recently was make cookies. I prefer eating them! But it came up the other day at work when the website needed to read and write some cookies.

UCM provides simple idoc functions to read and write cookies, using getCookie(name) and setCookie(name,value,expires.) The problem we had was that the setCookie command would only create a simple, non-secure cookie that was tied to the current sub-domain. We needed more flavour in our cookies!

So, instead of using setCookie I sent my own HTTP headers to do the job with more precision with setHttpHeaders(type,details.) Using this little baby meant I could include whatever cookie ingredients we needed. Here's an example:

<$setHttpHeader("Set-Cookie","myCookieName=myValue; path=/myPath/here/;; secure=true; httponly=true; expires=0")$>

The cookie can be read back in as normal using the getCookie command... provided the cookie is available, of course. I may have eaten it already. Mmmmmm cookies...


  1. Thanks, I was looking at something similar a while back and I like this.

  2. Great cookie method..
    I`m definitely going to try this idea out in future :)