Yesterday I added Google ReCAPTCHA v3 in one of my client's Shopify website, but I don't think that it is working because he is still reporting to receive several spam e-mails.
I've followed Google's guide, but I don't know what to do for "Verifying user response" part of the guide. I'm not an expert in coding.
Basically I've added this code to the theme.liquid file
<script src="https://www.google.com/recaptcha/api.js?render=*site key provided by google*"></script>
And then I've added this part in the page.contact.liquid file:
<script> grecaptcha.ready(function() {
grecaptcha.execute('*site key provided by google*', {action: 'contact'}).then(function(token) {
...
}); }); </script>
Have I missed out something? Can someone help me to fix this issue please?
Unfortunately, any attempt to implement reCaptcha on a native Shopify contact form will not work. It may appear to work, as in the form submits and you see the stats in the reCaptcha admin, but it won't actually be blocking any spam. The reason is that you can only implement the client-side piece in your theme, and in order to work, you must have both the client and server-side pieces in place and working. The server-side piece is what detects a failed captcha (i.e., a spam bot) and prevents the form from being submitted.
Implementing just the client-side piece might block some of the most unsophisticated spam bots that just see the captcha and stop, but it's trivial to design a bot to bypass the client-side piece: that's why the server-side piece is essential.
Also posted this answer on the Shopify forum thread linked by Chami, as people there are going in circles thinking it's possible or thinking it's working when it's not. 🙂
Update: Since originally posting this reply, Shopify has built reCaptcha support directly into the platform, and it's turned on by default. With this done, there's no need to implement the frontend code either within the theme, as it will be included automatically:
https://help.shopify.com/en/manual/online-store/os/preferences#protect-your-store-with-google-recaptcha
Try on this one.
https://community.shopify.com/c/Shopify-Design/Adding-Google-reCaptcha-v3-to-the-Shopify-contact-form/td-p/467787
If you are not familiar with editing code, the best solution is adding an app from shopify app store.
According to this page (http://blog.ivertech.com/blog/why-google-recaptcha-v2-or-v3-does-not-work-on-shopify-contact-form), Google reCaptcha v3 cannot actually be implemented on Shopify.
Since Shopify already implements Google reCaptcha v2 by default, there's really no need for you to implement v3. Some users from Shopify's forum who claimed that they were able to implement reCaptcha v3 successfully were mistaken. They were actually seeing the effect of reCaptcha v2 implemented by Shopify by default.
More details can be found from the link above.
Related
I have gone through the API documentation on the Dropbox website, and have found the section that relates to Paper, however I don't see a way to work with the TODO's for a document or a user.
Is this something that is not yet supported or have I missed it ?
The Dropbox API doesn't offer a way to interact with Paper to-do items unfortunately, but I'll pass this along as a feature request.
Is it a good idea to directly post content on google+ business page instead of sharing (adding) the link of a blog written by us?
Right now, the blog cannot be setup in the website. So, will posting informative content on google+ business page will be a good idea?
Dear
Maybe suggest to your client its done on a sub domain and even hosted elsewhere so blog.yourdomain.com
This have a couple of benefits, firstly google will know the blog is part of the site so credit it with the new content.
But one other thing is that if the blog is hosted elsewhere should there be a problem with the main site for what ever reason the blog would still function giving you a way to communicate with your users.
Its always nice to have a fallback solution and maybe offering them that might help.
good luck
Posting content to G+ is good idea. But you have more control on your own blog. Let's imagine some scenarios: 1. Google shuts down Google+. 2. Your content don't meets Google policy.
Our Challenges:
It seems to me The Polymer 1.0 developer community faces the following challenges right now:
We have no user auth UX example to follow. This Stackoverflow question requests a user authentication UX example. And describes why it's needed. This Github issue also documents multiple user requests for such a user auth UX example. And there has also been lots of anecdotal chatter on the Polymer Slack Site about this issue as well.
Modals don't currently work inside <paper-drawer-panel>. This open bug issue report, this Stackoverflow question and its accepted answer collectively prove that a bug requires <paper-dialog modal> elements must go outside any <paper-drawer-panel> element in order for the modal to render properly (i.e., in front of the modal's backdrop, not behind it). This issue report and this Stackoverflow question also verify same.
But modals inside panels have become the defacto standard auth UX design. It seems to me a principle of modern web app design that user authentication buttons (e.g., login and signup) go inside the equivalent of whatever version or "analog" of <paper-drawer-panel> any given web app happens to use. (Also, these auth buttons usually appear in the upper right corner of every screen of the app until the user logs in. Then they are replaced with an icon or link indicating login status.)
Code Examples:
Refer to the code examples contained here (in the question and answer). That code would be the same for this question too.
Question:
How do we, the Polymer 1.0 development community, best meet these challenges and build the best user auth UX experience possible? Perhaps there is a mistake in my facts or assumptions stated above? Perhaps someone has a direct (or workaround) solution they can share? Perhaps someone from Google's Polymer team would like to chime in? Any and all ideas, suggestions, feedback and answers are welcome.
On this bug report rubenstolk provides a hack-fix as follows:
To implement #dhpollack's hack in a nice way, add this function to your custom element:
// https://github.com/PolymerElements/paper-dialog/issues/7
patchOverlay: function (e) {
if (e.target.withBackdrop) {
e.target.parentNode.insertBefore(e.target._backdrop, e.target);
}
},
And add on-iron-overlay-opened="patchOverlay" to all your <paper-dialog>'s
I have tested it and verifies that it works. So for now, that solves challenge #2 in the question. Therefore, I suppose it is sufficient for now to wait until the bug is fixed.
I modified the PSK adding a login form, made out of a paper header panel, modifying routes for unauthenticated users and hiding the toolbar, by default.
This is done with
document.getElementById('headerContainer').style.display='none';
document.getElementById('mainContainer').style.paddingTop=0;
The UI reappears with
document.getElementById('headerContainer').style.display='block';
document.getElementById('mainContainer').style.paddingTop=168px;
This is just the beginning of a solution. For a complete solution, I would like an iron auth element supporting generic host and usual OAuth sites.
Is there a recommended "Polymer way" to do user authentication?
This question includes both the technical pieces AND the UX.
A soup-to-nuts example (and/or tutorial) of a UX for doing user auth would be fantastic.
Note: The Polymer Starter Kit does not contain any authentication UX examples.
In this question...
"UX" means:
The COMPLETE "user-experience" involved in signing up for a new account, logging in and handling forgotten user id or password. For example, a typical landing page for a typical web app will usually have some buttons in the upper right corner for signing up for a new account and logging in. What happens when someone clicks those buttons and how to handle the entire flow would be a very useful example for Polymer developers given that functionality is necessary for most modern web apps. I would love to not have to create my own amateurish "home-brew" concoction from scratch for a solution but, instead, to have something relatively professional and generic I can "plug-n-play" into my app and modify only if/when necessary.
You need to build a custom element with all the relevant styles, templates and scripts to express the UX.
The context is a desktop app using the client-side OAuth flow for authentication.
When I first built this app nearly a year ago, Facebook's documentation said to use the following URL to generate the login/authorization dialog:
https://graph.facebook.com/oauth/authorize?client_id=XXXXXXXX&redirect_uri=YYYYYYY
This is working right now. However, I've reviewed the newly updated Authentication Guide and now see that Facebook is saying to use:
https://www.facebook.com/dialog/oauth?client_id=XXXXXXXX&redirect_uri=YYYYYYY
Does anyone know what the difference is between them, and more importantly do I need to change it? Like I said, it is working now, but I'm a little concerned about something changing when the 10/01/2011 deadline comes around.
My second question is: Does anyone know what enabling the "OAuth Migration" setting in the Apps -> AppName -> Advanced page does?
The URLs redirect to each other. But still, please make the change to the new URL. Whenever the docs change urls and the semantics are the same, you should update so as to avoid unnecessary breaking changes. Even more so with desktop apps.
Second answer: That will issue you different access tokens for now.