Archive for July, 2008
window.opener.location – access denied

Let’s have a look at my programming duties today. The plot goes like this: There is a Web Dynpro within Enterprise Portal (I don’t know proper English fairy tale style, but this sentence feels similar to ‘In a dark, filthy cave lived a horryfying twelve-headed fire-spitting dragon’). This web dynpro opens external window with a JSPDynPage portal component.

Amongst other functionality there is a button, which switches application on the opening window. Since it’s a webdynpro in a portal, we need to use window.opener.top.location, as webdynpro is within a frame (or iframe). First time in works. Second time, Internet Explorer yields Access Denied.

You think: Common cross-site scripting issue. But we only do window.location.href="/irj/portal?NavigationTarget=ROLES://...", so no server is changed. The new component sits at same server as well. And it worked for the first time! Window opener still exists, but any access to it returns Access Denied. And the cause is, that we didn’t change window.opener, we changed window.opener.top, and thus window.opener is no longer valid. Once you realize that, the solution is pretty straightforward:

this.windowopenertop = window.opener.top;
this.windowopenertop.location.href=role1url;

and then later

this.windowopernetop.location.href=role2url;

…and the dragon lived happy ever after (though the user can choose to see another dragon at same location).

OpenSwan and Cisco PIX: ISAKMP:not zero on reserved payload 5

Now this was another long night: I was trying to create IPSec tunnel between Cisco PIX and Ubuntu-based router with OpenSwan. At first, I was unable to estabilish ISAKMP communication as PIX always rejected it with SA not acceptable. That was solved with adding

ike=aes-sha1-modp1024

into ipsec.conf configuration file. And once I got though this I came to thegreat showstopper, that is mentioned in the title. Cisco and various forums state, that my pre-shared key was wrong (but it wasn’t), that I should do clear crypto sa on the PIX (but it didn’t help), or that my access list was wrong (but they seemed right). After giving up and getting some sleep instead I decided to change the encryption (I used AES with SHA1). I added new policy for 3DES with MD5 and suddenly the message was gone!

But there was a new one, saying Proxy Identities Not Supported, and finally I found where I should have had 192.168.8.0 instead of 192.168.1.0 – in the ipsec.conf.

And from that time on, the tunnel works perfectly.

One more note:

After you’re happy that your tunnel has been estabilished and you’re re looking forward to trying it out, you may get disappointed that no pings to remote internal network will work, and that ssh will return No route to host.The secret ingredient is to use internal network interface as source, so use

ping remoteinternalhost -I routerinternalinterfaceip
ssh -b routerinternalinterfaceip remoteinternalhost