I am using Cucumber to perform automated tests. I am running two features during a run where in I enter my credentials to perform an action in the website. When second feature is executed I will have to re-enter the same credentials but the browser had already stored my credential previously making the script to actually skip/fail at this step. I have shared my script below. Please advice what can be the solution.
I tried deleting cookies but still the problem persists.
When /^I clear cookies$/ do
browser = Capybara.current_session.driver.browser
browser.manage.delete_all_cookies
end
In this case, You need to reset your sessions which will allow you to re login again with out any issues!
in your code:
When /^I clear cookies$/ do
Capybara.reset_sessions!
end
Accept my answer if it works for you!
Starting a new browser session guarantees a clean environment. However, depending on your setup and test suite, it slow tests down too much, but you might want to try that.
Deleting cookies does not drop credentials if you logged in using HTTP basic auth. If that is the case, there's no other generally applicable way than to restart browser.
Related
When making an auth request to the Google API (gapi), it's returning false on the checkOrigin.
I have removed any client id's or anything that would link directly to my account and replaced it with a regex indicating what the data is for reference.
Url: https://accounts.google.com/o/oauth2/iframerpc?action=checkOrigin&origin=https%3A%2F%2Flocal.tools&client_id=(\d{21})
My origin url is a local url, which is https://local.tools
Result: {valid: false}
I'm using the example found here without deviation (except for replacing clientid with my 21 digit clientid): https://ga-dev-tools.appspot.com/embed-api/third-party-visualizations/
The items I'm trying to display show up nicely on the demo site, but aren't getting past the Not valid origin for the client error on my local.tools site.
Clear your browser cache. Started getting this error in Chrome and then I created a new client id and was still getting the issue. Opened firefox and it worked, so I cleared the cache on Chrome and it started working.
I received the same console error message when working with this example: https://developers.google.com/analytics/devguides/reporting/embed/v1/getting-started
The documentation says not to overlook two critical steps ("As you go through the instructions, it's important that you not overlook these two critical steps:
Enable the Analytics API [&] Set the correct origins"), but does not clearly state WHERE to set the correct origins.
Since the client ID I had was not working, I created a new project and a new client ID. The new project may not have been necessary, but I'm retaining (and using) it.
Here's what worked:
Create a new project
Add and Enable the Analytics API
Create a new credential - ensure that it is an OAUTH credential (scroll to the bottom of this page for instructions https://developers.google.com/api-client-library/javascript/start/start-js#Setup).
During creation of the credentials, you will see a section called "Restrictions
Enter JavaScript origins, redirect URIs, or both". This is where you can enter your origins.
Save and copy your client ID (and secret).
My script worked after I created the new OAUTH credential, assigned the origin, and used the newly generated client ID following this process.
try clear caches and then hard reload, i had same error but when i tried to run on incognito browser in chrome it worked.
Key Point: Add both http://localhost and http://localhost:port_number to the Authorized JavaScript origins box for local tests or development.
Credentials do not work if API is not enabled. In my case the next steps were needed:
Go to https://console.developers.google.com/apis/library
Enter 'People'
From the result choose 'Google People API'
Click 'Enable'
Creating new oauth credentials worked for me
You probably use Client ID like this: <CLIENT_ID>.apps.google.com
Make sure your client ID is without ".apps.google.com"
For me - I just went here:
https://console.developers.google.com/apis/credentials
Then chose the right project; then choose the credential with the same ID shown in your console error message. When editing the credentials you can add multiple origins to the white list.
After updated Authorized JavaScript origins browser still caching old data, so I need to Empty cache and hard reload then it works
1. Change Authorized origins
2. Open Dev Tool (F12) then right-click into reload button
Clearing the cache on chrome works!
Please find the steps below to clear the cache.
Open dev tools (Right-click on the page and select inspect/ press F12)
Right-click on the chrome reload button while the dev tool is opened. (You will find the option to clear the cache and reload the site)
clearing the cache works for me.
for React developers try to restart the project otherwise it will show the same error again and again.
It was a referrer-policy problem.
This has been such a pain for a long time to me too...
Found the issue, my website instance had a referrer policy set to
no-referrer. After setting it to no-referrer-when-downgrade, the One
Tap prompt showed up as expected.
https://stackoverflow.com/a/63039142/15565029
If you are using Django, SECURE_REFERRER_POLICY is 'same-origin' by default. Change it by adding the below code in your settings file.
# settings.py
SECURE_REFERRER_POLICY = 'no-referrer-when-downgrade'
https://docs.djangoproject.com/en/3.2/ref/settings/#std:setting-SECURE_REFERRER_POLICY
Similar to few answers at above but with screenshots. If you created project for Firebase, may also use the same steps to configure at Google Cloud Platform console.
Select the project at https://console.cloud.google.com/
Navigate to Credentials
Click Edit button for the related OAuth 2.0 Client ID
Add URI into Authorized JavaScript origins
Don't forget to Save
That worked for me after trying for an hour:
On https://console.cloud.google.com/apis/credentials :
Edit Client Outh (mine was: Web Client (Auto Created by Google Service), which was created by my Firebase Web Project)
Enter JavaScript Origin for the Client ID (mine was: localhost:NNNN)
and don't forget to Save.
Try google login for half an hour: didn't work
Enabled Google Analytics as suggested above
Empty Chrome cache and hard reload as suggested above
Try google login for half an hour: didn't work
Sign Out from https://console.cloud.google.com, and sign in again
Empty Chrome cache and hard reload
Now it worked
I don't know which one of the above fixed the problem.
May be it was just a matter of time for cloud.google to
recognize my new JavaScript Origin.
I got the error because of Allow-Control-Allow-Origin: * browser extension.
Trying on a different browser(chrome) worked for me and clearing cache on firefox cleared the issue.
(PS: Not add the hosting URIs to Authorized JavaScript origins in API credentials would give you Error:redirect_uri_mismatch)
I was getting the same error but tried publishing my app and now it shows as below:
I'm trying to use sw-precache, but I must be doing something wrong!
I'm mostly using the demo code available from the github repo and can't seem to get updates to the app to come through. Once it's cached the first time, it never checks for new versions.
I was expecting that when I publish a new service worker, the browser would request the new service worker and update the cache accordingly in the background. Then using the registration code in the example, I would be able to prompt the user to refresh and get the latest version from their newly refreshed cache.
Would really appreciate if someone could please point me in the right direction.
Example
To demonstrate the problem, I've created an isolated example here:
https://github.com/stevenocchipinti/sw-precache-demo
The example uses a basic skeleton from create-react-app which has a built in build task which take care of fingerprinting the filenames, etc.
I suspect the problem is with me caching everything by using the following sw-precache config:
{
"staticFileGlobs": [ "build/**/*.*" ],
"stripPrefix": "build/"
}
There are more accurate steps in the repo's readme, but the basic steps I'm taking to reproduce the problem are as follows (with my probably incorrect expectations).
Steps and Assumptions
Browse to the app for the first
I should see Content is now available offline! in the console
Reload the page
The message in the console should not appear again because the service worker is installed, but the page should still work.
Go offline and reload the page
The page should still work
Make a visible change to the source code
Rebuild (run the build task and sw-precache)
This is where my understanding must be wrong
Reload the page
The service worker should update the cache in the background
When its done, you should see New or updated content is available. in the console
The actual visible changes should not be visible until the next reload
Reload the page again
The browser will use the new cache this time around
The changes should be visible now!
There shouldn't be any messages in the console
The problem
Once the app has been cached initially, it will never update unless you unregister the service worker or force a reload.
I'm not sure how to make this work - any help would be greatly appreciated!
After replicating your development hosting environment, I can see that you're serving your service-worker.js file with a browser HTTP cache lifetime of one hour:
There's more information as to why this is leading to the behavior you're seeing, along with best practices, in this previous answer. As mentioned at the top of that answer, browsers plan on changing their behavior to stop honoring the HTTP cache for the service worker file by default, mainly due to the type of confusion that you're experiencing here. For the time being, though, the production versions of both Chrome and Firefox continue to honor those headers.
I'm having problems with the simulation of the checkout flow with Jmeter. I believe there is a problem with the session management. I have already added a cookie manager in order to use the wcs cookies trough my testing plan. Has anybody ever done this? Please help me.
I also checked the SystemOut.log, and i found this exceptions(I don't have the exact text but it's similar to:
The user #### does not have the authority to run this command
or
The user does not have the authority to run this command
This happens with OrderItemUpdateCmd and OrderProcessCmd.
Please help me, thanks in advace.
Sometime this error occurs if we haven't run the acpload after adding new controller commands. Are you getting this error with the Out of Box WCS commands or the new controller commands added.
This thing just seems to give me problem after problem.
I posted another question earlier, trying to solve the problem of retaining my session state between closing and opening through Watir. Firefox achieves this on its own, so I figured if I just set the preferences correctly, it'd save my state. I ended up having to go into the selenium-webdriver source and make some changes in order to achieve this in reality.
So, I was just testing my application. Part of its behavior is to loop through a bunch of pages and extract text from them. While it's looping, I simply have it in a while true loop, and figured "hey, I can just stop the program with Ctrl+C". Well, this worked fine up to now, until it came to saving the states.
Ctrl+C causes it not to save its state. My guess as to why is that you need to actually close the browser (and I actually recreated the bug in IRB, so I'm pretty sure this is the case). Simple, right? Why not just use an ensure block with #browser.close in it? That was my first thought.
So, when I try it this way, it does hit the ensure block, and the ensure block calls a method called kill. Kill calls #browser.close if #browser.exists?. The problem is that when it tries to execute this line, I get a nice long list of errors leading up to selenium-webdriver. It seems as if it's trying to make an HTTP request as part of its close functionality, and is failing because, perhaps, Ctrl+C exited the application.
The stack trace is located at https://gist.github.com/Inkybro/5557085
The very last thing I thought was that maybe I needed to let any calls to the #browser object complete, so I placed a bunch of trap('INT', 'IGNORE') and trap('INT', 'DEFAULT') lines around these pieces of code. This also doesn't seem to do the trick.
I'm not really sure as to why, which is why I'm posting here. What I think needs to happen is that whatever processing is going on at the time of Ctrl+C needs to finish processing before #browser.close can be called. If anybody has experience with Watir and/or Selenium, or even if you don't, perhaps you could help me out?
Are you supposed to be testing the browser itself, or your product? Because really, if you are doing things like above, (logging in, closing and re-opening the browser to see if you are still logged in) it sounds to me like you are basically testing the browser's ability to store and read cookies and properly provide them when making requests of a page.
What about if you presume for a moment that the browser in fact does what it is supposed to do with regard to cookie management and usage? If you do that, then what becomes important? I think it would be that your app tells the browser to create the proper cookie, with the proper contents.
So maybe rather than actually trying to test that firefox will in fact use it's cookies correctly (or any other browser doing that for that matter) why not simply test that when the user has logged in, that the proper cookies have been created? You may also have to test that the cookie is updated periodically so that a user's session does not expire while they are actively using the site. again pretty easy to test by just looking at the cookies
You might also want to test that your server is sensitive to changes in the cookie, or a missing cookie. That the server is looking at the cookie and is not depending on session variables is also pretty easy to test, login, alter or clear the cookie, try to access a page and see if it fails.
So with that you get three things
1) Proper cookies created upon login.
2) Cookies kept updated as various pages are accessed.
3) Missing or altered cookie == no soup for your user.
(#4 site works properly if cookies present is implied by the three above and all the rest of your tests that exercise your site/app)
Stop trying to do the work of the mozilla test team, and refocus on testing your application.
I'm still not sure what you try to achieve, but this hacky piece of code ensures browser is closed on Ctrl+C and no your exception is raised:
require 'watir-webdriver'
begin
browser = Watir::Browser.new
loop do
# some code
end
rescue SystemExit, Interrupt
puts 'Exiting!'
ensure
begin
browser.close
rescue Errno::ECONNREFUSED
# do nothing
end
end
first, sorry for the bad english.
I have a test that submit a login form.
after redirect, when I test for a message 'successfully logged...'
then my page.body is
'<h1>Not Found</h1>'
but this works perfectly on browser manual test.
what should I'm doing wrong?
Sounds likely that one of your steps is redirecting in a way that you do not expect.
Check your before filters on the controller and application_controller to determine whether a login/I18n filter is redirecting your page.
If you have the launchy gem installed, you can also add the following to your steps:
And show me the page
Which will fire-up a browser with what capybara is actually looking at, which is useful for sanity checking your steps.
Good luck!
Tests run under their own clean copy of the database. Make sure you've set it up first using rake db:test:prepare, and that you're creating all the data you need for your tests as part of the feature. (I.e. Given there is a user named "Joe"...)