PATCH: Better cross-domain cookie detection [BR 66090]

[Dawit A.]

On Sunday 30 November 2003 09:01, Waldo Bastian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun November 30 2003 02:40, Dawit A. wrote:
> > Hi,
> >
> > The following patch is intended to address the malfunctioning of
> > cross-domain cookie detection (BR# 66090) when the web pages contain
> > IFRAMES or FRAMES.
> >
> > The patch seems to correctly catch cross-domain requests even for
> > iframes, but I am still being prompted for cookies that I should not be.
> > Waldo, any ideas ? Hmm... I guess I should make sure the meta-data is
> > set, i.e. the crossDomain function works properly.
>
> Ah, very nice, I had a quick look into this already. I also noticed that
> the cross-domain check needs to be done in the http slave, instead of the
> khtml part. Otherwise it will not work correctly in combination with
> redirections.
>
> E.g. http://www.kde.org loads the image
> http://www.kde.org/ads/ad.server.com/ foo.png which redirects to
> http://ad.server.com/foo.png
>
> Will play a bit with your patch.

Already changed the patch... I have been playing with this since last night as 
well. One of the things I realized is that currently the "cross-domain" meta 
data is not set unless the loader is used. An iframe or child frames requests 
for that matter do not go through the loader, hence the "cross-domain" 
meta-data will never be set in those cases. The solution I am trying now is a 
whole sale move of the cross-domain check code into a public function in 
KHTMLPart, isCrossDomainRequest( const KURL& url = KURL() ). I can then call 
this function from both openURL(...) in KHTMLPart and the Loader. 

I also thought about redirection. One way to deal with that would be to send 
the origination url along with the flag and only use the url on redirections, 
no ?

As a side note I actually do not like the fact that the jobs do not give 
applications the ability to override the automatic redirection. What would 
have been ideal IMHO is ability for applications to override the automatic 
redirection if desired (a flag for example) and then call the default 
automatic implementation if they chose to do so. This way application can do 
whatever they need, like warning the user about the pending redirection 
(which BTW is a requirement of the HTTP spec.), before allowing the 
redirection to take place. I do not know if it is feasible to do this right 
now though...

-- 
Regards,
Dawit A.
"Preach what you practice, practice what you preach"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cross-domain.diff
Type: text/x-diff
Size: 3576 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20031130/e4b43b92/attachment.diff>