Security questions around browser hosted control interaction.

  • Thread starter Thread starter mrmoosehead
  • Start date Start date
M

mrmoosehead

OK. I am trying to embed a control in a webpage that will allow local
access to the TAPI system to make and query phone calls. In a
nutshell.

Anyway, I am aware that there are many security issues around this and
have some mitigation of them in that the site is a 'private internet
site' - IPs locked to the users offices.

I have tried many options in terms of zones, but all throw
(unsurprisingly) security issues.

I have tried running the code from a local .hta but this still seems
to trhow the security permissions problem - Is this becuase I have
navigated away from the local html page to a remote one within
the .hta application?

Anyway, can anyone suggest a way of getting either

1) a remote hosted web page to communicate with a local machine hosted
app
or
2) an activeX or .NET UserControl object within an internet zone
application to be able to talk to the TAPI source.

or should I just give up and write a local server app to field AJAX
calls from the hosted app?
Actually, coming to think of it, that may be a much neater solution.

TIA,
M.
 
I'd be inclined to go with the latter (a separate app) - in particular,
I would probably use a COM server (exe) to host the actual TAPI
interface code, and a COM library (dll) to host the control (OCX or just
COM via CreateInstance; this acts purely as a shim/facade, forwarding
methods to the COM server) - that way, the COM server can stay alive as
you navigate between pages, minimising the load overhead per page;
likewise, the COM work that jscript does is minimal.

We've used the above to provide access to both telecomms and scanning
systems within web pages for a known site (i.e. not the public website).

Another option is to host the entire app in a WebBrowser (in a .NET exe)
rather than IE - and use ObjectForScripting to provide access.

Marc
 
I'd be inclined to go with the latter (a separate app) - in particular,
I would probably use a COM server (exe) to host the actual TAPI
interface code, and a COM library (dll) to host the control (OCX or just
COM via CreateInstance; this acts purely as a shim/facade, forwarding
methods to the COM server) - that way, the COM server can stay alive as
you navigate between pages, minimising the load overhead per page;
likewise, the COM work that jscript does is minimal.

By the latter do you mean the #2 option?

What security issues have you come accross doing this?
We've used the above to provide access to both telecomms and scanning
systems within web pages for a known site (i.e. not the public website).

Cool.
 
By the latter do you mean the #2 option?
Yes
What security issues have you come accross doing this?
Getting the control to load is always fun - and indeed I try not to go
near html <---> COM unless I can help it [needs must, though...].
As I recall, we had a signed cab installer (might have been msi - I
can't say for sure) for the COM that set the safe for scripting /
initialisation flags. Something like:
http://msdn.microsoft.com/en-us/library/aa751977(VS.85).aspx

Marc
 
By the latter do you mean the #2 option?
Yes

What security issues have you come accross doing this?

Getting the control to load is always fun - and indeed I try not to go
near html <---> COM unless I can help it [needs must, though...].
As I recall, we had a signed cab installer (might have been msi - I
can't say for sure) for the COM that set the safe for scripting /
initialisation flags. Something like:http://msdn.microsoft.com/en-us/library/aa751977(VS.85).aspx

Marc

Erk! Are we talking nasty nasty mfc activex level here, or is there a
nicer way of doing this stuff?

Ho hum.
 
DAng, going to have to scrabble around for Old School Studio.... :)

Yup; a fair ache going back to VB6, but AFAIK .NET can't write COM
servers...

You *might* be able to use .NET to create a serviced component, but I
have very little experience there, so can't advise.

Marc
 
Back
Top