0 Replies Latest reply on Jan 27, 2004 10:26 PM by 807574

    IPS cookie truncated if domain name starts with 't'.

      I'm using iPlanet version 3.0, service pack 3.0, hot patch 3.0. I have a scraper channel that's configured to scrape a JSP that also resides on the portal server. The portal is set up to serve numerous domains, and we have 'remember me' functionality enabled so people can cookie in.

      Everything works fine, provided the portal domain name does not begin with the letter 't'. If someone cookies in from a domain that begins with the letter 't', they successfully bypass login, and the portal home page is properly displayed with all the appropriate content. But the (secondary) request from the scraper channel to scrape the on-board JSP fails authentication, resulting in the sign in error page being displayed in the scraper channel (effectively as scraped content ... isn't that ironic).

      By introducing degbug statements to dump the cookies attached to each inbound request, I've determined that, when the cookie is read for the secondary request (to the on-board JSP), the IPS cookie is being truncated. As a consequence, the authentication software can't locate a valid (active) session, and authentication fails. I've confirmed that this only happens for users attempting to cookie in to domains that begin with the letter 't'.

      More detail: the IPS cookie (which includes the domain name) is obfuscated using a simple character substitution algorithm ... an obfuscated cookie looks something like this:


      The character substitution algorithm replaces 't' with 'g' ... in the example above, 'greevy.pbz' is the obfuscated domain. The cookie for any domain that begins with the letter 't' therefore contains the sub-string '%25/g' (confirmed through examination of numerous cookies). The cookie is being truncated at this point ... the cookie string above, for example, is truncated as follows:


      A cookie containing this string works fine for the initial request to the portal server. But the secondary request to the JSP (from the scraper channel) fails to authenticate because the cookie attached to the scraper request is truncated immediately following the %25. ???

      I have not been able to determine whether the cookie is being truncated when it is written (i.e. appended to the request by the scraper channel) or read (when the request to the JSP is being processed. Both the write and read operations take place deep in the bowels of the iPlanet Portal Server code, the former in the URL scraper code, the latter in the authentication, so debugging is a bit of a challenge.

      I tried upgrading to Service Pack 5.0, but it didn't fix the problem. I've seen a lot of bug tickets pertaining to cookies, but haven't been able to locate a bug report that identifies this particular problem.

      Anyone have a clue?