i have Fontis reCAPTCHA installed and it has been double checked by another developer to be working. but i keep getting fake customer registrations - about 2 or 3 a day.
they are like this:
452 sesBesIdete sesBesIdeteVQ v.e.ronikalikes#gmail.com
451 Monicarj MonicazcGF Gutermuth#daolemi.com
450 Reennadix ReennadixZB aldenrivas24#yahoo.co.uk
449 Ommett24 Hmmett67OM Demoura#daolemi.com
any way to stop this?
This may sound obvious, but what happens when you try to submit a fake account? I realize that you have the reCaptcha on the site, but how was it implemented? Does it protect the site if someone submits a form externally?
If you had someone apply reCaptcha without using an actual Magento extension then you may want to consider this one:
http://www.magentocommerce.com/magento-connect/Fontis/extension/1169/fontis-recaptcha
FWIW, upgrading to next version fixed this issue ...now at 1.6.2
Related
One quick question. As of last week I had completely setup the AEM SDK with the Venia store front with all the components working. When I move the setup the AEM publish SDK, I am encountering one issue.
The /api/graphql is throwing 403 errors which means no frontend commerce operation is happening on the storefront.
I tried adding the /api/graphql to the CSRF filter's exclude list and even removed the POST method from there.
After this I still 403 on GET request of /api/graphql and the following on POST request.
I am I missing some setting?
Note: on the sling servlet resolver config, I have added the /api/graphql but there is no change.
There is a query very similar to this on the groups but there is no response. So thought of raising it here.
https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/aem-cif-magento-on-publish...
Please let me know if I am missing something.
Issue solved.
I introduced a var called COMMERCE in the global vars to solve the problem, since the vhost file refers to it.
I could have done it slightly better but I guess i was lazy :)
Please refer to this link for details:
https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/aem-cif-magento-on-publish/m-p/442185#M31799
I just pushed my new updates on play store and all over sudden am getting this error, I have tried to research online for answers but I get non, any help what this error means and how to fix it?
Any help and guidance on how to fix this is highly appreciated
I'm glad to see others have been impacted and it was not just me!
It seems to be a bug with the Google review system. Best thing to do is contact them via the link to their form in the footer of the email you received.
Update 2:
I did not take any action and passed the review process today.
Update 1:
I received the reply I have screenshot below, which does not help much. I asked what the notification was about and he did not address the issue at all, so now I don't know what to do. However he did confirm that my app was currently in the review queue, so maybe we just need to wait. Maybe the email notification with errors can be ignored. I will wait a few days to see if my app passes review without taking any further action.
I've just updated my Data Safety forms adding Device or other identifiers because my app request Ad Id, BSSID etc.
I've faced the same issue, and the solution is :
You need to check if you're using third-party libraries (in my case, IronSource and AdMob) that collect the user data.
If you're using IronSource you need to fill the Data Safety from here :
https://developers.is.com/ironsource-mobile/general/google-data-safety-questionnaire/
After you fill the Data Safety, hit the save button and wait for the review to complete.
I currently have a Magento site version 1.9.1.0 and have the "Front controller reached 100 router match iteration" reports. It's bringing down the site several times a day.
I have followed the steps in this post Magento "Front controller reached 100 router match iterations" error
and when the site went down last I believe the controller that seems to reappearing is the '/admin' path as shown in
2015-09-19T16:55:02+00:00 DEBUG (7): ----Matching routers-------------- ----------------
2015-09-19T16:55:02+00:00 DEBUG (7): Total 7: admin, standard, install, wordpress_addon, cms, wordpress, default
2015-09-19T16:55:02+00:00 DEBUG (7): - Iteration 1
2015-09-19T16:55:02+00:00 DEBUG (7): Request: [path_info=/admin] [module=][action=][controller=][controller_module=][route=]
There is redis, varnish and memcache also running and the cache is saved to the database. When the site goes down I restart these services and it will fix the problem temporarily but obviously this isn't the solution. It also seems that the more I restart the services, the more it happens. This problem happened about a year ago and in order to rectify it, these were added and the problem seemed to be fixed but now has reappeared (badly).
I also found this post http://magentosupport.help/knowledgebase/solved-front-controller-reached-100-router-match-iterations/ which I have gone through each step and checked each one but still the problem hasn't been fixed.
I was going to try this patch https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-good-news-a-patch-from-magento
but my hosting company told me it wouldn't work because it doesn't apply to my version.
The site has multiple stores and lots of additional extensions, I would really appreciate it if anyone could give me any advice because I am desperately stuck.
Kind Regards,
I have been searching Google for hours regarding a nasty bug in Magento 1.9.1.
I'm using the demo setup to show the possibilities of Magento for several customers.
One customer has sent me an email she couldn't create an account.
Ok, I thought and tried the same thing and guess what... I get an error telling me "Please make sure your password match".
I already "patched" the Customer.php file by changing $confirmation = $this->getPasswordConfirmation(); to $confirmation = $this->getConfirmation();
This resolves the checkout issue which has the same bug.
But this doesn't resolve to make a new account to use with Magento.
We had several update bugs with updating 1.8 all the way to 1.9 and now a bug in a fresh installation.
Are there developers out there which have fixed the account issue too?
Please let me know.
Steve
Copy /app/code/core/Mage/Customer/Model/Customer.php to the local
Search for function validate()
Comment //$confirmation = $this->getPasswordConfirmation();
Insert $confirmation = $this->getConfirmation() ? $this->getConfirmation() : $this->getPasswordConfirmation();
This would resolve the issue for registration and checkout as well.
To solve "But this doesn't resolve making a new account to use with Magento." you need to recompile ( or turn compiler off)
I have tried your solution but compilation is not used.
What I did was install a clean Magento installation and guess what.
I can register a new account and I can use the checkout without problems.
It seems that the demo installation provided for free from www.magentocommerce.com doesn't work as it should.
Br,
Stevan
Recently transferred my Magento 1.7 store to a new host, and started having a frustrating problem.
We've got the store sitting behind a login shell - you can see it at http://www.seacadetshipsstore.com. Base exchange takes you to the root store (/magento/), and the gearlocker login takes you to a secure sub-store (/magento/gearlocker/).
The problem is, ever since transferring to the new host, /magento/gearlocker/ is sporadically redirecting to /magento/. I can only reproduce it 1 in every 10 times, but customers are constantly complaining that they can't access the secure store for this reason.
I've also noticed that if I turn off the security and have clients navigate to /magento/gearlocker/ directly, it seems to fix the problem for most - they no longer get the redirect after logging in. Only a few of them still have the error, and they're all PC users on various browsers.
I've set up a demo login for stack:
https://www.seacadetshipsstore.com/login.php
U: stack_login
P: thanks
I doubt it's an issue with the base url or base link url, otherwise the error would be much more consistent. I've gone through magento's official tutorials and made sure the secondary store was set up properly (remember, it was working fine on the old host). I also know it's not anything to do with the login shell - all it does is validate the user's login and redirect to /magento/gearlocker/.
Can anyone reproduce this error? Can anyone tell me what's going on, or how I might fix it? Thanks in advance!