![]() |
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
| Welcome to Windows Vista Forums. Our forum is dedicated to helping you find solutions with any problems, errors or issues you are experiencing with Windows Vista. The Vista forum also covers news and updates and has an extensive Windows Vista tutorial section that covers a wide range of tips and tricks. |
| |||||||
![]() |
| |
| | #1 (permalink) |
| | Security questions around browser hosted control interaction. 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. |
My System Specs![]() |
| | #2 (permalink) |
| | Re: Security questions around browser hosted control interaction. 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 |
My System Specs![]() |
| | #3 (permalink) |
| | Re: Security questions around browser hosted control interaction. On 13 May, 10:20, Marc Gravell <marc.grav...@xxxxxx> wrote: Quote: > 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. What security issues have you come accross doing this? Quote: > > 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). |
My System Specs![]() |
| | #4 (permalink) |
| | Re: Security questions around browser hosted control interaction. > By the latter do you mean the #2 option? Yes Quote: > What security issues have you come accross doing this? 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 |
My System Specs![]() |
| | #5 (permalink) |
| | Re: Security questions around browser hosted control interaction. On 13 May, 11:50, Marc Gravell <marc.grav...@xxxxxx> wrote: Quote: Quote: > > By the latter do you mean the #2 option? > Yes > Quote: > > 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 nicer way of doing this stuff? Ho hum. |
My System Specs![]() |
| | #6 (permalink) |
| | Re: Security questions around browser hosted control interaction. I think we just used VB6 and a couple of registry fragments in the installer... |
My System Specs![]() |
| | #7 (permalink) |
| | Re: Security questions around browser hosted control interaction. On 13 May, 13:15, Marc Gravell <marc.grav...@xxxxxx> wrote: Quote: > I think we just used VB6 and a couple of registry fragments in the > installer... ![]() Thanks. |
My System Specs![]() |
| | #8 (permalink) |
| | Re: Security questions around browser hosted control interaction. > 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 |
My System Specs![]() |
![]() |
| Thread Tools | |
| |
Similar Threads | ||||
| Thread | Forum | |||
| Setting properties on hosted toolstrip control at design time | .NET General | |||
| Can't read appSettings of IE hosted control when under SSL | .NET General | |||
| Problem running .NET user control hosted on Windows Vista / IE 7 | Vista security | |||