lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-9028) fix bugs in (add sanity checks for) SSL clientAuth testing
Date Wed, 27 Apr 2016 21:20:12 GMT

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

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


Working on SOLR-9040 helped me discover some stuff about when/how exactly the JVM reads in
the {{javax.net.ssl.*}} sys props to build the default {{SSLContext}} -- notably: it's a singleton,
so we can't change the sysprops after startup and expect it to do what is expected.  (And
there doesn't appear to be ably convinience classes/methods for loading a "custom" {{SSLContext}}
that obeys those properties by default unless/until you override them)

In this updated patch, I've added test code to preserve the {{SSLContext.getDefault()}} on
test class init, and use {{SSLContext.setDefaul()}} during testing to _mimic_ the effects
of how the JVM should behave if the corisponding {{javax.net.ssl.*}} properties had been set.
(then restore the preserved default in an {{@After}} method)

This seems to be working well.

I briefly considered eliminating all of the explicit modifications of HttpCiientUtil's HttpClientBuilder
/ SchemaRegistryProvider in these tests, so we were always mimicing how a solrj code will
behave by default when these props are set, but ultimately I think the current mix of both
styles of getting an SSLContext are better -- it helps us test both the "solrj client expects
to use standard javax sys properties" approach, and the "solrj client code explicitly using
HttpCiientUtil to say 'use these options for ssl'" approach.

There's still a handful of nocommits, that fall into two categories:
* I want to cleanup some of the SSLTestConfig methods that only exist in master and have weird
side effects (introduced in SOLR-4509)
* I think it might makes sense to promote the the SSLContext.getDefault/setDefault preservation
to SolrTestCaseJ4 ... but i'm not 100% certain yet.  Need to think it through more.



> fix bugs in (add sanity checks for) SSL clientAuth testing
> ----------------------------------------------------------
>
>                 Key: SOLR-9028
>                 URL: https://issues.apache.org/jira/browse/SOLR-9028
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>         Attachments: SOLR-9028.patch, SOLR-9028.patch, SOLR-9028.patch, SOLR-9028.patch,
SOLR-9028.patch, os.x.failure.txt
>
>
> While looking into SOLR-8970 i realized there was a whole heap of problems with how clientAuth
was being handled in tests.  Notably: it wasn't actaully being used when the randomization
selects it (aparently due to a copy/paste mistake in SOLR-7166).  But there are few other
misc issues (improper usage of sysprops overrides for tests, missuage of keystore/truststore
in test clients, etc..)
> I'm working up a patch to fix all of this, and add some much needed tests to *explicitly*
verify both SSL and clientAuth that will include some "false positive" verifications, and
some "test the test" checks.



--
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


Mime
View raw message