I'm trying protractor to write a few tests in a non angular application. I have to login in a page trough basic authentication in google chrome, but i have no idea how.
I already tried baseUrl: 'https://username:password#url' and capabilities: {
'browserName': 'chrome',
'chromeOptions' : {
args: ['--login-user=foo', '--login-password=bar']
}
}
But none if these worked for me. Anyone knows how to do it? I'm having some hard time on it.
You can set the URL as http://username:password#yourdomain.example. Chrome will handle it!
The short answer is there is no easy way of doing it on chrome because they do not support modifying request headers -- see https://code.google.com/p/selenium/issues/detail?id=141 (title says response headers, but if you read it, it's for all headers).
That being said, there are ways to do it, albeit difficult.
1) Find a chrome extension/plugin that allows you to modify header. A simple search bring up many of them: https://chrome.google.com/webstore/search/modify%20header. You'll need to add the plugin to webdriver: see Is it possible to add a plugin to chromedriver under a protractor test?.
2) You can use browsermob-proxy (https://github.com/lightbody/browsermob-proxy); this way you route your traffic through the proxy, which would add the headers for you.
From the docs:
POST /proxy/[port]/auth/basic/[domain] - Sets automatic basic authentication for the specified domain
Payload data should be json encoded username and password name/value pairs (ex: {"username": "myUsername", "password": "myPassword"}
There's a node project that may help you, https://github.com/zzo/browsermob-node, but you would still need to set up your proxy server yourself.
Both ways for chrome are complex, but would get you what you want. (or you can stick with firefox and follow Robert's answer)
As of version 59 Chrome no longer supports URLs with embedded credentials.
To work around this I wrote the authenticator-browser-extension Node module, which might be useful if you're using Protractor, WebDriver.io or similar test runners.
To use the module install it from npm:
npm install --save-dev authenticator-browser-extension
And import in the protractor.conf.js:
const { Authenticator } = require('authenticator-browser-extension');
exports.config = {
capabilities: {
browserName: 'chrome',
chromeOptions: {
extensions: [
Authenticator.for('username', 'password').asBase64()
]
}
},
}
Pro tip: remember not to commit your credentials with your code, consider using env variables instead.
Hope this helps!
Jan
It's because Firefox doesn't trust any site by default with sending the Windows auth info over. Even if you change it in the configurations manually, it won't affect protractor because it opens Firefox with an isolated configuration each time you run your end to end tests.
You'll need to programatically set up a Firefox profile and set its preferences such that it would trust localhost (or some other website, depending where the pages are loaded from)
First, check out this example. It shows how you can set up the profile and how you can set preferences.
https://github.com/juliemr/protractor-demo/tree/master/howtos/setFirefoxProfile
What it does is that it modifies the homepage for each new tab. In the same manner (with the firefoxProfile.setPreference method) you can change the preferences responsible for trusting websites. They're called "network.automatic-ntlm-auth.trusted-uris" and "network.negotiate-auth.delegation-uris". You'll need to set them both to "localhost". (Again, if they're at some other place, it's obviously that URL)
hankduan's browsermob-proxy solution worked for me on Chrome - but the latest revisions of browsermob are using a thing called littleproxy which does not support auth headers. Thusly I had to do browsermob-proxy -port 9090 --use-littleproxy false, which got things working.
You may use Windows Credentials Manager to avoid this pop-up being constantly shown on every attempt to log in.
Add your credentials to the 'Generic' category there, restart browser (including background apps running).
Some explanation I currently have: this pop-up is not 'browser' specific, it is 'in the middle', between browser and domain credentials verification. Thus browser features (save password, autofill) do not work completely. By the same reason Protractor / Selenium etc. do not have complete control over that pop-up - it is by design of the domain authentication.
As not completely sure if it is the only reason there are some other hints:
- you may also need to add your site to the IE (IE, not Chrome) list of trusted sites (Chrome grabs information from there);
- check "Automatic logon with current user name and password" in IE (not Chrome) - may not work if credentials you are using for the site are different from those you use to login to the machine.
If you're reading this in 2019, with Angular 7/8, consider this:
https://www.npmjs.com/package/authenticator-browser-extension
I find it much easier than the solutions suggested above.
Related
I have the following test that needs to verify that clicking a link downloads a PDF. This is especially important as we are using Gatsby, which in turn uses Reach Router's Link Component, and it is relatively easy to misconfigure things so that the router takes over the link and navigates to a 404 page instead of initiating a download.
describe.skip(`Downloads`, () => {
it(`Downloads the expected file`, () => {
cy.visit(pagePath)
cy.getByHref(downloadPath)
.should(`have.attr`, `target`, `_blank`)
.click()
cy.location(`pathname`).should(`eq`, pagePath)
})
})
While this isn't perfect, it does at least check that there is no navigation as a result of clicking the link.
The problem is that when running this test using cy run, which runs the tests in Chrome, the test hangs, due to Chrome's download dialogue.
How can I prevent the test from hanging?
Note that the downloadPath resolves to a pdf in the static directory, for example /static/example.pdf. There is no server component.
Also note that this is a different question to: How can I use Cypress.io to assert that a file download has been initiated without actually downloading?
Actually I searched alot about it and found that
It is not possible to run tests in headless mode with browser extensions installed, because the only supported browser in headless mode is Electron, and Electron doesn't support extensions as stated in the documentation.
Running headless Chrome is not supported yet. See this issue: #488
https://github.com/cypress-io/cypress/issues/488
And this is a an issue not so old it was tagged in Feb 2019
https://github.com/cypress-io/cypress/issues/832
https://github.com/cypress-io/cypress/issues/1235
There are a lot of ways to test this, so it depends. You’ll need to be aware of what actually causes the download, then think of a way to test that mechanism.
If your server sends specific disposition headers which cause a browser to prompt for download, you can figure out what URL this request is made to, and use cy.request() to hit that directly. Then you can test that the server send the right response headers.
If it’s an anchor that initiates the download, you could test that it has the right href property. As long as you can verify that clicking the button is going to make the right HTTP request, there’s nothing else to test for.
In the end, it’s up to you to know your implementation and to test enough to cover everything.
You can prevent the test from hanging by disabling the dialog asking where to save the file. Once you do that chrome will happily download your file and Cypress can continue running your test.
In chrome go to settings->Advanced->Downloads->Ask where to save each file before downloading and make sure it is off.
There are more complicated solutions in the links Apolo provided but this is a quick workaround.
I do cross-origin, cross-frame scripting in one of my projects (end to end testing with client side js without selenium) and that project highly relies on the --disable-web-security flag. From today one of my tests is failing. It tries to load a non-existent remote URI to a child window to check whether an error is thrown by the lib. Well I got an error, but that is a security error, so not what I expect. The other tests are between the karma server on localhost:9876 and a node server on localhost:4444. Those are working properly. My karma contains a Chrome custom launcher with the flag:
customLaunchers: {
"ch": {
"base": "Chrome",
"flags": ["--disable-web-security"]
}
},
As far as I know it needs some sort of user dir too, but the Karma launcher fills that param. Any idea about whether I can fix this or at least what release of Chrome changed the behavior? (I have already sent a bug report.)
Note that the question has nothing to do with Karma. All it does is starting Chrome from CLI with the given flags. A possible fix would be adding another flag, like the --user-data-dir was, but I guess the current changes are intentional and they cannot be undone. I'd like to see where this was discussed. I only found a 5 years old topic in Chromium Google Gorups which discusses this: https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/iivpdszNY3I/3o3BF_mGwlIJ
Using --disable-site-isolation-trials is a partial solution. It works on https://www.google.com, but does not work on Chrome error pages with the error:// protocol.
I'm building a website using WordPress as a backend, and AngularJS as the frontend. I'm using the WordPress JSON API to get my data to the front-end.
https://wordpress.org/plugins/json-api/
The problem
I'm using AngularJS to get my data from the WordPress JSON API. I have created the following service:
this.getPage = function ( slug ) {
return $http.get('wordpress/api/get_page/?slug=' + slug)
}
I use this service in my controller to get the current page like this:
HTTPService.getPage('home')
.success(function ( data ) {
$scope.page = data.page;
console.log(arguments);
})
.error( function () {
console.log(arguments);
})
This is working fine in all browsers, except for Safari on iOS. On Safari on iOS I get the following response when I log the error arguments:
This is the safari debugger which showed when I connected my iPhone to my Mac. The error response which I get is error code 0..
What I have tried so far
I have set Access-Control-Allow-Origin "*" in the .htaccess file, but this doesn't seem to work. The request is done on the same domain with a relative URL, so I don't think that this is the problem.
So, does anyone know why this is not working on Safari (iOS)?
EDIT
Some extra information as requested:
I'm pretty sure that this is due to the fact that Safari is the only browser that has the policy of blocking "3rd party cookies and other website data" by default. Actually, this issue shouldn't be exclusive of Safari iOS, it should also happen with Safari on your OSX. I'm pretty sure that if it's not happening in your MacBook is because one day you changed the default settings of the "Privacy".
You can try this, open Safari, go to "preferences" and under the tab "Pricacy" check if you have the option: "Block cookies and other website data" set to "From third parties and advertisers". This is the first, and the default option in the modern versions of Safari.
In your MacBook it will look like this:
And in iOS it will look like this:
Just to confirm that this is in fact what's causing your issue: change this setting to "Never", clear the cache and try to reproduce that problem again. I'm quite confident that you won't be able to reproduce it.
Now, if you set it back to "Block cookies and other website data: From third parties and advertisers" and you first clear the cache, you will have that problem again (with either iOS or OSX). After you've confirmed that this is the cause of your problem, set this setting back to "From third parties and advertisers", so that you can reproduce and address the problem with the default settings.
Bare in mind that every time that you want to re-test this issue you will be better off clearing the cache of Safary. Otherwise it could happen that Safari decides that the site serving the API can be trusted and you won't be able to reproduce the issue. So, just to be sure, clear the cache every time that you test this.
I believe that the root of this problem is that Safari wants to make sure that the user has had a direct interaction with the page that it's serving the "3rd party content" before the main page loads that content.
I would need to know more about your project in order to suggest an "optimal" solution. For instance: will the final app be integrated under the same domain as the API? Because if that's the case, you shouldn't have that issue when you go to production. I mean, if the app that you are developing will be hosted under: http://whatever.yourDomain.org and the API is going to be part of that same domain (yourDomain.org), then you shouldn't have that issue at all in production.
On the other hand, if you need to have have the API hosted under a different domain, then you will have to find a way to "trick" Safari. Have a look at this:
Safari 3rd party cookie iframe trick no longer working?
And this:
http://www.allannienhuis.com/archives/2013/11/03/blocked-3rd-party-session-cookies-in-iframes/
I hope that this helps.
I've spent a good few hours trying to crack this myself, having analysed a bunch of other people's work (this is the latest one I've tried to hack Block URL with a specific word somewhere in the subdomain ), and have come up none the wiser.
I feel like the js shouldn't really be that complex, I'm just trying to block a webpage and surface an error message in its place.
This is where I've netted out atm:
chrome.declarativeWebRequest.onRequest.addRules({
id: 'some rule id',
conditions: [
new chrome.declarativeWebRequest.RequestMatcher({
url: {
host: 'www.dailymail.com'
}
})
],
actions: [
new chrome.declarativeWebRequest.CancelRequest()
]
});
The answer at Block URL with a specific word somewhere in the subdomain works as expected. When it does not work, follow the following steps to troubleshoot the problem:
Open the background page's console and look for error messages.
Search for the error message on Google, and try to understand the recommended results. Trustworthy sources include Stack Overflow, the extension documentation, Chromium's bug tracker, the chromium-extensions and chromium-apps mailing lists.
Check whether you have added the correct permissions to your manifest file.
If you have just added the new permissions, make sure that you have reloaded the extension (e.g. by clicking on Reload at chrome://extensions/).
With the information you've provided, I can think of three reasons for failure:
Are you using Chromium beta, Chromium dev (or even Canary)? If not, then either install Chrome from one of these channels, or use the webRequest API instead. The declarativeWebRequest API is currently not available on the stable channel, only on the beta and developer channels.
url is an object of the type UrlFilter. There is no property called "host", if you want to match an exact host, use hostEquals, like this:
url: {
hostEquals: 'www.dailymail.com'
}
You have not added the correct permissions. To get your demo to work, you need to declare the declarativeWebRequest and *://www.dailymail.com/* permissions in the manifest file.
(This question pertains to the JS-XSL demo found here)
To briefly tell you what this demo is for; it takes a MS Excel file as input, parses the data, and outputs the data in text-only format. I downloaded the package (zip) and ran it locally, simply by opening the html file with Chrome.
The problem is, I just cannot seem to get over the following error:
Uncaught SecurityError: Failed to construct 'Worker': Script at 'file:///C:/Users/David/Desktop/Xlsx%20Demo/xlsworker.js' cannot be accessed from origin 'null'.
And above error points to line 34 of the html file, which has the following code:
/* I changed the file path from './xlsworker.js' to 'xlsworker.js' */
var worker = new Worker('xlsworker.js');
There are only three files for this demo: the html file itself, and two javascript files, one is named xls.js and the other xlsworker.js. All three files are in the same directory and at the same level.
What's rather baffling to me is, I successfully ran this same demo about a couple months ago! I cannot imagine if I am doing anything differently now. Any insight?
https://code.google.com/p/chromium/issues/detail?id=278883#c9
You are basically prevented by Chromium to use workers on the file:// protocol, you have to host your files and access them through the http:// protocol.
You need a server (even something simple like http://docs.python.org/2/library/simplehttpserver.html)
IMO, the below is a superior answer, because it does not require running a web-server. It's extremely quick and simple.
(the downvote is explained in my Note 5, below)
I have tested and verified that this solution works with the demo linked by the asker, when run locally as described by the asker. Tested on Windows 10, Chrome Stable x64 48.0.2564.103 m.
A script is not allowed to access to your local file system in Chrome. If you'd like to test web workers locally, you have to open Chrome with a special flag.
On Windows, launch chrome with the flag:
chrome.exe --allow-file-access-from-files
After that Chrome will be launched and you can test workers during this session.
Note1: if Chrome is already running when you run this command, the new instance of Chrome will not allow Workers to run-- you must first exit from Chrome (if necessary, use Windows Task Manager to ensure Chrome is not running).
Note 2: the source for this answer (link below) includes the --args flag on Windows, but i have not found the "args" to be necessary on Windows. In fact, i cannot find any documentation of the "args" flag anywhere-- not sure what it does. So i don't include it in the Windows command, above.*
Note 3: For those trying to do something similar on Chrome-Mac, or Windows-Firefox, the link below includes both, along with the Windows-Chrome solution above. But my solution described above is only the Windows-Chrome method.
http://js-workout.tompascall.com/web-workers-and-responsiveness/
Note 4: Be aware that this solution is not the same as running a web-server, but for your purpose it should be a completely adequate solution. Also, be aware that to browse the web with this chrome startup-switch enabled may compromise your local file-security, so it's advised to only use this method for your local file purpose, and disable it for web-browsing.*
Note 5: Google states that using startup flags "should only be used for temporary cases and may break in the future." Web search for chrome startup switches returns about 2,000 hits, so lots of people use them and blog about them. If your need is temporary, then this currently works great.*