Hi Shawn and everyone,
> > And this,
> > too, could be done with the same mechanism as the xmlhttp
> > instantiation, making it possible to minimize or prevent external
> > access to our objects.
>
> It sounds like you have something 'automatic' in mind that
> just solves the security issues here? Can you explain that a
> little bit more?
I thought I'd bring back this thread from the dark before going to bed,
because I think I may have a solution for my security concerns.
window.external is exposed to the IE DOM as a custom object reference into
the host. We can just hand out any old object we want from the external
property, and it's only available to IE instances hosted inside the
DQSDHost.
So if we expose a window launcher and possibly an XmlHttp launcher from
window.external (I have a couple of other ideas, as well), we can have that
functionality within DQSD, but without affecting IE as a whole.
Examples:
window.external.openWindow("file:///C:\Program Files\Quick Search
Deskbar\help.html", "centered, resizable");
var xmlHttp = window.external.createObject("Microsoft.XmlHttp");
window.external.closeWindow(); // closes the current window without
annoying prompt dialog
Now we only have to make sure nobody manages to;
a) inject malign searches into /searches or /localsearches
b) writes custom code to use DQSDHost.dll, though this is pretty hard -- the
browser host is an internal implementation detail, only the deskband is
COM-createable.
What do you think?
- Kim
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Archive: https://lists.sourceforge.net/lists/listinfo/dqsd-devel
