Query mainly due to trying to do this using Selenium but I see exactly the same behaviour if I repeat manually so I guess it's a general Chrome question.
So what I'm trying to do is use Chrome with some Selenium tests. Tests happen on a remote machine running 64 bit Ubuntu Linux (running Selenium Server) and are driven from my machine running 64 bit W7 Pro. Scripting is done in Python. Chrome is up to date, Selenium Server is up to date, as is Chromedriver.
The site I'm working on (still in development) uses a lot of AJAX/jQuery calls. It uses basic authentication to log you in.
Using Chrome, if I pass in the login credentials in the URL (as you have to with Selenium it seems) it gets me onto the site OK. Page navigation works OK. But AJAX requests fail as the basic authentication credentials are not added to the header for the request. If I log in via standard URL (manually enter ID + PW) the AJAX requests work OK. I see the same behaviour on Linux and Windows if I try it manually. Using FireFox, it all works OK - the AJAX requests have the authentication header as they're supposed to, regardless how you authenticate. Credentials are carried through correctly throughout. I've checked all the requests using Fiddler and can see the missing header for the Chrome AJAX request when passing in the credentials via the URL.
I did try and use the popup login box instead, but that appears to be a non-starter. Selenium hangs on the initial GET, and until you clear the popup, control is not passed back to the script. So I have no way of sending keys to it. I also tried navigating by using window.location.href = "url" directly, instead of the selenium "get". No luck that way either. And finally, if I reduce the page load timeout, wait for it to fail, and then try and pick up the popup, that doesn't work either. When it times out, the popup is removed.
At this point. I've just about given up. I can't use user profiles as it's a daily changing password (work thing) so theres no point in storing it.
I'm not the developer. I don't know JavaScript terribly well. I've spoken to the lead dev and their response is that this is a Chrome bug and nothing they can fix.
Does anyone concur? Or have a way round this. I'm snookered at the moment because of it ...
If you are facing Basic authentication issues, try authenticateUsing() method.
The Alert Method, authenticateUsing() lets you skip the Http Basic Authentication box.
WebDriverWait wait = new WebDriverWait(driver, 10);
Alert alert = wait.until(ExpectedConditions.alertIsPresent());
alert.authenticateUsing(new UserAndPassword("USERNAME", "PASSWORD"));
PS: Change the syntax for Python bindings
Related
I am trying to automate testing of a web application.
I have recorded the test using JMeter proxy template (JMeter version is 3.2) and couple of times when I ran the test in the JMeter it ran properly but after sometime only some part runs properly.
Following are the steps I am doing:
Hitting the URL
Logging into the application
changing some feature in the application
and so on.
All the steps ran perfectly first few times but then after that only till login everything runs properly.
Just to be sure I tried passing the jsessionid from the first request to the next requests using the Regular "Expression Extractor". I can see in the View Results Tree that jsessionid is passed properly but next page after the step two still takes me into the login screen.
Any help will be very much appreciated.
I have attached screenshot for better understanding:
The response header of logged in page includes a sessionid which is used by another request while logging in.
All the sessionID are properly maintained still after logging in the next page takes me to the login page instead displaying what was done next in the recording.
When it comes to load testing of JSF-based web applications you need to take care at least of the following dynamic parameters:
JSESSIONID
javax.faces.Viewstate
JSESSIONID is a normal HTTP cookie so it is quite enough to add a HTTP Cookie Manager to deal with it
javax.faces.Viewstate is client state management mechanism which also acts as a security token to verify user's origin. So you will need to properly correlate it, i.e. extract from previous response using one of JMeter PostProcessors, store into a JMeter Variable and add as a parameter to the next request. Remember to do this for each and every request.
There might be more application specific dynamic parameters, the easiest way of detecting them is recording the same request (or scenario) 2 times, compare the recorded scripts, detect and work around the differences.
First I'm not in the web side of our world, so be nice with the backend guy.
A quick background : For a personal need I've developped a google chrome extension. They are basically a webpage loaded in a chrome windows and... yeah that's it. Everything is on the client side (scripts, styles, images, etc...) Only the data are coming from a server through ajax calls. A cron job call a php script every hours to generate two files. One, data.json contains the "latest" datas in a json format. Another one hash.json contain the hash of the data. The client chrome application use local storage. If the remote hash differ from the local one, he simply retrieve the data file from the remote server.
As I have a BizSpark account with Azure my first idea was : Azure Web Site with php for the script, a simple homepage and the generated file and the Azure Scheduler for the jobs.
I've developed everything locally and everything is running fine... but once on the azure plateform I get this error
XMLHttpRequest cannot load http://tso-mc-ws.azurewebsites.net/Core/hash.json. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:23415' is therefore not allowed access.
But what I really can't understand is that I'm able (and you'll be too) to get the file with my browser... So I just don't get it... I've also tried based on some post I've found on SO and other site to manipulate the config, add extra headers, nothing seems to be working...
Any idea ?
But what I really can't understand is that I'm able (and you'll be
too) to get the file with my browser... So I just don't get it
So when you type in http://tso-mc-ws.azurewebsites.net/Core/hash.json in your browser's address bar, it is not a cross-domain request. However when you make an AJAX request from an application which is running in a different domain (http://localhost:23415 in your case), that's a cross-domain request and because CORS is not enabled on your website, you get the error.
As far as enabling CORS is concerned, please take a look at this thread: HTTP OPTIONS request on Azure Websites fails due to CORS. I've never worked with PHP/Azure Websites so I may be wrong with this link but hopefully it should point you in the right direction.
Ok, will perhap's be little troll answer but not my point (I'm .net consultant so... nothing against MS).
I pick a linux azure virtual machine, installed apache and php, configure apache, set some rights and define the header for the CROS and configure a cron in +/- 30minutes... As my goal is to get it running the problem is solved, it's running.
In my cross-platform app, I use QNetworkAccessManager to send HTTP requests to my HTTP service that requires authentication. I recently upgraded to QT5, and to my complete surprise on MacOSX my app would send a massive amount of requests to the my service as fast as possible in some scenarios.
After doing some debugging, it turns out that this would only happen when I specify bad auth credentials in my requests. QNetworkAccessManager would indefinitely resend requests to my service if invalid username/password were specified in my HTTP requests.
My code has worked for a long time in previous QT versions, so I decided it has to be something with QT5.
I stumbled upon a following enhancement that was added in QT5: https://bugreports.qt.io/browse/QTBUG-22033
Basically, the idea behind this enhancement os to check keychain for username/password if it intermediate proxy is requiring auth credentials. It turns out this was badly implemented, and this code has been added to the QNetworkAccessManager::authenticationRequired() signal, instead of being added to proxyAuthenticationRequired() signal.
The interesting part about this problem is that I don't set proxy for my application nor QNetworkAccessManager that I use. Which makes this problem so hard to debug!
Because of the bad placement, this "keychain querying" is happening with any authenticationRequired signal. The underlying getProxyAuth() method is calling "SecKeychainFindInternetPassword" with blank hostname which is matching a first "Internet Password" from my keychain and using it to send a request to my service with this new credentials. Imagine my surprise when I saw one of my other/personal passwords being sent to my HTTP service!
Not only this is a security issues, but it cause an infinite loop in your app. I opened a bug with QT about this: https://bugreports.qt.io/browse/QTBUG-30434
Is there a temporary solution? There is! I looked for a workaround to this issue for while. It is a nasty hack. But it works until QT guys get their ducks in a row. This hack works because it ensures that "SecKeychainFindInternetPassword" does not match any entries in the keychain, and therefore skipping that "keychain query".
Basically I am setting proxy hostname to " " instead of "" which will prevent any matching that causes an infite loop in my app.
Workaround:
QNetworkProxy proxy = manager_->proxy();
proxy.setHostName(" ");
manager_->setProxy(proxy);
I hope this is resolved in the next version of QT, so I can remove this horrible hack.
I am trying to implement Google Check out (GCO) on a new server, the process seemed to work fine on the old server.
The error from GCO integration console is the timeout error you might expect if there is load on the server and/or the response takes longer than 3 seconds to respond.
To perform a test (not integrating with my database), I have set some code to send an email to me instead. If I hit the https url manually, I get the email and I can see an output to the screen. If I then leave it as that, Google still returns the Timeout error and I don't get an email. So I have doubts as to whether google is even able to hit the https url.
I did temporarily attempt to use the unsecure url for testing and indeed I received the email, however this solution isn't the route we've developed for, so the problem is something to do with the secure url specifically.
I have looked into the certificate which is a UTN-USERFirst-Hardware which is listed as accepted on http://checkout.google.com/support/sell/bin/answer.py?answer=57856 . I have also tried to temporarily disable the firewall with no joy. Does anyone have any sugestions?
Good to hear you figured out the problem.
I'm adding the links below to add a litle more context for future readers about how Google Checkout uses HTTP Basic Authentication:
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API.html#urls_for_posting
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API.html#https_auth_scheme
http://code.google.com/apis/checkout/developer/Google_Checkout_HTML_API_Notification_API.html#Receiving_and_Processing_Notifications
SCENARIO:
I have a java web app running in the latest Tomcat 6. I also have a single servlet filter that provides authentication. I support BASIC auth and it appears to work fine - most of the time.
The first time a browser [pick any one - IE, FireFox, Opera, Safari, Chrome] hits one of our protected URL(s), it displays the standard browser-specific login prompt. IFF you enter the proper username/password - everything is fine, a new session is created, and everything operates normally.
IF, however, you entered invalid credentials in the initial BASIC auth dialog, my authentication filter logic handles this by returning another 401 response.
PROBLEM:
Unfortunately, at this point, Chrome is the only browser that will display another BASIC auth dialog. All other browsers listed automatically send the cached "Authorization: Basic.." header - instead of clearing it and prompting the user again.
If anyone has seen this or may know why this is happening, I would greatly appreciate any suggestions!
Thanks and Best Regards,
Bob
problem solved:
After looking over my code again, I found a point where a 401 was being returned without also setting the WWW-Authenticate HEADER.
-bob