Vista - Setting cookies on InternetExplorer.Application

I have a VBScript application I've written which uses IE for
display purposes. I figure, why not retain settings for my
app using IE's already built in handler, namely cookie
management? Unfortunately, I'm getting the big goose egg,
nada, nothing, zip.

Here's what I tried. It's easy, using VBScript in a web
page, to set a cookie. Here's an example:

<script type='text/vbscript'>
'Run this script in a .htm file
cookieScript = _
"var exp = new Date();" & _
"var Mins3 = exp.getTime() + (1000 * 60 * 3);" & _
"exp.setTime(Mins3);" & _
"alert (exp.toGMTString());" & _
"document.cookie = 'foo=bar; expires=' + exp.toGMTString();"
window.execScript cookieScript
MsgBox document.cookie
</script>

No muss, no fuss, the above set a cookie with a name of foo
to have a value of bar. Because the expiration is set (to 3
minutes after assignment), you can use IE's File / Import
and Export / Export Cookies to export the cookies to a file
and view it. However, when I convert the above in the hopes
of using it with the IE that my VBScript app brings up, the
cookie appears to never have been set.

'Run this script in a .vbs file
set ie = CreateObject("InternetExplorer.Application")
ie.Navigate2 "about:blank"
ie.visible = True
cookieScript = _
"var exp = new Date();" & _
"var Mins3 = exp.getTime() + (1000 * 60 * 3);" & _
"exp.setTime(Mins3);" & _
"var newCookie=" & _
"'foo=bar; " & _
"expires=' + exp.toGMTString();" & _
"alert ('setting: ' + newCookie);" & _
"document.cookie = newCookie"
ie.document.parentWindow.execScript cookieScript
MsgBox ie.document.cookie
'ie.Quit()

Of course as it sits, this code would be insufficient
because there is nothing to associate the cookie
with the script being run (ie. WScript.ScriptFullName).
Nevertheless, is there a way to get my basic idea to
work?

Thanks,
Csaba Gabor from Vienna

Um, oh yea, in the hopes that IE just needed a concrete
domain, I tried navigating it to a fake domain

ie.Navigate2 "about:blank"
ie.Navigate2 "http://sureNotToExist.com"
while (ie.ReadyState<4): WScript.Sleep(1): Wend

and then set the cookie. Not surprisingly,
this did not work either. It also didn't work
when I tried to execute the cookie script by
means of a window.setTimeout.


On Mar 4, 1:58 pm, Csaba Gabor <dans...@xxxxxx> wrote:....

As cookies can only be read from the same domain I can only think of two
possibilities if you must use cookies:
* Use a generic local page but pass in parameters via a querystring so
govern the mode:
myCookieManager.htm?mode=write
myCookieManager.htm?mode=read
Take a look at the document.domain property, that may also help.

* Use the FileSystemObject to read the cookie. The problem is knowing where
to look for it as the parent folder name is fairly random.

In general it might be easier to just use your own "home baked" version of
cookies


--

Joe Fawcett (MVP - XML)
http://joe.fawcett.name

"Csaba Gabor" <danswer@xxxxxx> wrote in message
news:f2089395-b593-45a0-88cd-34c96e46af6a@xxxxxx

Csaba Gabor wrote:hi Csaba, as long as you are using IE as an hta (fewer
restrictions), you could use an "ini" file, an xml file,
or registry entries to save your settings from
session-to-session.

cheers, jw
____________________________________________________________

You got questions? WE GOT ANSWERS!!! ..(but, no guarantee
the answers will be applicable to the questions)

Hi Joe and JW, thanks for your comments.

JW, indeed, your suggestion of using a different
standard means (such as the registry) is what I
was prepared to do. Notice that past tense in
there? Actually, I may still come back to it.

To clarify a point. I'd prefer to have a single
..vbs file in case I want to distribute that app.
And I'd like to presume a minimum write
capability (ie. I'd prefer not to write my own
auxiliary files (such as a custom .ini). However,
I may have to write a zero byte file in this case
as explained below.

Joe, I like your way of thinking as to your first
suggestion. I can't presume a web server,
but I like this thinking and have considered it
for other things in the past, especially in
conjunction with Firefox/GreaseMonkey

I tried to look at the value of document.domain
for both about:blank and for http://surenottoexist.com
In both cases I got an error.

Then I tried the following. I navigated to
http://google.at (or some other site you know that
you won't be using). I then set my own cookie on
it using the code already given. You know what? -
it stuck around!! So if I try to set a cookie on
about:blank or a domain that doesn't exist, IE won't
let me, but it's OK with letting me set it on a
site that I am actually external to. Go figure.
I'm missing exactly what security benefit these
restrictions have for me. In any case, I would
not be particularly happy to piggy back off a 3rd
party web site in this fashion.

Then I went back to the first suggestion, about
the local site, and thought it might have a 2nd
interpretation which did not presume a web server.
Perhaps it could be a local web page (ie. a .htm
file). In fact, the page wouldn't have to do anything
since it would simply be a means of letting ie
associate a cookie to the file. So get this - I
navigate IE to
WScript.ScriptFullName & "\..\empty.htm"
(which I have previously created as a 0 byte
file in the same directory) and the cookie is set
just fine!! The contents of the file are irrelevant
since only its name is important so it may as
well be 0 bytes. In addition, no internet connection
is needed this way, as opposed to the prior paragraph.
I tried navigating ie to WScript.FullScriptName (in
order to avoid writing a file) but ie is deeply suspicious
about opening a non .htm file and pops up all sorts
of alerts. Here is the demo code. Note that the
2nd running should be done within 3 minutes of
the first run (on account of 3 minute cookie
expiration), and that on the 2nd run, the execScript
line should be commented out (the line before the
MsgBox) as proof that the cookie was previously
written.

Important cautionary note: the name of the file
appears not to matter for the setting of the cookie
(ie. you can't assume a unique cookies per path
name). In other words, if you use empty.htm on
the first pass, and stub.htm on the 2nd pass, the
previous cookie will still be fished out. The domain
that shows for these cookies (doing an File \ Export)
is empty, but the directory is noted in the following
form (note forward slashes instead of backslash,
and | instead of colon):
/C|/myLib/myTest/
That means, that if you use empty.htm on one pass
and ..\stub.htm on the 2nd pass (the file names don't
matter, only the directories), you actually wind up
with two entries in the (internal) cookie table.

In conclusion, I've shown two ways to write local
cookies to IE from a .vbs script. The 1st piggy backs
off an external web site, while the (preferred) 2nd
variant (demo below) uses a 0 byte helper file (which
it creates).

Csaba Gabor from Vienna

'Setting local cookies demo
'Comment out next to the last line on 2nd running
set ie = CreateObject("InternetExplorer.Application")
emptyHTM = WScript.ScriptFullName & "\..\empty.htm"
CreateObject("Scripting.FileSystemObject"). _
CreateTextFile emptyHTM
ie.Navigate2 emptyHTM
while (ie.ReadyState<4): WScript.Sleep(1): Wend
cookieScript = _
"var exp = new Date();" & _
"var Mins3 = exp.getTime() + (1000 * 60 * 3);" & _
"exp.setTime(Mins3);" & _
"var newCookie=" & _
"'foo=frob; " & _
"expires=' + exp.toGMTString();" & _
"document.cookie = newCookie"
ie.document.parentWindow.execScript cookieScript
MsgBox "cookie is: " & ie.document.cookie


On Mar 4, 2:16 pm, "Joe Fawcett" <joefawc...@xxxxxx> wrote:

Csaba Gabor wrote:O.K. then, use a "wsf" file format (xml), and carry
along your initialization data as a "resource" embedded
in the wsf file.

You could make up the "resource" as a collection of
vbs statements to customize your gui (or whatever)
the way you want. Then just global execute the vbs
statements in the resource to do the initialization.

cheers, jw