If the alias is empty or null, don't bother using KeyChainKeyManager.
If the alias is not empty, confirm that it is associated with a
certificate, otherwise throw a CertificateValidationException
which will notify the user of the problem and ask the user to
check the server settings.
Likewise, the user is notified if the client certificate was
not accepted by the server.
With this commit, KeyChainKeyManager no longer throws the exception and
AccountSetupCheckSettings no longer catches it.
It was being thrown when the server requested a client certificate but no
client certificate alias had been configured for the server.
The code was making the incorrect assumption that the server would only
request a client certificate when such a certificate was *required*.
However, servers can be configured to accept multiple forms of
authentication, including both password authentication and client
certificate authentication. So a server may request a certificate without
requiring it. If a user has not configured a client certificate, then
that should not be treated as an error because the configuration may be
valid and the server may accept it.
The only indication that a certificate is *required* is when a
SSLProtocolException is thrown, caused by a SSLHandshakeException
resulting from a fatal handshake alert message received from the server.
Unfortunately, such a message is fairly generic and only "indicates that
the sender was unable to negotiate an acceptable set of security
parameters given the options available." So there is no definitive way to
know that a client certificate is required.
Also, KeyChainKeyManager.getCertificateChain() and getPrivateKey() no
longer throw IllegalStateException(). These methods are permitted to
return null, and such a response is appropriate if the user has deleted
client certificates from the device. Again, this may or may not cause the
server to abort the connection, depending on whether the server *requires*
a client certificate.
The app's minSdkVersion = 15 (Android 4.0.3, Ice Cream Sandwich MR1),
so there's no need to test the API level.
This also removes '@SuppressLint("TrulyRandom")'. I find no
documentation for it, nor do I find any additional lint errors
with its removal.
This only changes the vertical display order of the widgets.
The user will likely review the settings from top to bottom, but
the way they were previously arranged, settings lower on the list
were affecting things higher on the list.
Generally show top to bottom:
Server
security type
port (affected by security type above)
require login checkbox (SMTP only, affects everything below)
user
auth. type (affected by security type above, affects everything below)
password (affected by auth. type above)
client cert (affected by auth. type above)
Specifically, warn and block them when attempting to configure Client
Certificate Authentication in combination with Connection Security = None.
If this were not made obvious to the user, they might not understand why
they are not permitted to tap "Next".
Also, move the initialization of all view listeners out of onCreate() into
initializeViewListeners() which is then called near the end of onCreate(),
helping to assure that the listeners won't be triggered during the
initialization of views inside onCreate().
Change the translated strings files to a format similar to what
Transifex exports. This should make it easier to see the content changes
when translations are pulled from Transifex for the first time.
