M
Max Motovilov
[This is a detailed technical post, cross-posted to multiple newsgroups]
[Sorry for a premature posting of a partial message]
Abstract: I cannot get past an ADO error: "Safety settings on this computer
prohibit accessing a data source on another domain".
My code hosts the WebBrowser control using the ATL's CAxDialogImpl<>. A
local Web page (accessed via "file:") is opened in a hosted instance of
WebBrowser. The script in this page attempts to connect to a local MS Access
database via ADO.
This page works fine in either a standalone browser or a hosted instance of
WebBrowser on systems other than Windows XP SP2. This page does NOT work in
either IE or WebBrowser under Windows XP SP2 unless:
(1) Local host is added to the Trusted sites AND
(2) The Web paged is opened using the host's UNC name (\\name\c$\....
instead of c:\....)
This is expected behavior for a standalone browser; I have however expected
to be able to override the security lockdown in a hosted instance of the
WebBrowser control. Here's what I tried:
(1) Properly implemented IInternetSecurityManager (verified that methods are
indeed called)
(2) Made ProcessUrlAction() always return S_OK which should have an effect
of setting all policies to ALLOW
(3) Made MapUrlToZone() map all local URLs to zone 2 (trusted sites)
All other methods are returning INET_E_DEFAULT_ACTION.
This rather brutal approach to knocking holes in security resulted in total
suppression of all security-related warnings and errors that are normally
controlled by security settings in the IE. So far so good. However, calling
Open() on the ADO Connection object in order to connect to the MS Access
database results in the following error: "Safety settings on this computer
prohibit accessing a data source on another domain". I have tried both the
Jet OLEDB provider and the MS Access ODBC driver.
It appears to me that in this case the prohibition of cross-domain access
comes from ADO itself rather than the browser. However, why does ADO think
there is a cross-domain access in the first place if both the HTML page and
the MS Access database are local? And why is this no longer a problem
whenever the site is added to the list of trusted AND local page is
referenced using the UNC path? I have tried investigating the behavior of
undocumented IInternetSecurityManager::GetSecurityId() method and discovered
the following:
- when page is opened by its file name (C:\....), the default security
manager's implementation of this method returns "file:[4-byte zone ID]"
where the zone ID is a 32-bit binary number!
- when page is opened via the UNC name, the default security manager returns
"file:host\c$[4-byte zone ID]".
However this returned value does not seem to be passed to ADO, as overriding
this method does not help -- everything is again determined by whether the
page was opened using the file name or the UNC name.
So my question to the experts is: IS THERE ANY WAY TO OPEN A LOCAL PAGE IN A
WEBBROWSER CONTROL AND ACCESS A LOCAL MS ACCESS DATABASE FROM IT WITHOUT ANY
ADMINISTRATIVE ACTIONS???
Sincerely,
....Max...
[Sorry for a premature posting of a partial message]
Abstract: I cannot get past an ADO error: "Safety settings on this computer
prohibit accessing a data source on another domain".
My code hosts the WebBrowser control using the ATL's CAxDialogImpl<>. A
local Web page (accessed via "file:") is opened in a hosted instance of
WebBrowser. The script in this page attempts to connect to a local MS Access
database via ADO.
This page works fine in either a standalone browser or a hosted instance of
WebBrowser on systems other than Windows XP SP2. This page does NOT work in
either IE or WebBrowser under Windows XP SP2 unless:
(1) Local host is added to the Trusted sites AND
(2) The Web paged is opened using the host's UNC name (\\name\c$\....
instead of c:\....)
This is expected behavior for a standalone browser; I have however expected
to be able to override the security lockdown in a hosted instance of the
WebBrowser control. Here's what I tried:
(1) Properly implemented IInternetSecurityManager (verified that methods are
indeed called)
(2) Made ProcessUrlAction() always return S_OK which should have an effect
of setting all policies to ALLOW
(3) Made MapUrlToZone() map all local URLs to zone 2 (trusted sites)
All other methods are returning INET_E_DEFAULT_ACTION.
This rather brutal approach to knocking holes in security resulted in total
suppression of all security-related warnings and errors that are normally
controlled by security settings in the IE. So far so good. However, calling
Open() on the ADO Connection object in order to connect to the MS Access
database results in the following error: "Safety settings on this computer
prohibit accessing a data source on another domain". I have tried both the
Jet OLEDB provider and the MS Access ODBC driver.
It appears to me that in this case the prohibition of cross-domain access
comes from ADO itself rather than the browser. However, why does ADO think
there is a cross-domain access in the first place if both the HTML page and
the MS Access database are local? And why is this no longer a problem
whenever the site is added to the list of trusted AND local page is
referenced using the UNC path? I have tried investigating the behavior of
undocumented IInternetSecurityManager::GetSecurityId() method and discovered
the following:
- when page is opened by its file name (C:\....), the default security
manager's implementation of this method returns "file:[4-byte zone ID]"
where the zone ID is a 32-bit binary number!
- when page is opened via the UNC name, the default security manager returns
"file:host\c$[4-byte zone ID]".
However this returned value does not seem to be passed to ADO, as overriding
this method does not help -- everything is again determined by whether the
page was opened using the file name or the UNC name.
So my question to the experts is: IS THERE ANY WAY TO OPEN A LOCAL PAGE IN A
WEBBROWSER CONTROL AND ACCESS A LOCAL MS ACCESS DATABASE FROM IT WITHOUT ANY
ADMINISTRATIVE ACTIONS???
Sincerely,
....Max...