DISCLAIMER: Trusting all SSL certificates is generally a bad security practice and can leave your system vulnerable to man-in-the-middle attacks. Only implement this solution in a controlled environment.
For a JAX-WS client to accept all SSL certificates from any server, you must create an SLLSocketFactory that contains an X509TrustManager that bypasses all certificate validation.
Building the X509TrustManager is simple. Just create a class that implements the X509TrustManager interface and essentially do nothing in the methods:
If Host Name validation is desired, this can be implementd in the checkServerTrusted method. You can obtain the server Host Name from the last certificate in the passed-in array of X509Certificates.
Once your TrustManager is set up, the next step is to create an SSLSocketFactory. The factory is created by getting an instance of SSLContext and initializing it with your X509TrustManager you created previously. Then calling getSocketFactory on the context will return your SSLSocketFactory.
I recommended caching the SSLSocketFactory instance rather than creating a new one for each request because initialization can be time-consuming.
After the SSLSocketFactory is constructed, all that is left is to add it to your requestContext of your service proxy.
Your client should now be able to communicate with servers over SSL without needing to specify a trust store or add any new certificates to your existing trust store
Singleton In A Crowd
Adventures in Java programming in the Deep South.
Thursday, December 6, 2012
Sunday, November 6, 2011
Adding a P2 Repository Dynamically at Runtime
After experiencing the pains of dealing with a homegrown thick-client update system, we decided to give Eclipse's P2 provisioning system a try. For Eclipse 3.7 (Indigo), the P2 API received quite a bit of TLC, especially on the UI end, so we felt like it was mature enough for us to take a look at. It was very easy to create an Eclipse Plugin/Feature/Product that gets updated from a static P2 repository with a URI known at build time. All you have to do is create a p2.inf file and populate it with the correct repository locations, as explained in step 7 of Ralf Eberts excellent tutorial. We, however, had a situation where each customer would have their own private repository, so we had to set the update location dynamically at run time. Here's how we did it:
First, we had to obtain the P2 provisioning agent:
Once we have the provisioning agent, we can use it to get the metadata manager and artifact manager. You need both managers because the equinox provisioning systems allows for separate locations for each. Once we have the managers, we can simply add the URIs that we retrieved at run time via some external property file, database, preference store, etc.:
You'll need to be sure and add the following imports:
and you'll also need to make sure your plugin has the following dependencies:
First, we had to obtain the P2 provisioning agent:
Once we have the provisioning agent, we can use it to get the metadata manager and artifact manager. You need both managers because the equinox provisioning systems allows for separate locations for each. Once we have the managers, we can simply add the URIs that we retrieved at run time via some external property file, database, preference store, etc.:
You'll need to be sure and add the following imports:
- import org.eclipse.equinox.internal.p2.core.helpers.LogHelper;
- import org.eclipse.equinox.internal.p2.core.helpers.ServiceHelper;
- import org.eclipse.equinox.internal.p2.ui.ProvUI;
- import org.eclipse.equinox.p2.core.IProvisioningAgent;
- import org.eclipse.equinox.p2.core.ProvisionException;
- import org.eclipse.equinox.p2.operations.ProvisioningJob;
- import org.eclipse.equinox.p2.operations.ProvisioningSession;
- import org.eclipse.equinox.p2.operations.UpdateOperation;
- import org.eclipse.equinox.p2.repository.artifact.IArtifactRepositoryManager;
- import org.eclipse.equinox.p2.repository.metadata.IMetadataRepositoryManager;
and you'll also need to make sure your plugin has the following dependencies:
- org.eclipse.equinox.p2.core
- org.eclipse.equinox.p2.operations
- org.eclipse.equinox.p2.metadata
- org.eclipse.equinox.p2.engine
- org.eclipse.equinox.p2.ui
- org.eclipse.equinox.p2.metadata.repository
- org.eclipse.equinox.p2.repository
Sunday, February 13, 2011
Animated Visual Effects in an SWT Table
For the project I am currently working on, we have a view that contains a large table. When an item in that table is selected, it drives what data shows up in the other views inside the perspective. We needed a way to notify the user of what the context of his selection was, even if he changed focus to another view. I wanted something with a little visual flair, rather than just the normal, mundane icon. What I came up with was a "pulsing" background color that fades in at out slowly (keyword: slowly). It draws the user's attention if the user is looking for his selection, but does not distract away from other views.
This approach presented two main challenges: first, I wanted to develop a clean algorithm for fading between any two colors so that the speed of the pulsing would be consistent regardless of colors, and 2nd, all the heavy duty work would need to be done in a separate thread from the GUI thread so I wouldn't freeze up the interface.
The following code creates a listener that, upon being notified of a Table Mouse double click event, starts a new thread that controls a pulsing background that fades between two colors:
This approach presented two main challenges: first, I wanted to develop a clean algorithm for fading between any two colors so that the speed of the pulsing would be consistent regardless of colors, and 2nd, all the heavy duty work would need to be done in a separate thread from the GUI thread so I wouldn't freeze up the interface.
The following code creates a listener that, upon being notified of a Table Mouse double click event, starts a new thread that controls a pulsing background that fades between two colors:
Subscribe to:
Posts (Atom)