OK, this one’s been driving me nuts, mostly because it took the “automated” part out of automated testing, which basically defeats the purpose. If I can’t run an automated test, I am much more prone to avoid running them, and therefore not test, and therefore introduce bugs.
The Problem:
The problem is with self-signed certs. If you are working on something locally and it uses SSL (HTTPS), normally you’ll just create your own cert and forget about it. The problem is that when you run Selenium RC (with Firefox/chrome) it’ll fire up a browser and when it reaches this secured page, it’ll throw an exception. The exception is in an unscriptable window (AFAICT) and you wouldn’t want to code around the window in the test b/c it probably won’t happen on your staging or production servers. Normally with Firefox, you can simply add an exception, which gets written to a file called ‘cert_overrides.txt’, and forever going forward you won’t need to worry about it. Again, the problem is that because Selenium fires up a fresh profile each time you run it, you can’t simply add this exception anywhere. You’d think adding the ‘-trustAllSSLCertificates’ flag to the command line when you start the Selenium Server would work, but it doesn’t. I think the problem I’m having is not an expired or invalid cert, but that it’s self-signed and the CA is not trusted. (Whatever, all I know is that it doesn’t work).
The Answer:
Well, at first glance, it seemed like I could just make a blank Firefox profile, by firing it up from the command line and saving a new profile. The problem with this is that the new profile won’t have all of the Selenium proxy stuff configured. In fact, there’s seems to be a whole buncha stuff missing from the profiles, so I don’t recommend doing this. If you really want to know how to create a blank Firefox profile. Open a Terminal and type:
/Applications/Firefox.app/Contents/MacOS/firefox-bin -profilemanager
Once you’ve followed all the prompts, a new profile will be created in: ~/Library/Application Support/Firefox/Profiles
But anyhow, you want to know how to make it WORK not how it doesn’t work! This is what I did and it seemed to work. First create a Selenium test with one step that is basically a really long wait. I use Python so I have this step in my test:
def test_WAIT(self):
sel = self.selenium
sel.open("/")
sel.wait_for_pop_up('xxx', 999999)
This bascially gives you time to do the next step. OK, so now in your Terminal, open the /tmp folder in a regular Finder window by typing: open /tmp - Now, fire up the Selenium Server, and run the test. While the test is basically just hanging, you’ll see there’s a new folder in /tmp called something like: customProfileDir0ad7f0b886b7499bbf53d2ee5f4dc3dd. Drag this folder somewhere (like your Desktop), you should be asked to authenticate. Once you’ve copied the folder to your desktop (or wherever), you can use it as an alternate profile for firing the Selenium Server. I renamed the folder ‘SeleniumProfile’ and added the ‘cert_overrides.txt’ file to the folder (with the overridden cert information in it. If you override a cert in your normal profile, you can just copy it out of that file). Now you can use this fully prepared and ready Firefox profile with Selenium Server by running:
java -jar selenium-server.jar -firefoxProfileTemplate ~/Desktop/SeleniumProfile
To me, this was the simplest path to getting going.
My suggestions:
If it were up to me, I woul ddo one of a few things:
- Make the -’trustAllSSLCertificates’ flag actually work.
- Make it such that when the Selenium Server fires up and copies the files out of the Firefox default profile (found in /Applications/Firefox.app/Contents/MacOS/defaults/profiles ), it should copy ALL of the files in that folder, rather than just localstore.rdf and a few others. This way you could drop your cert_overrides.txt file in there and go on your way
- Include a fully formed “blank” profile with the distribution of Selenium RC to use or modify.
Other than that, I continue to use and love Selenium. I hope this article helps and gives folks who are doing the development some ideas to make things better for the users. I see a lot of these problems not properly answered in the forums and will be posting this blog link in there.
~Spanky
December 30th, 2008 - 15:22
Looking at the code, it seems you do not have to provide a complete Firefox profile - bits and pieces should work just fine, as they are copied into a directory that is a complete profile in and of itself. Thus, creating a directory only containing the file cert_override.txt and specifying that using -firefoxProfileTemplate should work.
Haw-Bin
January 4th, 2009 - 03:00
Please try RCE.xpi for Firefox3 https://addons.mozilla.org/en-US/firefox/addon/10246
I create it for auto-bypass bad cert exceptions in Selenium-IDE on FF3.
January 5th, 2009 - 10:09
That’s great Jerry. The only problem (again) is getting this plugin into the base profile loaded by Selenium RC? Same problem, see? I guess you could add the plugin to the default profile.
January 5th, 2009 - 14:47
I was able to get it into the Selenium profile by running firefox in the profile manager mode
firefox -ProfileManager
If all your firefox browsers are closed you’ll be able to select which profile you would like to run. I ran my SeleniumTest profile and was able to load the plugin.
With that said, I was also able to just install the self signed cert in the SeleniumTest profile and not have to install the RCE.xpi
January 17th, 2009 - 07:47
(This is a duplicate of a post I just sent to the Selenium forums)
The plugin Jerry referenced can definitely do the job, and we should really just get that embedded in the next rev of Selenium RC. That way you don’t have to do any tricky stuff to inject it in to the base profile that Selenium creates.
I built the underlying code for the -trustAllSSLCertificates flag. This was designed to solve cert issues for when proxy injection mode was being used. My guess for why it wasn’t working is two-fold:
1) If you’re using “chrome” mode (which is the default since 1.0 beta 2), the browser does not get configured to use a proxy. Try keeping the flag on, but then open up the launched browser and configure it to use localhost:4444 as a proxy. Then try hitting the site - it should work.
2) If it doesn’t work in step #1, that is most likely because of a bug I fixed just yesterday, which makes the flag even more trustworthy. You can check by grabbing a latest snapshot and see if the step in #1 works.
If that works, then you’ll need to pass in the proper flags to make Firefox launch such that it uses chrome mode (which is definitely the best option for Firefox) but still uses the local proxy simply for bypassing SSL stuff. Unfortunately, I believe that this isn’t doable with the current launches, which is why I created a custom launcher for my load testing service.
I hope this makes sense. In short: we did try solving this issue, but overlooked solving it for the mode you are using, which is now the default mode. As such, we need a better solution for you and everyone else. Expect some improvements by 1.0 final or shortly thereafter.
In the meantime, you can try rigging up the solution I mentioned (chrome + proxy everything) or you can try providing a base Firefox profile via the command lines (SRC supports this) and getting Jerry’s plugin mixed in that way.
Patrick
January 18th, 2009 - 00:03
Hi Spanky,
I open a discussion on community.
http://clearspace.openqa.org/message/55135
Please give your comments.
March 8th, 2009 - 15:19
kapanka.com - cool sitename man)))
————————
signature: http://cigace.ru/
March 9th, 2009 - 15:18
cooooolest domain name)))
————————
sponsored link: http://werato.ru/
March 10th, 2009 - 11:29
…forgot to mention that I also had to move the file
cert_override.txtfrom the custom Firefox profile toselenium-server.jar::customProfileDirCUSTFF\cert_override.txtand
selenium-server.jar::customProfileDirCUSTFF\cert_override.txt