We test our rails web application with rspec and use the selenium-client (gem version 1.2.18) API in our rspec tests to let selenium RC server (version 2.21.0) steer internet explorer 7 under AP to test our application.
This worked very well until we introduced HTTPS for our login and registration process. Now the user is redirected to the secure version of the login and registration form and afterwards redirected back to the unsecure HTTP site.
For our selenium tests to work with HTTPS and internet explorer 7 we are setting up the selenium driver with "*iexploreproxy" instead of "*iexplore" and use port 4444. We also installed the CyberVillans SSL Certificate as describe here http://blog.mogotest.com/2010/04/13/how-to-accept-self-signed-ssl-certificates-in-selenium/. We run selenium rc server with -trustALLSSLCertificates. This solved the self signed SSL Certificate issues (be aware that selenium RC > 2.21 does not work because of a bug which sets a wrong valid from date).
After that we received "Permission Denied" errors, when running our tests. We found out that this is because of the same origin problem described at http://wiki.openqa.org/display/SEL/Selenium+Core+FAQ under "Why do I get a Permission Denied error when accessing my website via HTTPS?". This problem can be solved by adjusting internet explorers 7 proxy settings and using localhost:4444 to route everything through the selenium RC server. It works, but the problem is that after every test run the proxy settings are reset.
My first question is: How is it possible to make those settings persistent in the internet explorer 7? I read about custom profiles for IE but I haven't found out how to set this up for rspec tests. I also read about a proxy.pac file, but googling for solution without success.
The next problem is that when running our tests we also run into "Access denied" errors by selenium. I have no idea how to solve these and why they occur. So my second question is: How do I get rid of those under the setup described.
Related
Im trying to access a url and run tests which specifically needs client certificate .client certificate is installed in my system and even though if I have multiple certs I’m able to select the one needed for the url and run the tests using selenium automation perfectly in normal mode but when I’m trying to run tests In headless mode it is unable to detect the cert which is installed in my system . Not sure what is the issue but is there any way I could resolve this issue.
I am getting this error “org.openqa.selenium.WebDriverException:unknown error:net :: ERR_SSL_PROTOCOL_ERROR”
Note :
I have tried “AutoselectcertificateforUrls “ As well but it didn’t work I don’t see any configuration settings for chrome
And also I don’t have permissions to download cert in .p12 format
Im running chrome headless through chromedriver and selenium via python.
I've run into the following issue both on Mac and Linux.
Im starting chrome as follows:
if self.headless:
options.headless = True
options.add_argument("--headless")
if self.debug_port:
logging.info(f"Setting up remote debugging on port {self.debug_port}")
options.add_argument(f"--remote-debugging-port={self.debug_port}")
options.add_argument(f"--remote-debugging-address=0.0.0.0")
If I connect to http://localhost:9222 from another headed instance of chrome I can see the list of sessions and connect to it seamlessly. At which point i have a window opened up with a screencast of the remote session and the dev console.
Here's that successful example:
When I connect to http://192.168.1.194:9222 I get the list of sessions just fine and upon selecting one the dev console opens but it doesn't start the websocket connection to ws://192.168.1.194 so the screencast and remote debugging capabilities are not available.
Here's that failed example:
I've captured har files and uploaded them here if you want to take a look
Using the following steps I was able to debug remotely. However the screencast functionality did not work. Ultimately that's what I needed so this is only a 50% solution in my case.
So, as noted above in the comments, what's blocking remote debugging from working is that the chrome debugger links out to https://chrome-devtools-frontend.appspot.com/..... and passes a value of ws://192.168.1.194 for the websocket parameter. Any browser will inherently block this, based on it being mixed content - i.e: https + ws
What's needed here is to run the chrome dev tools frontend on a http server
and direct your chrome instance to that server instead of the appspot instance.
Solution Steps
1 Install depot_tools (pre-requisite for building)
https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up
2 Checkout the devtools-frontend repo
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#checking-out-source
3 Build chrome devtools frontend
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#build
4 Start the devtools-frontend http server
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#running-in-hosted-mode
5 Run 2 instances of chrome and use one to debug the other
5.1 Start first instance of chrome headless
...with remote debugging enabled. See the python way in the question above or do it from the command line with the same arguments
5.2 Start a second instance of chrome
...using a different user data dir --user-data-dir=<some-path>
5.3 Navigate to http://192.168.1.194:9222
Use whatever the IP address of the first chrome instance is and the port that you chose.
5.4 Create a link to the local dev server
The 2nd instance of chrome will now be showing you links to debug each of the open tabs of the 1st instance. However the links will still to go https://chrome-devtools-frontend.appspot.com/..... You'll need to copy n paste the link you want and replace the hostname with the hostname of the devtools frontend that you started in step 4
Walla!!
If you figure out how to get the screencast working please comment below! 🙏
N.B:
I also tried using the npm run server command in the devtools frontend but for some reason that server didn't work at all ¯\_(ツ)_/¯
I have enabled SSL for a site using jdk 1.8 and Tomcat 8.5.23.
When I hit the site in IE, first time it shows:
"Can't connect securely to this page
This might be because the site uses outdated or unsafe TLS security settings. If this keeps happening,try contacting website's owner."
When I hit the site second time, the page loads and the application functionality works fine with SSL enabled.
When I hit the site in chrome no matter how many times, it shows:
"This site can't provide a secure connection
Abcd.xyz.com didn't accept your login certificate, or one may not have been provided.
Try contacting the system admin.
ERR_BAD_SSL_CLIENT_AUTH_CERT"
In server.xml I have added below in the connector tag:
SSLProtocol="TLSv1+TLSv1.1+TLSv1.2"
I also could not find any error in the log files.
Please help me. :(
I am using browserstack to test some devices, like IE. However I need to set up local testing so I can test my site localhost:3000
I have logged in to browserstack in Chrome and installed the extension. I click on the extension IE11 link. It takes me to a IE11 on Windows 8 virtual machine.
I type localhost:3000 into IE but it doesn't seem to work.
Then I click the Settings cog and click resolve all URLs through my network.
Still it doesn't seem to work for me.
Looks like the setup was fine in Browserstack, I just forgot that in IE11 I need to use http://localhost:3000 as it doesn't automatically resolve the protocol http silly mistake :)
Well this is odd. As of this morning, Chrome is responding with ERR_CONNECTION_REFUSED when it attempts to connect to web pages at various {subdomain}.localhost domains. Firefox and Safari both connect as normal. I am using Vagrant/Virtualbox running Debian and Apache. Chrome does connect to local domains which ARE NOT using localhost in the domain name. Wondering if chrome released some sort of local firewall?? But not seeing anything about that in release notes.
UPDATE: running curl {subdomain}.localhost in terminal gives me the output as expected (response from web server).
UPDATE 2: I did just find this: https://news.ycombinator.com/item?id=9210484 (Chrome team planning to block all access from browser to localhost wss) -- but I do not see that this was implemented yet.
The answer is in my second update. No more .localhost.
you can try using the port explicitly -> xxx.localhost:8080