Tech Forum

I am trying to update the suite of automated tests for our project and I noticed that because our site uses a self-signed SSL certificate, Firefox prompts to confirm the exception. The problem is, this causes our tests to fail unless we manually confirm the exception. This would be fine if it was just a one time thing but you have to do it each time you launch the automation.

What is the best way to bypass this warning from within automation?

Are you using WebDriver (Selenium 2)?

If you are what if you try setting the following settings when you create your FirefoxDriver? Like so:


FirefoxProfile profile = new FirefoxProfile();
profile.setAcceptUntrustedCertificates(true);
profile.setAssumeUntrustedCertificateIssuer(true);
driver = new FirefoxDriver(profile);

Mike

Mike,

We aren't currently using WebDriver. Thank you for this information though because it provides exactly what we need to refactor our test suite.

What tool are you using for your automated tests? I was a little confused by your response is this still a problem?

Sorry by being too vague. Let me explain.

We are not using WebDriver currently but we plan on refactoring our test suite soon to take advantage of the flexibility that it offers.

Here is the problem that we are experiencing. Every time that Selenium launches Firefox, it does so with a fresh profile which makes it impossible to permanently bypass the certificate exception. To overcome this problem, we could simply provide a different configuration to Selenium, however the method that we would need to modify is buried deep within Stack code. Here is what would need to change.

Inside of the class org.lds.stack.qa.selenium.SeleniumServerHelper the following changes would need to be made to the startServer() method:

public void startServer() throws Exception {
if (!isServerSetup()){
RemoteControlConfiguration conf = new RemoteControlConfiguration();
conf.setTrustAllSSLCertificates(true);
server = new SeleniumServer(conf);
server.start();
}
}

I was initially wondering if there was a different way to configure Selenium since it doesn't make much sense to have to change Stack code every time that we want to make a configuration change. When you suggested the WebDriver solution, however, I realized that in the long run it would be best to just pay down our technical debt by refactoring to WebDriver sooner than later.

After talking with our team, we feel like making the move to WebDriver now makes more sense than trying to work around these issues. I hope that clarifies. Sorry again for being so vague initially but your WebDriver solution seemed so intuitive that I realized that we should try a better approach. Thanks again for your help!

Thanks for the clarification. That said It wouldn't be very hard to modify SeleniumServerHelper to set this attribute if you don't want to migrate to webdriver just yet. Webdriver isn't yet the most stable of tools though it is better designed than selenium. I'd hold off on upgrading as long as you can and this would be a simple customization that I don't think alone would warrent a webdriver migration.

Let me know if you want help customizing this code.

Mike