Situation:
I am writing test automation for a website. There comes a point where there is a link button on my website. Clicking this I am redirected to an external website. There I have to log in and as soon as I do that I am redirected to my original web-page which contains some 'connections' that I need.
Problem:
As soon as cypress clicks on the redirection button it does into a blank page.
Ideal solution:
I would want to automate the entire scenario. If not then at-least a work around.
As suggested in the Cypress Docs, you should really be using cy.request() to log in. You don't control a 3rd party site, and that makes your test very flakey.
For example, a lot of login pages are constantly changing and are A/B tested for the purpose of preventing a bot from logging in, including testing bots. The data:, url is probably the result of a http redirect.
Thankfully, using cy.request() you can 'fake' logging in by making a request to the server through code (which doesn't change as much) and you will never have to leave your app to log in
Here's a recipe for Single Sign-On for example.
Hope that makes sense!
Related
Our team have been using Cypress as part as our E2E UI tests, however, we are running into some roadblocks where we can't write tests to cover some scenarios because the flow goes through a third party site.
We have several examples of this throughout our application:
Our signup flow actually goes through a slightly different domain (it's still our app, just a slightly different domain), but because Cypress doesn't allow us to navigate to third party sites, the tests stops
We have several integrations that requires the user to login through the third party site, and on success, they will be redirected back into our application. (We can do this through oauth... and as suggested by Cypress that would be the recommended way, but I feel that in doing so, it wouldn't exactly cover what we want to test, as we want to go through the steps of clicking the activate button, logging in, and being redirected back)
I was wondering if anyone has run into a similar issue and have found a solution or perhaps another alternative? While I agree that we should not be testing third party sites, what would be the option for our scenario?
We have tried setting chromeWebSecurity: false, however I believe this only works for Chrome...?
Thank you in advance!
It depends on what is required to cross the two domains, for example a token can be saved.
The trick would be to visit different domains in different tests. In the oauth example, test1 clicks the button and you confirm the navigation to the 3rd party site.
Test2 then retrieves the token and proceeds to test the local app as if it had been redirected from oauth.
I'm pretty sure it's covered in a Cypress recipe somewhere, will try to find it.
I have a page that I'm testing and it has a button to press to get additional information. Normally when clicked it would navigate you to a different site (different domain). Now I know the limitations of Cypress and cross domain access in tests. However, it would suffice for my test to confirm that the location had been set to the new address with out having to verify anything on the target page.
Is that possible?
I have the following very specific bug in my web application, caused by a curious interaction between the History API and the way Chrome caches pages.
User A logs in and uses a page like /home on the site. This page is an SPA type page that uses the History API to maintain a history stack as you navigate within the page. So as you do stuff, the url may change to /home/with/new/state This page also has a message like "Hello, User 1" on it.
User A logs out of the application.
On the same computer and browser, User B logs in and goes to /home, /home/with/new/state. Again, this is not a true navigation, just modifying the url via the history API.
User 2 clicks some link to navigate (for real) to another page on the site.
User 2 clicks the back button
The browser goes back to /home/with/new/state, but to the cached version that still says "Hello, User 1" on it.
Naturally, this is really confusing for users.
I can fix this by setting a more aggressive cache-control policy, forcing a reload of the /home page, but that would increase bandwidth to the site. The vast, vast majority of the time, the existing caching is fine, because the user isn't changing, so I don't really want to do this server side, for all users, always. It also is only an issue in Chrome; somehow the other browsers handle this correctly. I'd prefer a mechanism to bust the cache ONLY when I have this situation of a user change.
How might I accomplish this?
We have just implemented the _escaped_fragment solution in our testing environment along with a headless browser (phantom.js) to make our site crawlable by google.
The issue is I cannot find any solution for how to test this before pushing this change to our production environment.
The fetch as google link in webmaster tools doesn't work. Is there another way we can test this quickly instead of waiting for the google crawler to crawl our site?
You could write a bookmarklet that mucks with the URL of the page. It would replaces the #! with ?_escaped_fragment= and URL encodes the hash bang params. Then you could at least manually go through your site, activate the bookmarklet on any page and verify that you get the content that you expect.
This issue began last week. Prior to that, I was not having any problems, and I am not aware of any changes to my site or platform.
Now, when I want to share a new blog or article to Google+, it fails. Typically I would use the embedded +1 buttons on a specific post and use the expanded box to create my post. The box comes up, but instead of a nice title and image, it now uses the URL only for the page, and sometimes adds extra characters to the end of the URL. If I take the URL from the address bar and try to compose a new update directly on Google+, I get the same issue. If I enter the URL into the Link field on a status update, it usually comes back "could not load website."
Here's a sample
You'll find Google+ sharing buttons above and below the article. Sharing to every other network works as expected.
My site is a Drupal site that has been operating for 10 months. I am a Drupal developer, but have never encountered an issue like this.
It appears that requests from the Googler crawler are being rejected by your server. I tried testing the microdata with the structured data testing tool and it runs into problems connecting to your site. Other sites work fine.
If you have access to your site's Apache access logs, I would check those for problems coming to that URL. You can narrow your search down by looking for the user agent of the crawler: Google (+https://developers.google.com/+/web/snippet/)
My guess is that something changed in your server's configuration that is the cause. Start with the logs and see what's there.