Yes, I know I shouldn't be on 1.6, and we're in the process of upgrading.
Regardless, the site I'm working on its getting is registration form spammed, even after I added a honey-pot field. I'm not sure what this spam bot is doing, definitely not how it's getting round the extra field, and I'd like to stop it. Can anyone help?
note: Patching the site is not an option because it was super customized and the patches don't work.
As you may know Mage_Captcha is available only from > 1.7. You have to options:
Try to port Mage_Captcha to 1.6 als local module
Implement your own custom module
for second option see tutorial here https://www.gomage.com/blog/captcha-module-for-registration-in-magento/
Related
I am currently working on a POC and made quite a lot of progress thanks to IT-Hit WebDAV Library.
However, I am currently stuck at the authentication. I am using the "OnBeforeRequestSend"-Hook to add my authentication header containing my current access-token. This approach works very well for all the request coming from my webapp.
Nevertheless, the problem I am facing right now is, that I lose the authentication-token for every request from the webdav-client...
In order to tell the webdav-client apart from any other website, I thought about using the User-Agent-Header to determine what behavior the server is going to exhibit.
To be exact: I thought about only checking the token when the user-agent is not "Microsoft Office ...".
Since this solution seems very error prone, I wanted to ask If there is another way to pass the authentication-header from my webapp through the webdav-client to the webdav-server, so that i can validate/verify every request to webdav-server independently of the source (webapp or webdav-client)?
My current stack is:
WebApp written in TypeScript
WebDAV-Server written in .Net
thanks and best regards,
greenbird
Look into implementing MS-OFBA, this will work as you desire.
Successfully build Commerce 2011_7 with Spartacus 3.3 last week (using the standard instructions for B2B Commerce) and all appears to function on initial tests.
This week, I've gone to test the Standard Order Flows with mark.rivers#pronto-hw.com and noticed that the "Self Service" buttons that typically appear against a placed order in My Account are missing, and these are definitely there in the JSP Storefront and earlier versions of Spartacus.
I'm able to follow the instructions but not a developer so asking if anyone knows whats causing them to 'not appear' and could help me get them back please - have supplied a screenshot with the Console open as well.
The two lines in the console that concerned me were:
spartacus-storefront.js:18398 No component implementation found for the CMS component type 'AccountOrderDetailsOverviewComponent'.
Make sure you implement a component and register it in the mapper.
spartacus-storefront.js:18398 No component implementation found for the CMS component type 'AccountOrderDetailsReorderComponent'.
Make sure you implement a component and register it in the mapper.
enter image description here
order self service was added in 1.4 but you need release 2005.
see https://sap.github.io/spartacus-docs/cancellations-and-returns/
it's possible that with installation of 3.3, the cancel/returns code wasn't installed? we transitioned to many smaller libraries for 3.3. but also you need cms content in the backend (which looks like you have).
That's a quite puzzling problem. I've multiple MediaWiki installations. In this specific case: Version 1.34.
Now I can login to all of these MediaWikis. Everything works fine.
Now I can access all of these MediaWikis via API --- EXCEPT ONE. The strange thing is: All of them are configured almost identical. I even copied the configuration from one wiki where everything was working to the second wiki.
To be more precise. If I send ...
/wikiA/api.php?action=query&meta=tokens&format=json&type=login
... I get a very reasonable answer, e.g.:
{"batchcomplete":"","query":{"tokens":{"logintoken":"37ec2e690eeb48a10ac66b2ccbca2b576000f9f4+\\"}}}
If I send ...
/wikiB/api.php?action=query&meta=tokens&format=json&type=login
... I get the following answer, e.g.:
{"error":{"code":"readapidenied","info":"You need read permission to use this module.","*":"See http://xxx.xxx.xxx.xxx/wikiB/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."}}
This can be reproduced using any web browser.
Q: What could be the reason that on this wikiB I even can't access the normal login module? It can't be the configuration. It's almost completely identical. It can't be the source code. I ran a diff on the PHP files and found no significant differences. What could be wrong here? It seems it must be something with the database. But how do I approach this? Does anyone have an idea? I would appreciate it very much if you could help!
I analyzed the data base: No difference. I did more research using google: And found a bug report.
It's a bug in MediaWiki. They provided an official software release with THAT kind of bug.
It turnes out there is a 1.34.0 version and a 1.34.1 version. My WikiA has 1.34.1 while WikiB had 1.34.0. After copying this one single file includes/api/ApiQuery.php from WikiA to WikiB and everything worked fine.
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/580097/
I need a little help here, i hope someone here can help me for a hint or clue.
First of all, I'm not programmer. I'm just web admin who can use cms and basic html.
I was using PrestaShop for my online shop. In the backend, I can't upload new product image anymore.
The error just blank without any sign for me. Here for the screenshot:
I appreciate it, if someone can help me, thanks, and sorry for my english.
#PanjiWiyono This errors don't really give us a quality information, but this is a start. In your JS code should be a ajax query that has an error when converting results to json (first error). You should check what's the exact error that this request is returning by inspecting in browser developer console.
If you detect that the second error is in fact, the response of this ajax query, well now we almost have the problem.
The second error should be related to data size. Check this: Error while sending QUERY packet
Anyway, you should check DbPDO.php class. You can use debug_backtrace function to display the complete stack, but definitly if error is related to a basic PHP class issue you will have not help knowing wich classes are in calling stack.
Good luck.
Simple solution
maybe a extra module is in a conflict with the prestashop core files. go to advanced parameters, performance and disable third party modules and try again.
other option is reupload admin folder with other name and
js folder check again
hope it will work for you
I got problem with my company internal extension. They don't want to publish it, as it does gather data on external server. So I need to host it myself... but would like not to lose ability of autoupdate.
As far as I read I need to use update_url in manifest, but nothing more is said in Opera documentation...
"update_url": "http://path/to/updateInfo.xml", - as it is said in documentation page
Ok... and what should I put in that xml? Will it autoupdate or just notify users about new updates? Where do I put rest of updated files?
I tried to concat Opera itself about this question, but they don't give any contact information except something like if you have problem, ask on stackoverflow... so here I am.
If it does not work, I was thinking about really BAD method, using unsafe-eval and keeping newest version in local storage... but would rather like to avoid that.
In general the behavior is the same as for Chrome. You can base on this document: https://developer.chrome.com/extensions/autoupdate