Javascript too secure

VK · Jul 20 '05, 11:39 AM

Re: Javascript too secure

And it's good that it's so secure! ;-)

I'm not clear why do you have different web-servers within the Intranet.
Are you a web-provider?
Not my business really, I'm just wondering if you are troubling with
different sub-domains, not domains (like www.company.com,
secure.company. com, www2.company.co m and so). In this case you can fix
the situation by setting document.domain ="company.co m" on each involved
page.

Also you can:
on each involved browser go to Tools>Internet Options>Securit y, add your
sites to the "Trusted sites" list and apply no security protection on
them.

Work with System.Security .Permissions:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/h

tml/frlrfsystemsecu ritypermissions securityattribu teclasstopic.as p

**Rainer Rosenberger** · Jul 20 '05, 11:39 AM

Re: Javascript too secure

Hello,

thanks for your suggestions. We have two different subdomains
server_x.mydom. de (x=1,2) because there are existing applications sitting on
these servers (with different operating systems NT respectively AIX) and we
want to integrate the existing web application of server_2 into a new
application on server_1. So it seems to be worth to test the
document.domain ="mydom.de". The problem might be (to be tested) that the
URL used by users simply is http://server_x and not http://server_x.mydom.de

I already tried to set the trusted domains in IE, but this did not work
I'll keep you informed.

Regards, Rainer Rosenberger

"VK" <schools_ring@y ahoo.com> schrieb im Newsbeitrag
news:3faae1c1$0 $15697$9b622d9e @news.freenet.d e...[color=blue]
> And it's good that it's so secure! ;-)
>
> I'm not clear why do you have different web-servers within the Intranet.
> Are you a web-provider?
> Not my business really, I'm just wondering if you are troubling with
> different sub-domains, not domains (like www.company.com,
> secure.company. com, www2.company.co m and so). In this case you can fix
> the situation by setting document.domain ="company.co m" on each involved
> page.
>
> Also you can:
> on each involved browser go to Tools>Internet Options>Securit y, add your
> sites to the "Trusted sites" list and apply no security protection on
> them.
>
> Work with System.Security .Permissions:
> http://msdn.microsoft.com/library/de.../en-us/cpref/h
> tml/frlrfsystemsecu ritypermissions securityattribu teclasstopic.as p[/color]

**Rainer Rosenberger** · Jul 20 '05, 11:40 AM

Re: Javascript too secure

Hi VK, in the meanwhile I tested your suggestion and copied one file to
subdomain s1.mydom.de and the other to s2.mydom.de and still got the access
violation error. I also tried to access the the newly opened window through
an ActiveX control (hoping it acts like a trusted proxy), without success.

Regards, Rainer Rosenberger

"VK" <schools_ring@y ahoo.com> schrieb im Newsbeitrag
news:3faae1c1$0 $15697$9b622d9e @news.freenet.d e...[color=blue]
> And it's good that it's so secure! ;-)
>
> I'm not clear why do you have different web-servers within the Intranet.
> Are you a web-provider?
> Not my business really, I'm just wondering if you are troubling with
> different sub-domains, not domains (like www.company.com,
> secure.company. com, www2.company.co m and so). In this case you can fix
> the situation by setting document.domain ="company.co m" on each involved
> page.
>
> Also you can:
> on each involved browser go to Tools>Internet Options>Securit y, add your
> sites to the "Trusted sites" list and apply no security protection on
> them.
>
> Work with System.Security .Permissions:
> http://msdn.microsoft.com/library/de.../en-us/cpref/h
> tml/frlrfsystemsecu ritypermissions securityattribu teclasstopic.as p
>
>
>[/color]

**John English** · Jul 20 '05, 11:45 AM

Re: Javascript too secure

VK wrote:[color=blue]
> And it's good that it's so secure! ;-)[/color]

Not from my point of view... :-)
[color=blue]
> In this case you can fix
> the situation by setting document.domain ="company.co m" on each involved
> page.[/color]

I have a similar problem; I have a frameset containing two frames:
a left frame from "charon.it.bton .ac.uk" and a right frame from
"hermes.it.bton .ac.uk". The left frame contains some JS which
communicates with an applet. The right frame contains several forms,
each with a button that has "onclick=javasc ript:parent.lef t.process()"
to process the form data. (For various reasons I can't put the right
frame on charon.it.bton. ac.uk.) I used to get moans about the two
frames coming from different places, so I put a line at the start
of the right frame saying "document.domai n=charon.it.bto n.ac.uk".

What I now get is "Error: uncaught exception: permission denied to
get property Window.process" .

Can anyone tell me how to get around this one? Please???

TIA,

-----------------------------------------------------------------
John English | mailto:je@brigh ton.ac.uk
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

**Rainer Rosenberger** · Jul 20 '05, 11:45 AM

Re: Javascript too secure

Hello John,

a frame is the same as an other window, so the behaviour is as expected. I
checked also various other newsgroups and tried discussions, without success
yet. I also tried to put an ActiveX control in between the two windows as a
kind of proxy server. There I found that the related VB Window Object
pointing to the browser window does not contain any function collection (I
only have access to textboxes and other objects defined in the explorer
object model). My impression is that even calling functions in an other
window after oWin=window.ope n() is working, but not documented or did you
find an official MS document?

Regards, Rainer Rosenberger

"John English" <je@brighton.ac .uk> schrieb im Newsbeitrag
news:booe5t$ial $1@saturn.bton. ac.uk...[color=blue]
> VK wrote:[color=green]
> > And it's good that it's so secure! ;-)[/color]
>
> Not from my point of view... :-)
>[color=green]
> > In this case you can fix
> > the situation by setting document.domain ="company.co m" on each involved
> > page.[/color]
>
> I have a similar problem; I have a frameset containing two frames:
> a left frame from "charon.it.bton .ac.uk" and a right frame from
> "hermes.it.bton .ac.uk". The left frame contains some JS which
> communicates with an applet. The right frame contains several forms,
> each with a button that has "onclick=javasc ript:parent.lef t.process()"
> to process the form data. (For various reasons I can't put the right
> frame on charon.it.bton. ac.uk.) I used to get moans about the two
> frames coming from different places, so I put a line at the start
> of the right frame saying "document.domai n=charon.it.bto n.ac.uk".
>
> What I now get is "Error: uncaught exception: permission denied to
> get property Window.process" .
>
> Can anyone tell me how to get around this one? Please???
>
> TIA,
>
> -----------------------------------------------------------------
> John English | mailto:je@brigh ton.ac.uk
> Senior Lecturer | http://www.it.bton.ac.uk/staff/je
> Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS **
> University of Brighton | -- see http://burks.bton.ac.uk
> -----------------------------------------------------------------
>[/color]

**Graham J** · Jul 20 '05, 11:45 AM

Re: Javascript too secure

> I have a similar problem; I have a frameset containing two frames:[color=blue]
> a left frame from "charon.it.bton .ac.uk" and a right frame from
> "hermes.it.bton .ac.uk". The left frame contains some JS which
> communicates with an applet. The right frame contains several forms,
> each with a button that has[/color]
"onclick=javasc ript:parent.lef t.process()"[color=blue]
> to process the form data. (For various reasons I can't put the right
> frame on charon.it.bton. ac.uk.) I used to get moans about the two
> frames coming from different places, so I put a line at the start
> of the right frame saying "document.domai n=charon.it.bto n.ac.uk".[/color]

My instant reaction on seeing that, never having used document.domain ,
was that it couldn't possibly be allowed as it would break the
security mechanism. A quick check and as I suspected all you can do
is generalise the existing domain name. So for hermes.it.bton. ac.uk
you can set document.domain to "it.bton.ac.uk" , "bton.ac.uk ", "ac.uk"
or "uk". It sounds like setting them both to "it.bton.ac .uk" is what
you really need to do.
I have also seen a suggestion that you should have it in the frameset
document too.

**John English** · Jul 20 '05, 11:46 AM

Re: Javascript too secure

Graham J wrote:[color=blue]
> My instant reaction on seeing that, never having used document.domain ,
> was that it couldn't possibly be allowed as it would break the
> security mechanism. A quick check and as I suspected all you can do
> is generalise the existing domain name. So for hermes.it.bton. ac.uk
> you can set document.domain to "it.bton.ac.uk" , "bton.ac.uk ", "ac.uk"
> or "uk". It sounds like setting them both to "it.bton.ac .uk" is what
> you really need to do.[/color]

You're quite right; I was having funnies due to caching when I tried
that.
[color=blue]
> I have also seen a suggestion that you should have it in the frameset
> document too.[/color]

It works quite happily as far as the JavaScript is concerned, but now
the JS can't talk to the Java applet because they now purport to come
from different places. I can't find anything about changing the domain
for an applet, so I'm just as stuck as before...

-----------------------------------------------------------------
John English | mailto:je@brigh ton.ac.uk
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

**Rainer Rosenberger** · Jul 20 '05, 11:46 AM

Re: Javascript too secure

Helle John,

I was able to solve my problem because I run in two different windows (maybe
with some modifications the same can be done for two frames). First of all a
everything in a browser window opened from a local application (HTA, VB or
DLL) can be acessed. A local application has full rights, regardless from
where the page has been requested. The tricky thing is to find the scripts
set oIE = CreateObject("I nternetExplorer ")
oIE.visible = True
oIE.Navigate sURL ' Now wait until oIE.busy = false
call oIE.document.pa rentWindow.MyJa vaScriptFunctio n(par1, ...)

I will write a DLL which mainly executes the code above but provides the
function calls as public classes. So I will have class methods like
Navigate(sURL) or CallFunction( para1,....). In Browserwindow1 I will not
control Browserwindow2 directly but open my class an let the classdo the
job. The class should be trusted (registry entry), otherwise there might be
a query whether the ActiveX should be activated) .

Regards, Rainer Rosenberger

**John English** · Jul 20 '05, 11:48 AM

Re: Javascript too secure

John English wrote:
[color=blue]
> I have a similar problem; I have a frameset containing two frames:
> a left frame from "charon.it.bton .ac.uk" and a right frame from
> "hermes.it.bton .ac.uk". The left frame contains some JS which
> communicates with an applet. The right frame contains several forms,
> each with a button that has "onclick=javasc ript:parent.lef t.process()"
> to process the form data. (For various reasons I can't put the right
> frame on charon.it.bton. ac.uk.) I used to get moans about the two
> frames coming from different places, so I put a line at the start
> of the right frame saying "document.domai n=charon.it.bto n.ac.uk".
>
> What I now get is "Error: uncaught exception: permission denied to
> get property Window.process" .[/color]

In fact (following a few cache flushes so that I was loading the correct
version of all the pages involved) I get errors if I try to set the
domain to charon.it.bton. ac.uk -- setting it to it.bton.ac.uk is fine,
but I then get this:
sun.plugin.live connect.OriginN otAllowedExcept ion: JavaScript is not
from the same origin as the Java code, caller=http://it.bton.ac.uk,
callee=http://charon.it.bton. ac.uk
So, I can't claim that all the pages are from charon.it.bton. ac.uk,
but I can claim that the JS is from it.bton.ac.uk -- however the
applet is still from charon.it.bton. ac.uk.

Sigh. This used to work just fine with Netscape 4.7... :-(
[color=blue]
> Can anyone tell me how to get around this one? Please???
>
> TIA,[/color]

-----------------------------------------------------------------
John English | mailto:je@brigh ton.ac.uk
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

**Thomas 'PointedEars' Lahn** · Jul 20 '05, 11:50 AM

Re: Javascript too secure

VK wrote:
[color=blue]
> And it's good that it's so secure! ;-)[/color]

But it is an imperfect security.
[color=blue]
> I'm not clear why do you have different web-servers within the Intranet.[/color]

Not different servers are the problem, but different domains are.

PointedEars

**Thomas 'PointedEars' Lahn** · Jul 20 '05, 11:50 AM

Re: Javascript too secure

Rainer Rosenberger wrote:
[color=blue]
> thanks for your suggestions. We have two different subdomains
> server_x.mydom. de (x=1,2) because there are existing applications sitting on
> these servers (with different operating systems NT respectively AIX) and we
> want to integrate the existing web application of server_2 into a new
> application on server_1. So it seems to be worth to test the
> document.domain ="mydom.de". The problem might be (to be tested) that the
> URL used by users simply is http://server_x and not http://server_x.mydom.de[/color]

Use server-side redirection to work around that:

,--------------------------- .htaccess ----------------------------
| RedirectMatch permanent ^(.+:\/\/server_x)(/[^.].*) $1.mydom.de$2

PointedEars

**John English** · Jul 20 '05, 11:51 AM

Re: Javascript too secure

Rainer Rosenberger wrote:
[color=blue]
> Helle John,
>
> I was able to solve my problem because I run in two different windows (maybe
> with some modifications the same can be done for two frames). First of all a
> everything in a browser window opened from a local application (HTA, VB or
> DLL) can be acessed. A local application has full rights, regardless from
> where the page has been requested. The tricky thing is to find the scripts
> set oIE = CreateObject("I nternetExplorer ")
> oIE.visible = True
> oIE.Navigate sURL ' Now wait until oIE.busy = false
> call oIE.document.pa rentWindow.MyJa vaScriptFunctio n(par1, ...)[/color]

Alas, this won't work for me -- in my case it needs to work with any
browser, not necessarily running under Windows, and most certainly not
a special-purpose app. We have users on PCs, Macs and Suns running IE,
Netscape and Mozilla; most of the PC users run Windows, but quite a few
run Linux.

I've found a workaround -- an application running on my server that uses
Java class loaders & reflection to do what the applet would have done to
communicate with the other server, and an applet loaded from my server.
The JS can talk to the applet, and the applet uses the application as a
proxy to talk to the other server. This has involved me discovering much
more about the black magic of the reflection API than I ever wanted to
know, and has cost me a couple of days of frantic experimentation due to
the lack of documentation for various aspects of the process, but it
works at last.

However, I'd still be interested in hearing of any general solution to
the problem that doesn't involve writing local server apps to proxy for
remote services...

Cheers,

-----------------------------------------------------------------
John English | mailto:je@brigh ton.ac.uk
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Javascript too secure

Javascript too secure

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment