I have added a new KIO meta-data to disable username spoofing change. See
https://projects.kde.org/projects/kde/kdelibs/repository/revisions/bab4ee944b2d045e13cb73a5e8c95fe1d62d49d1
You can now disable the spoofing check by doing something like the following:
KIO::TransferJob* job = KIO::get(url,....);
job->addMetaData(QLatin1String(" no-spoof-check-prompt"),
QLatin1String("TRUE"));
On Wed, Nov 23, 2011 at 8:57 PM, Shantanu Tushar Jha
<jhahon...@gmail.com> wrote:
> Hi,
>
> On Wed, Nov 23, 2011 at 11:22 PM, Dawit A <ada...@kde.org> wrote:
>>
>> On Tue, Nov 22, 2011 at 11:20 PM, Shantanu Tushar Jha
>> <jhahon...@gmail.com> wrote:
>> > On Tue, Nov 22, 2011 at 11:26 PM, Dawit A <ada...@kde.org> wrote:
>> >>
>> >> On Tue, Nov 22, 2011 at 11:09 AM, Shantanu Tushar Jha
>> >> <jhahon...@gmail.com> wrote:
>> >> > Hi,
>> >> >
>> >> > I'm pretty sure everyone will have seen the message `You are about to
>> >> > log in
>> >> > to the site "api.opendesktop.org" with the username "user", but the
>> >> > website
>> >> > does not require authentication. This may be an attempt to trick
>> >> > you.'
>> >> > when
>> >> > you tried to use anything that uses Attica (Get hot new stuff, social
>> >> > desktop settings, gluon and so on).
>> >> >
>> >> > Seeing the dialog once is ok, but it gets really irritating when 4-5
>> >> > of
>> >> > these pop up simultaneously because the app might be performing more
>> >> > than
>> >> > one kio_http requests (which is the case in almost every social
>> >> > component in
>> >> > gluon).
>> >>
>> >> So long as the request URL does not change, you get one single prompt.
>> >> If you are sending multiple requests to different sites using the same
>> >> URL format, then you are going to be prompted multiple times.
>> >
>> > Well in gluon, multiple requests ( http://paste.kde.org/149786/ ) are
>> > sent
>> > to the same site (api.opendesktop.org), and this happens
>> > http://wstaw.org/m/2011/11/23/plasma-desktopwp1921.png . Can this be
>> > fixed
>> > so the dialog only appears once per server?
>> >>
>> >> > So, the question is, what to do to prevent these from popping up
>> >> > unnecessarily? Attica is performing a legitimate login to the
>> >> > opendesktop
>> >> > website [1], so it shouldn't be reported as a problem.
>> >> >
>> >> > [1] of the form
>> >> > https://usern...@api.opendesktop.org/v1/content/something
>> >>
>> >> Can you please explain how "Attica is performing a legitimate login to
>> >> opendesktop website" by including a 'username@' into a request URL
>> >> that does not require HTTP authentication ? You are getting the
>> >> spoofing prompt because the request URL contains a username and the
>> >> server does not respond with a 401/407 response code or a redirection.
>> >> IOW, the site does not really require authentication at all. Hence,
>> >> Attica or any other client code has no business adding the username to
>> >> the request URL. So the question remains why exactly is Attica adding
>> >> a username@ to the request URL ?
>> >
>> > Hmm thanks for the insight, I tried manually browsing to the
>> > "authentication
>> > required to access" URLs as per
>> >
>> > http://www.freedesktop.org/wiki/Specifications/open-collaboration-services#search and
>> > looks like the server is at fault (i.e. it doesn't ask for auth). Will
>> > poke
>> > the guys managing it soon. However, we still should show the message
>> > only
>> > once per site, what do you think?
>>
>> Yes, it should. Unfortunately the problem with multiple dialogs on
>> multiple requests at once is not limited to the spoofing check. You
>> get the same multiple dialog boxes for SSL checks as well for example.
>>
>> It is a known KIO limitation that is caused by the fact that each
>> ioslave is a separate processes and as such the message dialog boxes
>> shown are done from separate processes. It is not an easy fix since it
>> would require some external process like a kded module and
>> communication over dbus to keep track of the message prompt requests
>> from multiple processes. Much like how it is currently done for the
>> password dialogs.
>>
>> Anyhow, the easiest way to address this issue right now is to simply
>> provide a meta-data that would disable the spoofing check ; so it will
>> be up to you to disable it from your own client application. It will
>> be enabled by default of course.
>
> Ah ok, how do I do that?
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
