On Mon, Feb 3, 2020 at 11:51 PM Johan Ouwerkerk <jm.ouwerk...@gmail.com> wrote: > > On Mon, Feb 3, 2020 at 11:27 AM laurent Montel <mon...@kde.org> wrote: > > > > Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit : > > > I updated: > > > > > > https://community.kde.org/Policies/API_to_Avoid > > > > > > Which had no mention of this. > > > > > > David > > > > I think that you made an error > > > > "networkAccessManger->setAttribute(QNetworkRequest::FollowRedirectsAttribute, > > true); " > > Doesn't exist it's a enum from QnetworkRequest::RedirectPolicy > > And FollowRedirectsAttribute is old value > > It seems that we need to use QnetworkRequest::NoLessSafeRedirectPolicy > > directly no ? > > > > Yes, the example code is definitely wrong: in the real world redirects > are an attack vector. A few cases to consider: > > * Loops of redirects (could happen if the site is broken) > * Leaking sensitive information via e.g. the Referrer header
I would recommend follwoing the various browsers (Firefox & Chromium in particular) behaviour here. Not only are they what we generally test redirects with when doing server maintenance, but they also have put quite a bit of work into being secure. With regards to loops, stopping after 10 or so redirects should be more than sufficient as a safe guard here. 5 if you'd like to be a bit more restrictive. I can't imagine a need with our systems to need more than 3 (first to https, second from somewhere to the mirror network redirector, third to a mirror) Because mirrors often don't support https (and Mirrorbrain doesn't support handling https mirrors) clients that interact with download.kde.org or files.kde.org *must* support transitioning from https:// to http:// (under a different domain - so https://download.kde.org to http://ftp.gwdg.de for instance). This would primarily affected applications that need to fetch large binary assets. > > Regards, > > - Johan Cheers, Ben