On 07/12/12 10:46, Marek Potociar wrote:
> Hi Bill,
> Thank you for writing this up. It's been sitting on my plate for too long.This is a great starting point. A few thoughts/questions:
>
> IIUC, you suggest we re-introduce a "client builder" concept that would be represented by ClientFactory. I'm fine with that. With KeyStore/TrustManager ClientFactory builder methods in place, should we expose similar methods via client-side configuration? Or does the proposal mean that users would not be able to modify keystore/truststore etc. on any other level than Client (i.e. not in WebTarget or Invocation.Builder)? Are there any common use cases that we would be ignoring? IOW, do you see a need to change keystore/truststore configuration for different resource targets? Also, I think we need to expose a method that would accept a custom SecureRandom instance.
I'd start with the Client-level support only
>
> As for the Authentication, I cannot really decide. On one hand I am inclined to prefer a composition-based solution, e.g. something like
>
> target.register(new BasicAuthFilter(user, pwd)) // or BasicAuthFeature....
>
> but at the same time, your proposal works well with the fluent API and with careful javadocing can be extensible in the future too. The disadvantage of the above is also the need to provide the implementation in the spec and fixing any bugs can become a nightmare after we release. So I guess I would like to hear from others what they think before I make up my mind.
>
> The one problem I'd like to point out though is that it is a big security hole to force users to represent passwords as plain Strings. Strings in Java are internalized and are not garbage-collected in the same way as other objects. They may stay in the heap long after they're not used. A memory dump may thus reveal passwords stored as strings. I guess it's hard to completely avoid this issue, but I was thinking whether we should also expose overloaded methods that take e.g. byte[] or CharSequence as a password input for users who want to avoid working with plain-string passwords in their code.
I'd support Authentication interface offering the support for the
well-known/mainstream schemes only, which is what Bill suggested.
In other cases "Authorization" header can be populated from filters or
directly from the client code as needed. I thought of having callbacks
supported too but I do not see now what it will give users if they can
set Authorization header manually anyway, while the filters can be used
to encapsulate dealing with the advanced schemes.
Sergey
>
> Marek
>
> On Dec 6, 2012, at 11:45 PM, Bill Burke<bburke_at_redhat.com> wrote:
>
>> Here's some thoughts on SSL. Was thinking we'd change/refactor/augment the CLientFactory class, so it might look like this:
>>
>> Client client = ClientFactory.factory()
>> .serverTruststore(KeyStore truststore)
>> .build();
>>
>> Client client = ClientFactory.factory()
>> .serverTruststore(KeyStore truststore)
>> .clientKeyStore(KeyStore keystore)
>> .build();
>>
>> You might want to have additional methods like serverSSLTrustManager(X509TrustManager)
>>
>>
>> or options for other ways to set up SSL connections.
>>
>> For non-cert authentication, I was thinking we could do it at the WebTarget level:
>>
>> WebTarget target = client.target("https://")
>> .authentication().basic("username", "password");
>>
>> interface Authentication {
>> WebTarget basic(String username, String password);
>> WebTarget digest(String username, String password);
>> }
>>
>> interface WebTarget {
>> Authentication authentication();
>> ...
>> }
>>
>> Is that too limiting?
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>