Ramble On

We use the Domino redirect [url] to direct to users to different web pages.

One of our systems handles the Athens devolved authentication used many by UK Universities to provide access to journal subscriptions to students off-campus.

Athens basically works by a set of redirects and can be used by users either pre journal search or post. If they choose not to pre-authenticate. When a user accesses a journal they’re directed to Athen’s login page. They can then identify their host institution. At this point a series of redirects takes place.

Basically Athens sends a long URL to a Java agent on Domino. This url has a long MD5 session hash and information to pass back to Athens so that it can then direct the user to the correct page on publisher’s website.

We process the hash, validate it and then using a private key create a new hash that includes information about the user such as a unique id number and any permission sets that apply to them.

Today, it stopped working.

A publisher recently restructured their website and this created much longer url hashes. (2200 characters long)

Every time the agent was called from the Athens, Domino generated a http error – ‘Buffer Overflow’.

After some debugging. We identified that the error was generated by the in-built Domino redirect. It appears that there is a 2048 character limit on Java redirects.

The solution is simple to implement. You just need to return url string as part of the header via the http ‘Location’. But it’s odd that Domino will accept 4kb’s long URLs but less for redirects.

Technote: ‘Buffer Overflow Exception’ error using URL redirection with a string longer than 2048

Domino Buffer Overflow, Domino, HTTP

We use a Google Search Appliance to index our Domino websites. We use Google’s OneBox module to execute FT searches to return results from a database we don’t want Google to index (basically 80,000 journal records we don’t want to be counted against our license total).

Yesterday we upgraded our Search Appliance to the latest version of Google’s software (6.2.0.G14). About an hour after switching it on, one of our Domino servers was hit by a sustained denial of service. The Agent called by the Google OneBox module had saturated all our HTTP threads. The Google box was making continuous requests to the search agent at a rate of nearly 200,000 per hour. The odd thing was, Google’s OneBox module passes across the end-user’s IP address as part of the search query and all requests were coming from 216.239.43.1 – a Google IP address.

It appears that there’s a known issue with the OneBox module that can cause this. (Bug report #2368523). Google immediately applied the patch, and after an hour the requests had stopped.

If you intend to upgrade to 6.2. I suggest you remove all OneBox modules from your front-ends before upgrading

So related to this problem, I find it easy to create a DOS on a Domino server. Calling any agent that takes a second to return results continuously creates a DOS (it might simply be a case of holding F5). Our server’s are set up as per Lotus’s recommendations. But does anyone have any tips for optimising the Domino http stack (Solaris) to avoid DOS?

Domino Google Search Appliance