You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2016/05/11 22:27:12 UTC

[jira] [Updated] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

     [ https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man updated SOLR-8970:
---------------------------
    Attachment: SOLR-8970.patch

updated patch that goes the direction Joseph suggested, instead of a sys prop override, there's not a copy of the cert in the resources directory that's used so it can always be found.

still running full test, but I'm pretty happy with this and plan to move forward as soon as i see precommit pass.

> SSLTestConfig behaves really stupid if keystore can't be found
> --------------------------------------------------------------
>
>                 Key: SOLR-8970
>                 URL: https://issues.apache.org/jira/browse/SOLR-8970
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: SOLR-8970.patch, SOLR-8970.patch, SOLR-8970.patch
>
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean "trySslClientAuth") but it has a hardcoded assumption that the keystore file it can use (for both the keystore and the truststore) will exist at a fixed path in the solr install.
> when this works, it works fine - but if end users subclass/reuse SolrTestCaseJ4 in their own projects, they may do so in a way that prevents the SSLTestConfig keystore assumptions from being true, and yet they won't get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org