janhoy commented on a change in pull request #139:
URL: https://github.com/apache/solr/pull/139#discussion_r646401624
##########
File path:
solr/core/src/test/org/apache/solr/security/JWTAuthPluginIntegrationTest.java
##########
@@ -127,13 +135,40 @@ public void tearDown() throws Exception {
super.tearDown();
}
- @Test(expected = IOException.class)
- public void infoRequestWithoutToken() throws Exception {
- get(baseUrl + "/admin/info/system", null);
+ @Test
+ public void extractCertificateFromPem() throws IOException {
Review comment:
I added two tests to JWTAuthPluginTest, verifying that init() fails. No
need for integration test of all these?
If you load a `security.json` to ZK with bogous `trustedCertsFile` or
`trustedCerts` (or other config) while Solr is running, the JWT plugin `init()`
will throw and exception and auth will not be enabled/changed. Here are log
messages you can expect to see prior to exception:
> Reading trustedCerts from file {}
or
> Reading trustedCerts PEM from configuration string
In the exception stacktrace itself you'll see either
> Wrong type of certificates. Must be DER or PEM format
or
> Failed loading certificate(s) from input stream
If you start Solr from scratch with a bogous config, I think the server will
fail during CoreContainer init and not start at all. The fact that users need
to monitor Solr logs when pushing new security.json is unfortunate. It is easy
to make mistakes when automating this with scripts. You may start Solr, then
apply security.json which fails, and then you have an unsecured cluster without
even knowing :(
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
