I'm using omniauth and cucumber with a new application. I've got omniauth up and working and am trying to add appropriate cucumber feature tests. I kept running into odd errors in testing - errors that I don't get when performing the same steps manually.
Via "show me the page" I've narrowed it down to the fact that when cucumber does anything it's doing it via a file path (e.g., file:///path/to/app/tmp/capybara/capybara-201107151148029152254898.html) instead of an http path (e.g., http://localhost:3000/).
Why would my cucumber tests go through file paths instead of http paths; and how do I fix this situation?
I can only guess that Capybara implements "show me the page" as the following steps:
Take the HTML source from the current page and write it into a file
Open that HTML file
I assume your tests are hitting your application just fine using HTTP. (You can always verify that by looking at your logfiles.) But "show me the page" cannot simply open the URL it was testing because its content might change from request to request.
Example: A test posts a comment by POSTing to /comments. If that fails for any reason and Capybara would open /comments (the URL that raised the exception), it would issue a GET request and couldn't present you the content it saw.
Related
I am running a simple suitelet with a form, to which I am adding a clientscript.
form.clientScriptModulePath = './clientScript.js';
It works fine, as long as the suitlet is run from the 'normal' url.
But if External URL is used, clientScript seems to be completely ignored, no error, just ignored.
Are Client Scripts not available for External URL's in NetSuite? Or is there some workaround for it?
I didn't find any documentations for External URL restrictions.
When you select Available Without Login and then save the Script Deployment record, an External URL
field is displayed on the Script Deployment page (see following figure). Use this URL for Suitelets you want
to make available to users who do not have an active NetSuite session.
Note The Website feature must be enabled for Clients Scripts to work in externally available Suitelets
Please go to Set up > company > Enable features >Web presence > Website.
Here is a screenshot for your reference
The Suitelet should be in released status to avoid any other errors.
The following table shows how you can specify the localization context based on the script type.
Script Type
Defining Localization Context Filtering
SuiteScript 2.0 Client Script Type
Complete the following steps to add localization context filtering to client scripts:1. Use the localizationContextEnter and localizationContextExit entry points in your script.
Please let me know how this goes!! Happy coding :)
It's been a while but I think your clientScriptModule path needs to be absolute for it to work externally. I think I ran into this a couple of years ago and that turned out to be the solution.
I have configured my Liferay 7 site with a terms of use web content document. It works perfectly when new users log in for the first time.
However, I need to be able to provide a link to review the terms of use. The only thing I see is in the Liferay Portal struts-config.xml file, which is "/portal/terms_of_use". But this link appended to my hostname is not working. I get a "Not Found" error page ("The requested resource could not be found.").
Am I using the wrong URL? I've tried searching for what the URL would be and have not found anything, which is surprising since I would think this is a common requirement.
With the routing of web-stuff to OSGi bundles, there's no longer any top-level URL that can be specified this way (there may never have been one). However, there is a way to get to it:
http://localhost:8080/c/portal/terms_of_use requires login, but results in the (in my case unconfigured) terms of use. The /c within the URL targets struts (and maybe something else - the /portal within targets a certain bundle (portal-web in this case)
I'm testing a web app that integrates Gmail, Slack, Dropbox etc. I'm trying to write end to end tests with Cypress.io to verify that auth flows are working. Cypress restricts me from navigating outside my app's domain and gives me a Cross Origin Error. The Cypress docs say that testing shouldn't involve navigating outside your app. But the entire purpose of testing my app is to make sure these outside auth flows are functioning.
The docs also say you can add
"chromeWebSecurity": false
to the cypress.json file to get around this restriction. I have done this, but am still getting cross origin errors (this is at the heart of my question. I would ideally get around this restriction).
I have attempted cypress' single-sign-on example. https://github.com/cypress-io/cypress-example-recipes#logging-in---single-sign-on
I was not able to make it work, and it's a lot more code than I think is necessary.
I've commented on this thread in github, but no responses yet.
Full error message:
Error: CypressError: Cypress detected a cross origin error happened
on page load:
> Blocked a frame with origin "https://www.example.com" from
accessing
a cross-origin frame.
Before the page load, you were bound to the origin policy:
> https://example.com
A cross origin error happens when your application navigates to a new
superdomain which does not match the origin policy above.
This typically happens in one of three ways:
1. You clicked an <a> that routed you outside of your application
2. You submitted a form and your server redirected you outside of your
application
3. You used a javascript redirect to a page outside of your application
Cypress does not allow you to change superdomains within a single test.
You may need to restructure some of your test code to avoid this
problem.
Alternatively you can also disable Chrome Web Security which will turn
off this restriction by setting { chromeWebSecurity: false } in your
'cypress.json' file.
https://on.cypress.io/cross-origin-violation
setting { "chromeWebSecurity": false } in my 'cypress.json' file worked for me
If you are trying to assert the proper navigation to gmail...
You should stub the function that handles that and assert that the request contains the necessary key value pairs. Without more information on the intent of this test it is hard to give specific advice. It sounds like you would want to have a "spy"(type of test double).
Here is the documentation for spies: https://docs.cypress.io/guides/guides/stubs-spies-and-clocks.html#Stubs
If you are trying to verify the contents of the email
You will want to use a library to handle reading gmail. cy.task can be used to invoke JavaScript from an external library. This Medium article has a good write up on how to do this.
Medium article: https://medium.com/#levz0r/how-to-poll-a-gmail-inbox-in-cypress-io-a4286cfdb888
TL;DR of article
Setup and define the custom task(method) that will check gmail(uses "gmail-tester" in the example)
Use cypress to trigger the email(obviously)
Capture/define data(like email subject, dynamic link, email content)
Assert the data returned from gmail-tester is as expected
DON'T
Use the GMail UI in your test in an effort to avoid test flake (all UI testing has flakiness), and potential UI changes to the Gmail app that require updates to your test. The backend methods that gmail-tester uses are less likely to change overtime compared to the UI. You also avoid the CORS error.
Disabling cross-origin security, if you must...(eek bugs!)
If you must, add chromeWebSecurity: false to the cypress.json config file. Be sure to add it inside of the curly braces. There should only be one set of braces in that file.
NOTE: One cannot simply use cy.visit(<diffSuperDomain>); there is an open issue. Apparently this is a very difficult change to make in cypress.
One potential workaround is to only have one super domain per test. It should work if you set the chromeWebSecurity: to false and only have one domain per test(it block). Careful, as it opens you up to cascading failures as one test will rely on the next. Hopefully they fix this soon.
https://docs.cypress.io/guides/guides/web-security.html#Disabling-Web-Security
Since Cypress 9.6.0 you can set "experimentalSessionAndOrigin": true in cypress.json. This allows your tests to operate in multiple domains using the origin command. Example from the official blog:
it('navigates', () => {
cy.visit('/')
cy.get('h1').contains('My Homepage')
cy.origin('www.acme.com', () => {
cy.visit('/history/founder')
cy.get('h1').contains('About our Founder, Marvin Acme') // đź‘Ť
})
})
At that blog entry there are also examples how to use this to authenticate at another domain. Worked fine for me with Keycloak using both Chrome and Firefox.
There are a few simple workarounds to these common situations:
Don’t click <a> links in your tests that navigate outside of your application. Likely this isn’t worth testing anyway. You should ask yourself: What’s the point of clicking and going to another app? Likely all you care about is that the href attribute matches what you expect. So make an assertion about that. You can see more strategies on testing anchor links in our “Tab Handling and Links” example recipe.
You are testing a page that uses Single sign-on (SSO). In this case, your web server is likely redirecting you between superdomains, so you receive this error message. You can likely get around this redirect problem by using cy.request() to manually handle the session yourself.
If you find yourself stuck and can’t work around these issues you can just set this in your cypress.json file. But before doing so you should really understand and read about the reasoning here.
// cypress.json
{
"chromeWebSecurity": false
}
In a system I have to maintain (didn't build it, just inherited it) we have a Foursquare implementation that hasn't been used in quite a while. Trying to revive it failed, because our page is now loaded via HTTPS, which it didn't used to be.
We are using the "Save to Foursquare" button as well as the API request to retrieve the number of Check-ins. I already switched all the JS includes and intent links from http to https and at least now it shows the number and the button correctly.
However, I can't click the button and checking the browser's console I found that it added a script tag to the head of this page which tries to access http://platform.foursquare.com/js/modules/widgets.asyncbundle.js. The browser obviously blocks this, because it's not using HTTPS.
The file we are explicitly loading is https://platform.foursquare.com/js/widgets.js. It seems to me like this script is not reacting correctly to HTTP vs. HTTPS. There is probably a very simple solution to this, so what am I missing?
I don't know if you've tried it yet but the foursquare website says this on the matter:
Change the source of the JavaScript file to https://platform-s.foursquare.com/js/widgets.js
Add {"secure":true} to the global configuration block (window.___fourSq)`
The same link (see below) has all the different ways to call the Save To Foursquare function using its .saveTo() function.
https://developer.foursquare.com/overview/widgets
I hope this information and links helps! Cheers.
I try to call XSP._isDirty() for XPINC but it does not work. In the browser everything works fine. Is there a trick how i can use it.
Is there a way how i can see clientside errors when i'm executing XPages in the Notesclient?
Two questions here.
Q1. XSP._isDirty()
XSP._isDirty() is an internal call. From the XPages portable command guide (page 156).
XSP._isDirty() : Used internally by the Dirty Save feature— see the <xp:view> properties for enableModifiedFlag. This is a private function.
Code for this call is in the file xspClientDojo.js (look for the uncompressed file on Domino/Notes).
As it is an internal call it is used at risk. There is no guarantee it will work as expected in later versions.
The enableModifiedFlag is an XPage attribute that allows you to mark the page as dirty and prevent the user accidentally leaving the page. There are more details about this on the Infocenter.
Q2. Client side debugging.
You can review client side errors using the developer panel of most modern browsers, or something like the firebug plugin. The XPages extension library comes with a Firebug Lite component you can use as well.
For SSJS and XSP engine issues you can review these in the Notes client by reading the XPages logs in the IBM_TECHNICAL_SUPPORT folder contained in the Notes data folder.
For a "live" method of this is to modify the shortcut that launches notes as follows:
Target: C:\Lotus\Notes\notes.exe -RPARAMS -console -debug -separateSysLogFiles -consoleLog
Start In : C:\Lotus\Notes\framework\
Change the path to match your clients install.