By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,853 Members | 1,541 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,853 IT Pros & Developers. It's quick & easy.

Security questions around browser hosted control interaction.

P: n/a
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.
Jun 27 '08 #1
Share this Question
Share on Google+
7 Replies


P: n/a
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
Jun 27 '08 #2

P: n/a
On 13 May, 10:20, Marc Gravell <marc.grav...@gmail.comwrote:
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.

Jun 27 '08 #3

P: n/a
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/libr...77(VS.85).aspx

Marc
Jun 27 '08 #4

P: n/a
On 13 May, 11:50, Marc Gravell <marc.grav...@gmail.comwrote:
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/libr...77(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.
Jun 27 '08 #5

P: n/a
I think we just used VB6 and a couple of registry fragments in the
installer...
Jun 27 '08 #6

P: n/a
On 13 May, 13:15, Marc Gravell <marc.grav...@gmail.comwrote:
I think we just used VB6 and a couple of registry fragments in the
installer...
DAng, going to have to scrabble around for Old School Studio.... :)

Thanks.
Jun 27 '08 #7

P: n/a
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
Jun 27 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.