I have a contact addition form that can be navigated to from multiple screens in our application.
Once the form is submitted, I then take the user to a screen to view the contact that was added.
When the user then makes use of the back button it should take them back to the screen that they originated from.
This might be the Android back button or one that calls the RouterExtensions back function.
I have made use of the navigate extra replaceUrl when navigating away from the form to the view page.
I have also tried using the skipLocationChange extra when navigating to the form but this creates more issues.
I have created a simple playground page flow that creates not quite the same issue but does throw an error that I don't know what to do with either:
https://play.nativescript.org/?template=play-ng&id=BfVcGZ&v=2
In our app, by making use of the replaceUrl extra, the back button does take the user to the correct page.
However, there is a brief moment where they see the form again. This isn't an ideal user experience.
In the linked Playground I do get an error:
Cannot reattach ActivatedRouteSnapshot created from a different route.
This seems to tell me that replaceUrl is indeed removing the page from the route table.
However, the page isn't destroyed yet and so the app is trying to show a page that it shouldn't.
replaceUrl is not yet supported by Page Router Outlet, there is an open feature request, you might want to register your vote on the feature and follow up there for further updates.
We have integrated invisible recaptcha in one of our websites. Whenever we submit the form it automatically submits.
I read in some google groups that we would get a challenge when accessed on edge browser. But for us, it is automatically submitted.
Any specific steps to test the invisible recaptcha?
You can test invisible recaptcha by using Chrome emulator.
You will need to add a new custom device (BOT) in developer tools, and set User Agent String to Googlebot/2.1 on Desktop. Then use the new BOT device when testing on your site to trigger the recaptcha authentication.
Note: ReCaptcha v3 will still let the google bot pass as it has a score of 0.9 when emulating in Chrome.
V2 INVISIBLE
In this case just use Incognito or Private browsing to see it works.
Here is the testing link where ReCaptcha is working:
https://www.google.com/recaptcha/api2/demo?invisible=true
Please give the credits to the guys in comments below.
I found an excellent answer that works as of 2018-08-27.
In Chrome, hit F12 to open the Developer Console. Next, toggle the Device Toolbar, select a device and click Edit... Now, add a new device with the following configuration:
Once you hit save and use the new device, the ReCaptcha should open a modal requiring the user to match images.
Credit: This answer was originally posted on https://www.tectite.com/fmhowto/test-invisible-recaptcha.php?WWWTECTITE=p32j2na5otc4rmtbmfsmf9rci6
May 2021
Everyone was talking about using the demo page to test it out. What we get after we tested and how it should looks like is what everyone miss out. Or probably thats why most of us are still searching for the answer.
Even though this question is 3yrs old, still its not clear how this recaptcha works. Iam trying my best to break in steps. Let me know if its works for you.
Google Demo page test
Important
Follow the steps below in the Incognito window
with the parameter
Go to this url https://www.google.com/recaptcha/api2/demo?invisible=true (notice the url has ?invisible=true parameter at the end)
You should see nothing but an pre-filled form with an active 'submit' button with no 'checkbox' captcha, instead you will see the badge at the bottom right.
Click the 'Submit' button and you should see something like this. This is the verification check point.
4. Select the relevant image and the page should redirect with the message saying
Verification Success... Hooray!
But what if you didn't see any image?
If you are not seeing any verification image and the form submits with
Verification Success... Hooray!
then either the form is not working (mostly that's not the case) or you need to clear your browser cache and try again.
without the parameter
Go to this url, https://www.google.com/recaptcha/api2/demo (notice, i have removed the ?invisible=true parameter from the url)
You should see the good 'ol robot checkbox captcha above the 'Submit' button.
3. Also you can notice there won't be captcha badge at the bottom right.
Your Website
Try it in the Incognito window
Just like the demo you should get the same result in your website if you use invisible captcha. (Don't worry about the url parameters)
If your page displayed the captcha badge at the bottom right then after clicking the 'submit' button you should see the popup image window.
If you do not get any popup and the form submits then there's an issue with your captcha or could be browser cache.
Not seeing the checkbox ... ?
Here are some notes from reCaptcha help page - https://support.google.com/recaptcha#6223828
If you're seeing this reCAPTCHA challenge, your browser environment doesn't support the reCAPTCHA checkbox widget.
There are a few steps you can take to improve your experience:
Make sure your browser is fully updated (see minimum browser requirements)
Check that JavaScript is enabled in your browser
Try disabling plugins that might conflict with reCAPTCHA
Please note that some sites may have incorrectly integrated with reCAPTCHA - in this case please contact the site's webmaster.
WordPress Contact Form 7 users
You do not need to add the [recaptcha] tag.
reCAPTCHA v3 doesn’t need a CAPTCHA widget (the “I’m not a robot” checkbox used in reCAPTCHA v2) to work, so [recaptcha] form-tags are no longer necessary. If [recaptcha] form-tags are found in a form template, Contact Form 7 5.1 or higher ignores them and replaces them with an empty string.
https://contactform7.com/recaptcha/
As of 2019-06-21, it appears that it is sufficient with Google Chrome (v74.0.3729.169) to bring up a new incognito window to force the recaptcha to execute. (I had needed this for our own recaptcha testing, so I'm glad I found it.)
I am still struggling a little bit with this but I found that the following things make invisible recaptcha puzzle more likely to appear:
Log into the recaptcha admin and set it to maximum security
Open your site from an incognito tab.
Sometimes leaving the login page open and trying to login after some time has passed seems to trigger the recaptcha puzzle.
I must admit though that these don't work all of the times and there are times that I really struggle to get it to work.
Update: It seems a bit strange but I have found that the invisible ReCaptcha is more likely to appear when I submit a form using the Enter key instead of pressing a button with the mouse.
Invisible recaptcha check fails if you try to access your page via automated tests (in my case chrome browser) since chrome has a feature to recognize if the browsers is controlled by such software... so try to create easy tests in Python or Java(+webdriver), to see if recaptcha is implemented correctly.
If you did not implement the code yourself, the first thing to check is the source code, see if reCaptcha is actually loaded. When using a CMS, I search for this line (or similar):
script type='text/javascript' async defer src='https://www.google.com/recaptcha/api.js?onload=renderInvisibleReCaptcha&render=explicit&hl=de-CH'
If you have the luxury of a VPN, switch to a bad rep IP or country or an IP commonly used for P2P. This works for me most of the time.
Go thru the steps to test the re-captcha with dev tools open. Go to the network tab and find the POST where the form is submitted. Right click that line and copy as cURL.
Paste into the CLI and voila, you get the failure and the output of the cURL is the HTML that the server sent back.
2022 Answer that worked for me!
Please do give this one a go as it's the only one that actually worked for me after hours of testing.
Go to your reCAPTCHA admin account: https://www.google.com/recaptcha/admin/
Go to your site settings
Move the "Security Preference" slider all the way to the right to make reCAPTCHA trigger more often
Open an Incognito window, or even better a secure web browser with a built in encrypted proxy (I think this makes reCAPTCHA more suspicious of your browser) - I used a browser call Epic Browser, which is also Chromium based: https://www.epicbrowser.com/. Note: Just using Incognito on Chrome did not work for me, hence why I went to go use Epic.
Attempt to submit your form - you should hopefully receive the popup check!
As others mentioned you can also test if the browser alone triggers reCAPTCHA check by going to https://www.google.com/recaptcha/api2/demo?invisible=true and submitting the form.
This finally helped me as I was going crazy thinking my reCAPTCHA setup was not working and that I coded something wrong... But no, it was working! Just not very suspicious apparently.
I hope this helps someone as it did me!
The way I tackled it:
Go to your POST to google.com/recaptcha/api/siteverify
Before the response is returned, set the success property in the response to false.
I'm using Guzzle in Laravel (thanks to this example):
$response = $client->post('https://www.google.com/recaptcha/api/siteverify', [
'query' => [
'secret' => env('RECAPTCHA_V3_SECRET_KEY'),
'response' => $value,
'remoteip' => $_SERVER['REMOTE_ADDR'],
]
]);
$body = $response->getBody();
$contents = json_decode($body->getContents());
$contents->success = false;
return $contents;
If you go to http://jsbin.com/ibozun/2, hit "Add Item," and then hit "Save," you will see that a second dialog is opened on top of the first one. The form in the dialog is posting to itself (no action defined) - this is by design. Because the dialog has duplicated itself, now you have to hit "Cancel" 2 times to get it to close.
The use-case for this setup is a MS MVC3 page with unobtrusive JQuery validation on it. The default scripts (in other words, I have no custom validators - the scripts are straight from MS) cause an ajax call to the server, and JQM treats that the same as a self-posting form - so you wind up with a duplicate dialog if validation fails.
A similar thing happens if the second page as a page, rather than a dialog - the form posting to itself results in a second history entry in the browser, so to get back to page 1, you have to hit back 2 times.
I believed this be a bug in JQM, but after submitting a bug on GitHub, I was told that this is the expected behavior. So, assuming this behavior that will not be changing in the framework, how do I prevent this from happening for my instance (preferring NOT to edit the framework JS)? Do I have to write my own ajax calls for validation so that I can prevent JQM from knowing that anything has happened? That seems unfortunate...
One idea I had was to detect that the nextPage and current page are the same on "pageHide", and manipulate the dialog/history myself, but have had no luck.
Thanks in advance!
First, there is no dialog duplication in the example. Second, my response and an explanation as to why solving the history issues with posting back to the same page for users of the library is hard can be found here. This example is particularly thorny because it's also in a dialog which we don't support linking to, so disabling ajax for the form (ie forcing it to reload), which would work if it were embedded in a page, won't serve.
The quick solution here is to switch the dialog to a page and add the data-ajax=false data attribute to the form. Mind you this causes a page flash/reload and requires that the form document be fully formed with a head including javascript,css, etc.
1) I saw an interview question on this, and I'm assuming it's something to do with form submission and avoiding double submissions. Can someone confirm this?
2) Assuming this assumption is correct, can this be done with Ajax? If so is there a link someone can point me to?
(I'm assuming you'd generate some sort of random number and include it in the form as a hidden field, then ensure that number hadn't been submitted before for the session).
Redirect-after-post is a technique to avoid problems with the user refreshing or using the back button to get back to a posted form. In short, instead of providing a response page to an HTTP post, which will trigger another post if its reloaded, you issue a 303 redirect (or a 302, to support ancient browsers by taking advantage of a bug that is as old as the web). This causes the browser to issue a second HTTP request - a get this time - and if the response page to that is reloaded there shouldn't be any problems. Just make sure that all the changes are made by the post handler and the page you redirect to has no side effects.
If you post using XMLHttpRequest then the redirect will be followed; unless you specifically support it using the hash part of the location or the new HTML5 history methods then the back button and reload aren't going to trigger an AJAX post again.
I am implementing a web application using ASP .Net and C#. One of the pages has a requirement that it always needs to be fetched from the server, rather than from the local browser cache. I have been able to achieve this.
We have a back button in the application, which simply invokes javascript:history.back() method. The problem is that when the back button is clicked to navigate to the page which is always to be reloaded from the server, the browser displays a "Web page expired message".
The intent here is to force the browser to reload the page rather than display the web page expired message.
Any help would be highly appreciated. Thanks a ton in advance.
You will probably need to change the implementation to make the browser load the URL explicitly:
window.location.href = 'http://....';
instead of invoking the back button, since the intention of the back button is to get the last page from the cache.
(If browsers would not act that way, they would re-send your form data multiple times when using the back button during a registration process or similar.)
You mean you want to control browser behaviour, which is not possible. I doubt you can solve it that way. You could set the expiration time to a small value (1 minute perhaps?) so that the page is still valid if one navigates back quickly.