| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Also adds a unit test.
Fixes #541.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we had the policy that no qt keywords were allowed in headers
that may be included by users. However since there was no automatic test
verifying that in some places keywords were still used.
This now disables qt keywords completely, also in tests and examples. Qt
keywords are in general no good or really good idea as they even
conflict with the standard library (`emit` at least).
In some cases in the examples I just removed the slot tag if the
functions didn't need to be slots (anymore).
Closes #503.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
QCryptographicHash::Sha3_512 was accidentially using Keccak-512 before
Qt 5.9.2, thus we can only use SCRAM-SHA3-512 when using Qt >= 5.9.2.
|
| | |
|
| |
|
|
| |
Adding new algorithms only needs a new name/algorithm entry now.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous logic was:
- use the preferred SASL mechanism if available
- otherwise use the first supported mechanism offered by the server
However RFC 6120, section 6.3.3 states:
"The initiating entity MUST maintain its own preference order independent
of the preference order of the receiving entity."
The new logic is:
- order our supported mechanisms from most secure to least secure
- if the user sets QXmppConfiguration::saslMechanism, put it first
- use the best mechanism supported by the server
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
