> On April 16, 2011, 4:45 p.m., Kevin Krammer wrote:
> > Wouldn't it make more sense to change KProtocolInfo::protocolClass() such
> > that it considers data: to be local access?
>
> Volker Krause wrote:
> That was indeed my first attempt, but David pointed out that this would
> have further (security) implications, since the protocol class is also used
> in a number of different places where the use of data: might not be desired.
> Instead, I followed the approach chosen by KHTML now, explicitly
> white-listing data: only for retrieval but nothing else.
Well I guess I am the one that broke this in an attempt to make it more
generic. The change seems fine, but you patch should then do the following:
if (scheme.compare(QL1S("data"), Qt::CaseInsensitive) == 0)
return true;
if (KProtocolInfo::isKnownProtocol(scheme) &&
KProtocolInfo::protocolClass(scheme).compare(QL1S(":local"),
Qt::CaseInsensitive) == 0)
return true;
return false;
since isLocalRequest is more likely to encounter the "data" protocol than any
other local protocol.
- Dawit
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101140/#review2680
-----------------------------------------------------------
On April 16, 2011, 4:27 p.m., Volker Krause wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101140/
> -----------------------------------------------------------
>
> (Updated April 16, 2011, 4:27 p.m.)
>
>
> Review request for kdelibs.
>
>
> Summary
> -------
>
> Currently KIO::AccessManager blocks retrieval of embedded data: URLs if
> external references are disabled. This does not match the behavior in KHTML
> and breaks for example the display of sender photos/logos in KMail (which
> uses kdewebkit).
>
>
> Diffs
> -----
>
> kio/kio/accessmanager.cpp bfb4721
>
> Diff: http://git.reviewboard.kde.org/r/101140/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> Volker
>
>
