[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    [PyQt] QtNetworkAccessManager detect failed proxy authentication requests
From:       Paweł Miech <pawelmhm () gmail ! com>
Date:       2015-12-20 10:52:27
Message-ID: CAO38UCkcQ55-79Dy6N0y1LUT9Did8E4WdekgLcgcbpMzax3cWA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hello,

I need to provide users of my application with ability to set multiple
(possibly authenticated) network proxies. This turns out to be surprisingly
difficult and tricky.

First surprise is that NetworkAccessManager setProxy() method allows to
specify password and username when initializing QNetworkProxy object, BUT
this has NO effect on actual authentication headers. If proxy requires
authentication NAT emits signal proxyAuthenticationRequired in which you
need to explicitly set credentials on QAuthenticator object.  Now here's
where I'm stuck and confused. I can set credentials in Authenticator. If
they are correct request will go through but what if credentials are wrong?
With current implementation of this api I don't see any way to stop
processing request after requests are rejected by proxy due to bad
credentials. If user specifies bad username + password Qt will keep
retrying request till infinity with mistaken credentials.

Is there any way to stop processing requests after detecting repeated
"proxy authentication required" signal?

I was thinking about keeping some form of NAT object attribute keeping
track of proxy authentication queries, but this could be difficult to get
right - I would need to basically keep some dictionary of all requests sent
via proxy matched to number of proxy authentication required signals
emitted per request.  It seems like a hack and dirty solution.

Maybe cleaner solution would be aborting request after receiving some
signal "first proxy authentication request rejected", but this again is not
easy to do, because after receiving bad credentials proxy will just keep
responding with 407 and this response will be same no matter if this is
first or 10th request from Qt Application.

Final way is just ditching proxyAuthenticationRequired signal and setting
"Proxy-Authorization" headers manually in NAT createRequest(), this again
has the drawback of losing nice support for different authentication
methods that QAuthenticator provides. I see Authenticator supports "Basic",
"Digest-MD5", and "NLTM version 2" methods, so I'd have to write code
adding headers that would be duplicating API code to support those schemes
(I could also decide to ignore supporting those that I dont need, say
support just basic).

How would you handle problem like this? Do you think it warrants creating
some issue in Qt bug tracker? I think Qt api users should be able to easily
detect failed authentications somehow so I see lack of mechanism to detect
this as a missing feature in QT, am I right here?

[Attachment #5 (text/html)]

<div dir="ltr">Hello,<div><br></div><div>I need to provide users of my application \
with ability to set multiple (possibly authenticated) network proxies. This turns out \
to be surprisingly difficult and tricky.  </div><div><br></div><div>First surprise is \
that NetworkAccessManager setProxy() method allows to specify password and username \
when initializing QNetworkProxy object, BUT this has NO effect on actual \
authentication headers. If proxy requires authentication NAT emits signal \
proxyAuthenticationRequired in which you need to explicitly set credentials on \
QAuthenticator object.   Now here&#39;s where I&#39;m stuck and confused. I can set \
credentials in Authenticator. If they are correct request will go through but what if \
credentials are wrong? With current implementation of this api I don&#39;t see any \
way to stop processing request after requests are rejected by proxy due to bad \
credentials. If user specifies bad username + password Qt will keep retrying request \
till infinity with mistaken credentials.  </div><div><br></div><div>Is there any way \
to stop processing requests after detecting repeated &quot;proxy authentication \
required&quot; signal?  </div><div><br></div><div>I was thinking about keeping some \
form of NAT object attribute keeping track of proxy authentication queries, but this \
could be difficult to get right - I would need to basically keep some dictionary of \
all requests sent via proxy matched to number of proxy authentication required \
signals emitted per request.   It seems like a hack and dirty solution.  \
</div><div><br></div><div>Maybe cleaner solution would be aborting request after \
receiving some signal &quot;first proxy authentication request rejected&quot;, but \
this again is not easy to do, because after receiving bad credentials proxy will just \
keep responding with 407 and this response will be same no matter if this is first or \
10th request from Qt Application.  </div><div><br></div><div>Final way is just \
ditching proxyAuthenticationRequired signal and setting \
&quot;Proxy-Authorization&quot; headers manually in NAT createRequest(), this again \
has the drawback of losing nice support for different authentication methods that \
QAuthenticator provides. I see Authenticator supports &quot;Basic&quot;, \
&quot;Digest-MD5&quot;, and &quot;NLTM version 2&quot; methods, so I&#39;d have to \
write code adding headers that would be duplicating API code to support those schemes \
(I could also decide to ignore supporting those that I dont need, say support just \
basic).  </div><div><br></div><div>How would you handle problem like this? Do you \
think it warrants creating some issue in Qt bug tracker? I think Qt api users should \
be able to easily detect failed authentications somehow so I see lack of mechanism to \
detect this as a missing feature in QT, am I right here?</div></div>


[Attachment #6 (text/plain)]

_______________________________________________
PyQt mailing list    PyQt@riverbankcomputing.com
https://www.riverbankcomputing.com/mailman/listinfo/pyqt

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic