_IECreate and "vista security"

[bengalih]

So I am repurposing/rewriting some code that was written by someone else in my organization.  Looking at the code, I can't help but feel that it isn't doing what the intent was.

Here is the code in question:

#include <IE.au3>

; Other Code

Func open_webpage()
   Local $ie = _IECreate("https://some.website.com", 1)

   If @error > 0 Then
      Local $i = 0

      Do
         Sleep(500)
         $i = $i + 1
         $ie = _IEAttach("Site Name")
      Until VarGetType($ie) == "Object" Or $i >= 10
   EndIf

   If VarGetType($ie) == "Object" Then
    ; do things
   EndIf
EndFunc

The original person that coded this remembers that they needed this to solve the issue mentioned here:

Quote

New security in Windows Vista causes a new browser window to be created when a browser is instructed to navigate to a URL in a different security zone.
This occurs as well with the initial creation and navigation initiated with _IECreate().
The new window is a new browser instance and the previous browser object variable no longer points to it.
There are several workarounds:
    1) add #RequireAdmin to your code (this is required even if the account is part of the Administrator's Group and will prompt for credentials if necessary),
    2) use _IEAttach() to connect to the new browser window
    3) add the target website to the Trusted Sites security zone in IE,
    4) turn off "Protected Mode" in IE,
    or 5) disable UAC. Care must be taken to understand the implications of disabling IE security features when accessing untrusted sites.

However not only have I found that this code doesn't seem necessary, I can't understand why it would have worked.

The initial _IECreate call wouldn't cause an error even if the "vista issue" mentioned above existed would it?
The _IECreate would still succeed would it not?  It is just that the "vista issue" would cause the handle to that object to change, but that doesn't mean that the _IECreate failed, right?

That being said - I don't see how the "If @error" branch would ever get run.
And, even if it were to run wouldn't there NOT be our "Site Name" to attach to anyway (since the initial _IECreate failure of that site is what got us into this branch in the first place)??

Now I suppose that this "vista issue" might actually close the object down during the _IECreateMethod causing an error back from the internal IE3.au3 code.

The problem is I can only surmise because I can't recreate this "vista issue" as described in the docs.

I would like a piece of code where I can reproduce the "vista issue" described...namely that you lose the handle to the object because a new window is created.
I just don't see that happening.

For what it is worth, all my testing has been on Windows 7 and Windows 2008R2 using IE 10 and 11.
I haven't added any websites to "trusted."
I have Protected Mode on in IE.
UAC is not disabled.
I don't use (and can't) #RequireAdmin

So based on the above I should be seeing it.  What am I missing.

Thanks.

Edited June 10, 2016 by bengalih

[bengalih]

Ok - so I rolled up a new Win 7 image and experimented with all the browsers and settings and I have finally figured out exactly how this issue can occur.

The _IECreate information is a little lacking in explaining exactly when this happens, it just says "a different security zone" which is technically true...but not always apparent.

In later versions of IE the security zone is hidden from normal display and things that you believe might be in an Intranet zone are not necessarily so.

So, to just make it clear it works like this:

If your initial URL is in an zone with Protected Mode = Off AND the Internet zone is Protected Mode = ON then the problem exhibits.

 

Basically, IE seems to always START in whatever the Internet zone is…which by default is Protected.
This is true even when no URL is sent yet.

As soon as you direct it to a site in an Unprotected zone, it creates the original handle to the object is lost.

So, when you will see this in practice is when the site you are navigating to is:

-          A trusted site (and trusted site zone is unprotected – the default)

-          An intranet site (and trusted site zone is unprotected – the default)

If you disable Protected Mode FROM THE INTERNET ZONE, and your other zones are also unprotected (again the default) you won't have this issue.

So the code shown above actually does work.
What happens behind the scenes is that the _IECreate process fails internally (on the _IELoadWait function) with an error 9 = $_IESTATUS_ClientDisconnected.
That is why the @error check was failing – it actually does create the object, but it fails on the _IELoadWait, so while the object was created (as I stated), it still logs an error here.

The code could probably be tighter though because if you turn _IELoadWait off (3rd option of _IECreate) it would then fail to issue the _IEAttach code.

Since the object is still there (we can’t test on that),  we can see if we can retrieve a property, so using something like:

_IEPropertyGet($oIE,"readystate")
If @error Then

May be a  better way to determine if we can access that page.

Hope this saves someone else the grief.

Edited June 11, 2016 by bengalih