JavaScript permissions error with Websphere Portal and Domino and JavaScript

HCL Domino Domino Forum
1

A customer of ours is having a permissions error raised when using FCKeditor, a popular if oddly named JavaScript web editor that replaces the textarea with an editor. I have reproduced their scenario as well as the possible solutions and thoughts suggested by some of the gurus I know, but I was wondering if anybody here had a more specific suggestion.

The problem

According to the customer:

<<We are trying to rollout an application on our WebSphere Portal server using the Domino Applicaion Portlet to access the test database (we are experiencing this same problem on the database that we have designed). Whenever it goes to bring up the FCKEditor we see a Java error message stating permission has been denied??? The portal server and the domino server are on different servers. >>

The error is displayed as the following (with redaction for the company name):

I asked around, and the answers from the gurus I consulted were (reworded slightly):

<<It looks exactly like the JavaScript error that occurs when JavaScript attempts to load something from server B onto a page that was loaded from server A.

This is a fundamental security feature of JavaScript.

Deep in the recesses of my mind, I think I recall that there’s a way that if both servers are in the same domain there’s a way to get this to work, but the page has to explicitly do something to associate itself with the domain instead of with the specific server, and I don’t recall the details.>>

and

<<I think you (they?) need to look at the usual access issues:

Check the ACL on the NSF and make sure that either the specific user has rights (if logged in) or that Anonymous has rights.

Check that the web user has access to the WebSphere Portal as well as the Domino server

Check whether the portlet use DIIOP. If so, additional security settings might need to be tweaked on the server

Is Domino LDAP involved?

Is the Portal server listed as a trusted server from domino’s perspective? It is possible that is necessary

Does the browser have rights to run JavaScript at all? From that site?

I usually start by trying to access the NSF via IE, see what crops up that way >>

Does anybody else have anything to add? I don’t know how to either reproduce the problem or correct it, but I think the clue is in the first of these two answers. I just don’t know how to interpret the clue.

2

Subject: JavaScript permissions error with Websphere Portal and Domino and JavaScript

Ben, is it possible that the domain in the link to the main page is different from the domain in the link to the FCKEDitor source? Portal is designed to handle content from different servers, but if - within the Domino or Portal page - there were references to different http hosts, that could screw the pooch. For example, sometimes people use just the hostname (WINS name) as opposed to the FQDN in one of the two, or they even have multiple DNS entries for the same box and use them interchangeable. If the page is coming from the Domino server, and the FCKEditor source files are also on that server, what about a relative url? Portal will rewrite it correctly.

/brainstorming

3

Subject: JavaScript permissions error with Websphere Portal and Domino and JavaScript

This isn’t something that can easily be solved at the server. That is, the security error is being thrown by JavaScript itself because of the source URLs, not because the user has insufficient access to something remote. That can be solved in some browsers some of the time by setting the document.domain property of the pages to a common “domain.tld” (leaving the server part of the URL out of the deal), but it’s not something you can count on working universally. It’s cheap though, so it might be worth a try.

The problem usually pops up with frames or windows that are tied together by the opener property – you can source the script happily in either window from wherever it happens to live, but if the different frames or windows have their content sourced from different servers, the script can’t address the “other” window.

This is a particularly nasty little problem. In the AJAX world, the solotution so far has been to dynamically create tags (whose src property can point to any URL, not just the current server) and get the data formatted as JSON (“JavaScript Object Notation”, pronounced “Jason”). (See JSON for more on JSON.)

Poisonally, I wouldn’t want to try to dynamically format an arbitrary Domino page as JSON using the current Designer toolset. That might be something an enterprising ISV with an in-depth knowledge of Rich Text structures could take a look at, though, if the market seems big enough.