Use authenticationRequired as intended instead of sending in createRequest

[guruz]

#5728 (comment)

@guruz The code for sending the Auth header all the time refers to issue #4326 - doesn't that mean we can't re-revert ef9483c as long as we support servers 8.X?

We would need to check which server 8.x version has this actually fixed.
See also https://github.com/owncloud/core/wiki/Maintenance-and-Release-Schedule on how long servers are supported.

Maybe @ogoffart could explain if this collides with OAuth2 or not, I didn't see any big issues when checking https://github.com/owncloud/client/pull/5668/files

FYI @ogoffart @ckamm

[guruz]

FYI @ckamm

[ckamm]

So, since all 8.X servers are now at EOL we could remove this workaround. It might help with addressing bugs like #5989 that are seem related.

[ckamm]

Further investigation:

• QAuthenticator in Qt 5.6.1 doesn't support the "bearer" challenge or response that's needed for OAuth2.
• Issue [Regression] In 2.4 "Credentials Wrong" state does not retrigger the password-asking form #5989 isn't addressed by feeding credentials (for basic auth) in the slot for authenticationRequired

Result: We cannot use the QAuthenticator / authenticationRequired-signal based way of answering authentication challenges and should stick to what already works.

[ckamm]

OAuth2 support in Qt:

• QtNetworkAuth (preview in 5.8, released in 5.9?) https://doc.qt.io/qt-5/qtnetworkauth-index.html
• pipacs/o2 (https://github.com/pipacs/o2)

But since @ogoffart already made OAuth2 work for 2.4, none of these are urgent.

[guruz]

@ckamm said this is not possible because we can't access "Bearer" authentication from QAuthenticator.

@thiagomacieira

[ogoffart]

Correct, this is not possible with oauth2 anyway. Even QtNetworkAuth do the same as us.