altoid

I will do that. Thanks for the assistance.

Hello, today I checked my banned IP page and found this IP: 127.0.0.1. It was banned by my system on 2010-08-21 at about 0230 hours. However on the PHPIDS log there was nothing corresponding to this, nor did I get an email notice about any type intrusion. I googled 127.0.0.1 and see it is something known as a loopback address. From what I read, this is basically something not to get worked up over. Some snippets of what I read are: 127.0.0.1 is a reserved IP address corresponding to the host computer. Known as the loopback address, 127.0.0.1 is used whenever a program needs to access a network service running on the same computer as itself. Anyway, I was wondering what, if anything to do with the IP now on my banned IP list. Thanks

Like Jim said, each one has it's instructions, but if you are really, really, really new, you probably need to know some fundementals. Like do you have an FTP program and a decent text editor?

Hello, with Anti XSS removed now from my system and Security Pro installed as per instructions in PHPIDS read me, all appears OK. However I have noticed that when I am run Site Monitor, there are 18 files that keep recurring in the report even after I delete the Site Monitor reference file. The recurring files are located in these directories: includes/phpids/lib/IDS/tmp/ includes/phpids/lib/IDS/vendors/ I found I can get them to stop appearing in the Site Monitor report if I exclude them in the configure part of Site Monitor, but I thought I'd mention the situation for discussion sake. I am presuming there is something dynamic about these files that make them constantly change, perhaps that's how they work. Thank for your assistance.

Since posting my observation I removed XSS [XSS Shield] and reran test 2. That error page I asked about disappeared on the second run; and the module functioned as it was supposed to. Thanks much.

I want to make sure I follow the logic on this. With Anti XSS [XSS Shield]installed, that code would stop the intrusion and redirect to a 403 page, but also stop the code short of allowing PHPIDS to function, do I have that correct? With Anti XSS [XSS Shield] removed, PHPIDS will then process an injection, do its job but in at least some cases, the script would still run in application_top.php and allow Security Pro to sanitize the string as well. Is that accurate? Thanks much.

By going in through phpMyAdmin and manually changing the origin row to null as follows: origin varchar(15) latin1_swedish_ci Yes NULL I was able to get this to work. However for the second test: ?test="><script>eval(window.name)</script> When I run this I get Forbidden You don't have permission to access page_name.html on this server

Thanks for the clarification of the 404. I really appreciate what you do for us here.

Jack, thanks for the update. I just tested this with some duplicate meta descriptions and duplicate title tags that were flagged in my google webmaster tools. Such as..... /-c-0_136.html /-c-0_182.html /-c-0_32_62.html /-c-0_43_179.html /-c-0_43_53.html /-c-0_43_55.html /-c-0_43_56.html After the update these are all now redirected to the index page, which should take care of those duplicate situations if I understand the concept correctly. Thanks

Maybe this will be of help to someone. I am in the process of catching up on my sitemonitor versions and was getting the "....failed to open dir: No such file or directory...." error. Turned out it was my error, where the instructions for upgrading say 1) Upload all of the files except for sitemonitor_configure.php in the included admin directory to your admin directory. I blew right by the "except for sitemonitor_configure.php" part. When I figured out what I was doing wrong, and went back the install/upgrade worked fine. Note to self: Read instructions....follow instuctions....read instructions....follow instructions

Jack I have installed 3.2.3, it's running well. Thank you. In particular I appreciated the modified code so this would work with Sam's Remove-Prevent duplicate content add on, and I appreciate the html editor update in that I use fckEditor. I am still trying to figure out the duplicate meta tags I get with All-Products when Google crawls by alphabetized category. Meaning <https://www.mystore.com/all-products.php-by-A.html>, <https://www.mystore.com/all-products.php-by-B.html>, etc. But for now that's on the back burner until I let Google crawl over the next couple weeks and see what they come up with for duplicate content issues. I will revisit that then. Anyway, thanks very much.

Well on the bright side of things I have had IP Trap installed for quite a while and snagged several intruders. Doing an IP whois search on the intruders, I usually don't find out much other than where the nosey person was from. Today got a good one, my IP search for today's intruder yields results that that IP was involved located in eastern Europe and associated with many porn related sites. Just guessing but I think this visitor was hoping to plant code on my site creating links back to the porn sites. I am very grateful Nic provided this add on to help protect from that kind of thing. :thumbsup:

Sam, I have the Anti-Hack Mods Add On installed and all appears to be working as it's supposed to. Great and thank you. My question is that I also have this other PWA add on installed. Do I deduce correctly from your comments posted here and the docs that the Anti Hacker PWA is independant of that other PWA; so I can therefore tidy things up in my shop by removing a couple database mods and file changes that were specific to my original PWA? Apparently they are not causing any conflicts that I see but if I don't need them I'd like to remove them for housekeeping sake.

This fix also worked for a similar problem I had with PayPal Standard. The coding is not exactly the same from IPN to standard in the respective files but the concept is there and I successfully made the adjustments to solve the issue for PayPal standard. FYI if someone using PayPal standard runs into this.

Peter, or anyone else who may be able to assist, thanks to help from Peter I have QT Pro working with AJAX attribute manager. I am managing the quantities via AJAX Attribute Manager but would like to have quantity management capability in QT Pro also. There are a couple parts of QT Pro not working for quantity updating but the one I want to focus on fixing for now is in admin->reports->stock report. When I click on a product it takes me to "http://www.myshop.com//adminfoldername/stock.php?product_id=409" for example. QT Pro Doctor says all is OK. But the part of the page where you can update quantites by attribute won't work. I can select an attribute from the drop down, enter the quantity, but when I click ADD I get an error page. Apparently what is happening is the web store address is not being picked up because the URL only shows: "http://adminfoldername/stock.php?option2=1&quantity=2&product_id=409&action=Add" Any ideas?

I did the www.mysite.com/googlebase.php test and got a blank page after setting SEO to true. Switching it to false generates the correct data. What I really needed was to get this working with my one shop via the htaccess coding technique. It is working so now I can schedule uploads on the google base site accordingly and that's good to go. Thanks for working on this and keep on keepin' on. SK

G: I had the delimitor set to tab in Google Base. I just uploaded your update and first run, it worked, all items uploaded. I have Ultimate SEO Urls (Jack's version) installed so I set the enable for that to true. Doing that I got 0 of 1 uploaded. Resetting back to false I got the full upload. Thanks much

Jack here is that follow up I promised. It was a problem with my server system. The "tier two" support tech determined that a service they provide called "ShopSite" had been activated and was causing a directory conflict with the public_html folder where my osC store resides. I don't use ShopSite so my hunch is that the tier 1 tech support did that when working on my report of sluggish website symptoms. The timing of the problem I brought up here matches exactly when tier 1 was working on my problem. Anyway, SiteMonitor is functioning normally now, just wanted to let you know the outcome. I thank you for this valuable add on and several others I have installed in my shops. Keep up the great work.

Jack, I confirmed the path is as on the admin->Modules page. I am turning this over to support at my host and see what they come up with. I will post the outcome here. Thanks

I am leaning towarded a host permissisions issue because this only started occurring a couple weeks ago and I didn't change any configuration settings until I saw the root issue brought forth in this topic. But I am not sure. The extra slash keeps getting regenerated even though I try to clear it in configuration. Meaning if I clear the extra slash in configuration, update the page the extra slash is gone. But when I go to admin and come back to configuration the extra slash is back. The same thing occurs if I remove both slashes. Set no slashes-->Admin --> Configuration and they are both back. The start directory entry is a direct copy/paste right from my hosts site over to configuration. It is the same path automatically generated by Site Montitor. If it's not a securty risk I can post it here with all buy my username. I have yet to learn what curl is, thus my Admin Directory, Username and Password are blank. When I look up curl on my host site I get directed to this: Question/Problem Configuring: Available PEAR packages Answer/Solution PEAR (PHP Extension and Application Repository) is a framework and distribution system for reusable PHP components. The following PEAR packages are available on our platform. Thanks

Jack, I am having a similar issue but apparently with permissions. Warning: opendir(/document/root/directory/path/myusername/public_html//store/) [function.opendir]: failed to open dir: Permission denied The "/store/" is actually there and confuses me a bit but in configuration the root is correct, the above modified for example purposes. To verify, my host control panel gives me the correct document root, which is what comes up by default in the configure page of Site Montitor This glitch occurs on one of my two stores, both on the same server run with two separate accounts. The current problem store is with a ssl certificate. The non problem store has no certificate if that matters, I am just mentioning it. Suggestions? Thanks

Thanks for responding I had it with /public_html/ which probably explains why my pop up images are appearting in google webmaster tools as duplicate title and decription tags. I have now changed it.

It isn't so I won't use it. Thanks for responding.

I googled this issue and the hits didn't come back with, for me at least, a definitive answer so I am asking here. My osC shop resides in my server's public_html folder. In that folder, top level resides the robots.txt file. Question: is the correct cirectory syntax for robots.txt in the public_html folder.... Disallow: /account.php or Disallow: /public_html/account.php Thanks

G: I got an error after a few trial uploads after I did the install of the new file. I have about 151 products, but the errors on both tests indicated "0 of 34" products inserted. The error seemed to be with an incorrect number of tabs. That's what Google said. I had /t set. The error indicated that the pipe | was detected. When I revert to the earlier version of googlebase.php I had installed it runs OK. I am willing to continue testing this in that I'd like to get this running so I can try it in another on line shop I have. Right now I am stuck running that second store manually because the htaccess approach won't work there for some reason. Thanks