I exported a working Selenium test case to Java, running it via selenium-rc's selenium-server.jar in Junit4 on Eclipse.
The test case breaks the next step after opening the page, trying to write to an element. When stepping through the runtime I noticed the error,
The requested URL could not be retrieved
The following error was encountered:
Unable to determine IP address from host name for unknown server name
This means that: The cache was not able to resolve the hostname presented in the URL. Check if the address is correct.
So, I changed the url to the corresponding IP address of the web page, but now I am timing out.
Opening the page using both the url and IP formats manually is working, (except IP doesn't for IE8). I'm originally targeting Firefox, but will expand to other browsers once I have solved this issue.
Is there a security issue involved with Selenium opening a page in a browser via RC programatically that browsers don't like? What sort of issues should I be investigating to solve this?
I think you are trying to open a secure page.In selenium pages which has ssl certificates should be handled.
The problem actually came down to the proxy set up on my machine. After removing it things worked fine.
Related
In my Selenium Tests I need to test a webpage where I use a basic Authen,
Knowing that I am using Chrome Headless Java and Selenium WebDriver.
On my machine 'locally' It works perfectly using driver.get("https://admin:admin#localhost..");
and then
driver.get("https://localhost..") for example.
I know that Chrome doesn't support this function anymore but I managed to make it work based on someone's solution here by passing the first URL with credentials and the second without.
But when I run it on remote (Jenkins) On Linux servers I get the following Error
the configuration of your browser does not accept cookies
. I don't have vision on the servers when I can configure Chrome ..any ideas how to make it work without facing that problem.
I know a lot of people asked that question before, But I didn't find any valide answer for my issue.
try ChromeDriver 2.45 (changelog) or change the location, where it is supposed to save the cookies:
ChromeOptions options = new ChromeOptions();
options.addArguments("user-data-dir=/path/to/your/custom/profile");
otherwise (per default) it would create a new temporary directory each time it starts a session.
ChromeOptions options = new ChromeOptions();
//Command line flag for enabling account consistency. The default mode is disabled.
options.addArguments("--account-consistency");
//Chrome that will start logging to a file from startup
options.addArguments("--log-net-log=C:/some_path/resource/log.json");
//Sets the granularity of events to capture in the network log.
options.addArguments("--net-log-capture-mode=IncludeCookiesAndCredentials");
Try this, basically, it saves the logs on startup of chrome browser, then it will set the account consistency. Anywhere from the log, you can debug the issue.
Hello I managed to fix the problem (I forgot to mention that our website is protected by Siteminder) so I did the following following:
1-We inject the USER and the PASSWORD on the URL :
The issue we faced was that the displayed prompt wasn’t part of the page’s HTML and it was hard for us to catch it using Selenium. We managed this by directly injecting the user login and the user password in the URL as follow :
‘https://USERNAME:PASSWORD#basicAuthentURL’
This will launch the Chrome session. Beware, this is only the first step of the process. The user identification have not been performed yet.
2- We create a new cookie :
After launching the URL, we have to manually create a cookie called « SMCHALLENGE » and add it to current session with Selenium, for example in JAVA :
new Cookie("SMCHALLENGE", "YES");
3- Call the URL without the user credencials :
As the SMCHALLENGE cookie is now set, the last step is to call the URL again (https://basicAuthentURL ). The SMCHALLENGE cookie will be deleted once the authentication succeed and a SMSESSION cookie will be generated by Siteminder.
The SMSESSION cookie now allows us to call the application and sucessfully pass Siteminder as if normally logged in (via SSO).
Let me know if you try this out.
I m using Selenium IE Webdriver.I want to delete "This is the initial page of webdriver server." from IEDriverServer.exe file of Selenium IE Webdriver. I opened the IEDriverServer.exe file in notepad++ and deleted that line from it and again add it in my classpath.But then i get this error:
org.openqa.selenium.remote.UnreachableBrowserException: Could not start a new session. Possible causes are invalid address of the remote server or browser start-up failure.
How can we do that.Please someone tell me.
You can't just edit an executable file like that. You have undoubtedly ruined the executable and now should redownload it from the Selenium site.
Regardless, this is expected behaviour. The IEDriver must have somewhere to go to begin with.
There is a setting that configures this URL called InitialBrowserURL. If this is not configured in your code, then the default is used.
Configure this to what you want. Most cases it can be configured to just go to the home page of your application.
I'm trying to load my app in development mode using Chrome v. 20.0 on my local ip 127.0.0.1.
The app fails to load, and the following is displayed:
message:
"GWT Code Server Disconnected
Most likely, you closed GWT Development Mode. Or, you might have lost network connectivity. To fix this, try restarting GWT Development Mode and REFRESH this page."
on top of the previous message (overlaid):
"Plugin failed to connect to Development Mode server at 127.0.0.1:9997
Follow the underlying troubleshooting instructions"
This started to happen about 6-9 months ago and after 1 or 2 page refresh, the module loaded correctly. Now, i cannot load my app in dev-mode at all using Chrome. (in firefox
everything is ok).
I'm using GWT 2.4
UPDATE:
Those errors are not accompanied by any code stack trace output. Usually, if I changed the address form 127.0.0.1 to localhost, the module loaded, but this doesn't work any more...
Had the same problem. Deleting / reinstalling the plugin did the trick for me.
Check Automatically select an unused port of GWT from Run configuration.
My similar problem solved by this
I solved this in chrome by:
go to chrome://extensions/
locate GWT Developer Plugin
uncheck the Enabled box
check the Enabled box
Have a look at http://code.google.com/p/google-web-toolkit/wiki/TroubleshootingOOPHM
This page is supposed to be displayed in an iframe below the message (hence the message "underlying instructions", but Google has changed some server code on code.google.com and they now prohibit display within iframes, which is why it actually doesn't display.
FYI, the issue has been reported on GWT's issue tracker http://code.google.com/p/google-web-toolkit/issues/detail?id=7301
Your problem might be caused by improper gwt plugin setup. Go to your gwt developer plugin options (red toolbox right upper conner) in chrome and add your web and code server addresses. That worked for me.
Allowing "localhost" as webserver and code server made it work for me (although 127.0.0.1 was specified for both in the browser)
Our company running Liferay without virtual host. We using VM IP with port 80 open for our portal. No any problems with this setup.
When I'm added virtual host to Liferay and changed DNS on my machine -- I can't opened any assets (articles) with long russian names.
Tomcat console:
WARN [404_jsp:109] /home/-/asset_publisher/JbL5ejmhvwSa/content/%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F-%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%BF%D1%80%D0%BE%D0%BA%D0%BE%D0%BC-%D0%BF%D0%BE-%D0%BE%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8-%D1%80%D0%B0%D0%B1%D0%BE%D1%87%D0%B5%D0%B3%D0%BE-%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8-%D1%81%D0%BE%D1%82%D1%80%D1%83%D0%B4%D0%BD%D0%B8%D0%BA%D0%BE%D0%B2-%D0%BD%D0%B0-%D0%B1%D0%B0%D0%B7%D0%B5-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2-ibm
Virtual host enabled URL (not working)
http://companyname.com/home/-/asset_publisher/JbL5ejmhvwSa/content/%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F-%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%BF%D1%80%D0%BE%D0%BA%D0%BE%D0%BC-%D0%BF%D0%BE-%D0%BE%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8-%D1%80%D0%B0%D0%B1%D0%BE%D1%87%D0%B5%D0%B3%D0%BE-%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8-%D1%81%D0%BE%D1%82%D1%80%D1%83%D0%B4%D0%BD%D0%B8%D0%BA%D0%BE%D0%B2-%D0%BD%D0%B0-%D0%B1%D0%B0%D0%B7%D0%B5-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2-ibm?redirect=http%3A%2F%2Finterprocom.ru%2Fhome%3Fp_p_id%3D101_INSTANCE_JbL5ejmhvwSa%26p_p_lifecycle%3D0%26p_p_state%3Dnormal%26p_p_mode%3Dview%26p_p_col_id%3Dcolumn-2%26p_p_col_pos%3D1%26p_p_col_count%3D2
Virtual host disabled URL (working)
http://192.168.10.35/web/guest/home/-/asset_publisher/JbL5ejmhvwSa/content/%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F-%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%BF%D1%80%D0%BE%D0%BA%D0%BE%D0%BC-%D0%BF%D0%BE-%D0%BE%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8-%D1%80%D0%B0%D0%B1%D0%BE%D1%87%D0%B5%D0%B3%D0%BE-%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8-%D1%81%D0%BE%D1%82%D1%80%D1%83%D0%B4%D0%BD%D0%B8%D0%BA%D0%BE%D0%B2-%D0%BD%D0%B0-%D0%B1%D0%B0%D0%B7%D0%B5-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2-ibm?redirect=http%3A%2F%2F192.168.10.45%2Fweb%2Fguest%2Fhome%3Fp_p_id%3D101_INSTANCE_JbL5ejmhvwSa%26p_p_lifecycle%3D0%26p_p_state%3Dnormal%26p_p_mode%3Dview%26p_p_col_id%3Dcolumn-2%26p_p_col_pos%3D1%26p_p_col_count%3D2
It's few days until we go public. We'll use our domain companyname.com
I'm worried that we will got same issue.
Without being able to immediately solve the underlying problem: You can also use the last option with the host name: No virtual host names, just have the name resolve to 192.168.10.35 (change to an actual IP when going live).
Also, what version of Liferay are you on?
see this Question, my be it help you: Liferay: After changing Public Virtual Host settings, can't log in
Also you can see in generated jsp code tomcat/work/... why this do not work.
And at last, you can debug Liferay and find the solution :) The simple way to debug Liferay is to get Liferay IDE and add Liferay Source as eclipse project. Good luck.
Even I face this issue and observed that with liferay's virtual host mapping, url's with special characters are not showing up when they are related to entries in Guest site.
By mapping virtual host, web/guest part is removed from the URL.
Now if you try manually adding web/guest before the URL, In your case
try accessing with following URL
http://companyname.com/web/guest/home/-/asset_publisher/JbL5ejmhvwSa/content/%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F-%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%BF%D1%80%D0%BE%D0%BA%D0%BE%D0%BC-%D0%BF%D0%BE-%D0%BE%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8-%D1%80%D0%B0%D0%B1%D0%BE%D1%87%D0%B5%D0%B3%D0%BE-%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8-%D1%81%D0%BE%D1%82%D1%80%D1%83%D0%B4%D0%BD%D0%B8%D0%BA%D0%BE%D0%B2-%D0%BD%D0%B0-%D0%B1%D0%B0%D0%B7%D0%B5-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2-ibm?redirect=http%3A%2F%2Finterprocom.ru%2Fhome%3Fp_p_id%3D101_INSTANCE_JbL5ejmhvwSa%26p_p_lifecycle%3D0%26p_p_state%3Dnormal%26p_p_mode%3Dview%26p_p_col_id%3Dcolumn-2%26p_p_col_pos%3D1%26p_p_col_count%3D2
and it should work.
So one possible way to resolve this issue is to keep virtual host
mapping in your windows/your os hosts file and rename virtual host to
localhost in Liferay in portal settings under Portal tab in control
panel.
STEPS:
1) In hosts file keep the mapping as you have done i.e
192.168.10.35 companyname.com
2) In liferay, remove the virtual host mapping i.e rename virtual host to localhost in "portal settings" under "Portal" tab in control panel.
and try to access your entry and it will work.
This is very interesting behavior/ may be a bug in liferay.
Hope this helps.
So you testing Liferay on your local host, then trying to move on real domain and facing some weird behaviour.
First thing you want to do is to check Control Panel and type in your new virtual host there.
I'm not sure about this because we are using 6.0 now and I did not remember how exactly we fixed it. If my advice did not helped please check other comments to this question.
I'm following Scott Davis' tutorials on developing grails apps, but whenever i try to run my app (or indeed his source code) i get "Firefox has detected that the server is redirecting the request for this address in a way that will never complete." Safari gives a similar error message as does Opera.
As i've tested the original authors source code which gives the same error i'm fairly confident it's nothing to do with the code.
Is this a problem with the web server on my machine? I use Mac OS Snow Leopard so i'm assuming it's apache that's generating this error.
Edit: Seems Grails as standard uses Jetty, so probably not Apache that is causing the problem. However also tested the app on Glassfish and i get the same error.
Anyone know what i can do to fix this?
Cheers
It depends on the code and Apache configuration you are using. I assume that the web server sends cyclic HTTP redirections, eg. from /root/ to /root (without the slash) and vice versa. This causes a redirection infinite loop.
Check your configuration on conditions that cause a HTTP redirect. For example, Apache automatically adds slashes to directory URLs in standard configuration (like the /root/ example above). I don't know Grails, so I cannot give you a hint on how URLs are processed within the app.
You can also use manual HTTP requests for debugging to see whats going on behind the scenes, using telnet on a terminal:
$ telnet localhost 80
GET / HTTP/1.0
I guess the response will be something like that:
HTTP/1.0 302 Found
Location: XXX
...
Now do a second request on the URL passed in the Location header and so on.
I was getting the same error a little while ago, heres how I fixed:
Try the same page on a different internet setup (it could be your ISP)
Open up Safari, Firefox or whatever your using and empty the cache and delete ALL your cookies
Reboot your computer and try again
It may work now, but if it doesn't:
open up Firefox and type 'about:config' (without the quotes) into the URL bar
You will get some little warning, just press OK
Type 'redirect' into the Filter box
You should see a listing for 'network.http.redirection-limit'
Double click the listing and type a large number (anything above 50 and lower than 200)
Press OK, quit and re-open FireFox
Basically all that does is make FireFox's tolerance for redirect loops higher which should fix your problem - but usually, just borrowing someone else's internet connection fixes it
Hope that all helps =)
Just carefully check your URLMappings configuration:
YOUR_APP/grails-app/conf/UrlMappings.groovy
Common case:
You configured request to be handled like this:
"/anything" (controller:"someController")
So without action, request will be handled by default one, "index". "index" action usually redirects to "list", and "list", in some cases redirect back to "index"
There is your loop.
Good luck