Multiple MSHTML instances in same process seperate cookie stores?
Adar Wesley
I know this question has been aswered before and the simple answer was that,
"WinInet stores all cookies on a per process basis, so all instances will
share cookies."
I would like to undestand the details here.
I understand that MSHTML implements an OLE object and supports the
IOleObject, IPersist, IPersistStream, IPersistFile, IPersistStorage,
IOleClientSite, ...
Does WinInet access any of these interfaces while storing or retrieving
cookies?
Is it possible to Aggregate the MSHTML object, implement any combination
of these interfaces and override the calls to WinInet for presisting cookies?
The documentation about MSHTML and the OLE implementation is pathetic.
Please help.
Thanks,
---
Adar Wesley
Igor Tandetnik
> I know this question has been aswered before and the simple answer
> was that, "WinInet stores all cookies on a per process basis, so all
> instances will share cookies."
Not all cookies - session cookies. Persistent cookies are stored on
per-user basis.
> I would like to undestand the details here.
>
> I understand that MSHTML implements an OLE object and supports the
> IOleObject, IPersist, IPersistStream, IPersistFile, IPersistStorage,
> IOleClientSite, ...
It does, but I'm not sure what this has to do with cookies.
> Does WinInet access any of these interfaces while storing or
> retrieving cookies?
No. MSHTML uses WinInet, not the other way round. WinInet cookie
handling is mostly transparent to its clients.
> Is it possible to Aggregate the MSHTML object, implement any
> combination
> of these interfaces and override the calls to WinInet for presisting
> cookies?
MSHTML makes no calls to WinInet to persist cookies. WinInet does it
entirely on its own.
Having said that, there is a way to maintain private cookie jars - a
rather difficult and painful way. You start with a passthough APP - e.g.
this one (sorry for shameless plug):
You intercept IInternetProtocolSink::GetBindInfo, and add
BINDINFO_OPTIONS_WININETFLAG flag to BINDINFO::dwOptions and
INTERNET_FLAG_NO_COOKIES to BINDINFO::dwOptionsFlags. This instructs
WinInet to ignore cookies - it neither adds Cookie: headers on outgoing
requests, nor acts on Set-Cookie: headers on response. You then manually
add Cookie: headers in IHttpNegotiate::BeginningTransaction, presumably
from a private cookie jar you maintain on a per-instance basis
In IHttpNegotiate::OnResponse you manually parse any Set-Cookie headers
and update your cookie jar.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Adar Wesley
Thanks for the quick reply. This was an excellant pointer for me. You sent
me to do
some heavy duty reading ...
I took a look at your code in the PassthruAPP sample. I had to make one
small change
in the code to make it run under VS2005. This change was due to
imlementation changes
in the ATL base classes. While running the code an ATLASSUME was hit in the
atlcore.h
in the method CComSafeDeleteCriticalSection::Lock(). The comment next to the
ATLASSUME statement led me to the right solution.
The change was in the protocolCF.inl file, in the method:
template <class Factory, class Protocol, class FactoryComObject>
inline HRESULT CMetaFactory<Factory, Protocol, FactoryComObject>::
CreateInstance(Factory** ppObj)
Made the following change:
Original was:
p->InternalFinalConstructAddRef();
hr = p->FinalConstruct();
Changed to:
p->InternalFinalConstructAddRef();
/* Added initialization to object as specified by new ATL implementation -
Adar Wesley 5/5/06 */
hr = p->_AtlInitialConstruct();
if (SUCCEEDED(hr)) /* Added if (SUCCEEDED(hr)) on result of Initialization
- Adar Wesley 5/5/06 */
hr = p->FinalConstruct();
End changes
Assuming I follow the path you suggested and tell WinInte not to handle
cookies at all and use the
APP implementation to intercept all the requests, how can I know on behalf
of which client the current
request is executing? I will need this information in order to associate
the right cookie jar that I will
implement.
Is there a different InternetSession for each client?
Can I know from the current thread context which client is the caller?
Thanks,
---
Adar Wesley
Igor Tandetnik
news:2982179A-6E5A-4D40...@microsoft.com
> Assuming I follow the path you suggested and tell WinInte not to
> handle cookies at all and use the
> APP implementation to intercept all the requests, how can I know on
> behalf of which client the current
> request is executing?
This is actually a surprisingly tough problem. For some ideas, see