Jump to content


  • Content count

  • Joined

  • Last visited

1 Follower

About websissy

  • Birthday 10/27/1950

Profile Information

  • Real Name
    Tom Blatt
  • Gender
  1. websissy


    Thanks for the candid reply, Jack. After pondering this situation carefully, I decided to remove SiteMonitor and rely on the web host's built-in security protections plus all the other security addons I've installed on this site to protect us as well. I began by building my own list of potential security addons. Then I carefully read spooks white-paper on how to secure an OSC site: http://forums.oscomm...howtopic=313323. Then I studied the white-paper on "How to protect an OSC site using .htaccess" by Fimble: http://addons.oscommerce.com/info/6066 And then I went back though my own list and adjusted it based on what these "recognized experts" had to say. Your patches were on my original list and survived that 'cuts' process too. As it is, the list of security features I've installed includes 14 distinct security addons varying from fairly simple to very sophisticated. That's not to say we're invulnerable to attack. NO site is! But we're as hardened as I could make the site using my 43 years in IT plus the wisdom and insights of some very smart OSC gurus to guide me. So, even without SiteMonitor's protections, we're not exactly running naked in the woods here. Frankly if I was an attacker and encountered all the security barriers we've raised to protect this site, I'd give up and go elsewhere looking for an easier site to crack. That's what I'm hoping anyway. We'll see. Frankly, I'd love to be able to install and run SiteMonitor too, Jack. However, I'm unwilling to begin jumping through burning hoops backwards while blindfolded in order to get there. Thanks VERY much for your help!
  2. websissy


    I have a hunch I know what's going on here. After experiencing a series of hacker attacks and server invasions involving OSC sites they hosted, our webhost finally got to the point a few months ago where they restricted certain things some php programs try to do and blocked PHP's ability to do them. For instance, they now deny ANY use of the exec command by PHP apps to avoid having a program that's running at an owner-privileged level from executing certain system commands. Another thing they may also do is to block the ability of programs to create completely new files out in the server's directory space where none existed before (e.g. in your case, creating what amounts to a brand new sitemonitor_configure.php file (okay, granted it's named sitemonitor_configure_1.txt; but the behavior is still the same) where none existed before. Even you have to admit that's a fairly unusual behavior. They've done this in part by restricting access to certain php and shell functions. I suspect that's the underlying cause of this 406 error problem. As soon as the SiteMonitor programs try to create a completely new file in this manner, permission is being denied and the result is this 406 error we're seeing. Since these are deliberate server-security meaasures designed to block certain questionable behaviors, I suspect I'm not going to be very successful in convincing them to be more permissive in this case. In short, I suspect the way you're handling the sitemonitor_configure.php file may be being treated as an invader/hacker-type behavior. Question, beyond the site_monitor_configure_#.txt (which apparently gets created in shoproot/ADMINDIR/includes and the reference file (which gets created precisely WHERE, please? And can you show me what a new empty reference file looks like?) does the SiteMonitor software engage in creating files out in the server's file space like this in ANY other places? Or if I were to provide those (correctly configured) files manually is it possible the software will go along and be happy and not engage in any more 'naughty' behavior of the same type? The bottom line is if SiteMonitor makes a practice/habit of creating files out in the server-controlled directories, then if my hunch is right, it's never going to work on my server. But if it's only these two files that it creates in this way, then I've at least got a shot at making it work correctly except during the configuration and setup process. You know the software. Is this something SiteMonitror does a lot throughout its code? If that's the case I might as well give up and abandon my efforts to install your addon right now. If it's not, then I may be able to work around it and still get the benefit from your code. I eagerly await your reply. Thanks.
  3. websissy


    Jack, if this is helpful at all, this site is running OSC v2.2 RC2a. It's also using a non-standard (locally assigned) name for the admin directory Here's what the sitemonitor_configure_0.txt looks like as I uploaded it. The name of the admin directory and the shoproot directory have been changed in this code.. to mask our real filenames and locations: <?php /************** THE OPTIONS AND SETTINGS ****************/ $always_email = 1; //set to 1 to always email the results $verbose = 1; //set to 1 to see the results displayed on the page (for when running manually) $logfile = 1; //set to 1 to see to track results in a log file $logfile_size = 100000; //set the maximum size of the logfile $logfile_location = 'sitemonitor_logs'; //enter the name of the directory to store the log files. The directory is required to be in the admin directory $logfile_delete = 30; //set of days to wait before a previous log file is deleted - leave blank to never delete $reference_reset = 3; //delete the reference file this many days apart $quarantine = 0; //set to 1 to move new files found to the quarantine directory $to = [email=""]'sheila@ourdomainname.com'[/email]; //where email is sent to $from = 'From: [email="webmaster@ourdomainname.com"]webmaster@ourdomainname.com'[/email]; //where email is sent from $start_dir = '/home/ourdomaindir/public_html/shoproot/'; //your shops root $admin_dir = 'http://ourdomainname.com/shoproot/manage/'; //your shops admin $admin_username = 'LeadAdmin'; //your admin username $admin_password = 'adminpassword'; //your admin password $excludeList = array('cgi-bin'); //don't check these directories - change to your liking - must be set prior to first run $hackIgnoreList = array('jpg', 'jpeg','gif','png','txt','zip'); //don't check these types of files - change to your liking $hackCodeSegments = array('error_reporting(0)', 'base64_decode','<iframe','gzdecode','eval','ob_start("security_update")', 'Goog1e_analist_up', 'eval(gzinflate(base64_decode', 'Web Shell', [email=""]'@eval'[/email], ' header;', 'shell_exec', 'system','SetCookie','Meher Assel', 'nt02', '<script src','r57shell','createCSS','auto_append_file'); //enter any hacker code that you would like to check for ?> I'm running PHP v5.2.17. There's nothing especially unique about our site's permissions. In fact to eliminate that possibility while trying to figure out the cause of this problem, I ran check permissions and allowed it to update all permissions to the defaults it recommends. Can you at least tell me the name and intended directory location of the file the sitemonitor_configure_setup.php utility is trying to create? It seems to fail as soon as I click the update button in sitemonitor -> configure Finally, if I pay you to install this addon will you devote the effort to figure out what is wrong and how to fix it? P.S. it may be helpful to know we have several security-related addons installed on the site (over a dozen) yet, this is the ONLY one I've had this sort of trouble with... Thanks! Best, websissy
  4. websissy


    Hello. I've got v3.0 of the Site Monitor software installed on my 2.2 site and had no particular problems doing so up to step 5. However when I try to run the configuration utility for the first time and update the settings in step 5, I get a 406 error which produces the following error mesages in IE and Firefox... IE Internet Explorer cannot read this webpage format HTTP 406 What you can try: Go back to the previous page. More information FireFox: Not Acceptable An appropriate representation of the requested resource /carthome/admin/sitemonitor_configure_setup.php could not be found on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. Other relevant info: Permissions on sitemonitor_configure_setup.php 644 Permissions on sitemonitor_configure_0.txt 755 Permissions on /carthome/admin/ 755 I've double-checked everything several times. From what I can tell, I've done nothing wrong. Yet the site monitor setup utility fails every time in both browsers. Can anyone tell me what I have overlooked? Thanks.
  5. websissy

    IP trap Version 3 released

    I recently installed IP_Trap on a client's 2.2rc2 site. The installation went well; but when I tried to test I found that (as others have reported), I was also being redirected to the store's ../index.php whenever I tried to visiit "catalog/personal" rather than being banned. After analyzing the code a bit, I realized there was a loop through the whitelist file built into "catalog/personal/index.php" that redirects the user back to "../index.php" if a match on the IP address is found in the "banned/Whitelist.txt" file. Yet, I was SURE my IP address must NOT be in that file and a quick check confirmed I was NOT there. Puzzled by this situation, I then made a small patch to the "foreach" loop code which originally looked like this: foreach( $ipw as $whiteip ) { $test = strcmp($whiteip,$ip); if($test == 1) { header ("location:"."../index.php"); exit; } } foreach( $ipw as $whiteip ) { $test = strcmp($whiteip,$ip); if($test == 1) { // header ("location:"."../index.php"); print $whiteip . ' ' . $ip; exit; } } To my great surprise when I tested using this code I found my new "print" command produced the following... 8.6.48 In short, my IP address ( was producing a false positive match in the Whitelist.txt file with the IP string (8.6.48) ? Say WHAT? So I then removed the (8.6.48) IP address from Whitelist.txt and tested again. To my surprise I was banned as I should have been earlier in the very next test. I noted that one user theorized he thought the cause of false positives in the Whitelist.txt file issue was ANY 3 part IP address, while another suspected the cause of false positives might be the failure to include a standard DOS line-ending CR/LF pair at the end of each line in the Whitelist file. So checking further, I found that the foreach loop had NOT gotten false postives on ANY 3 part IPs that occured in Whitelist.txt BEFORE the 8.6.48 IP address appeared, I also double-checked using a hex-file-editor and confirmed that there was a standard DOS CR/LF pair character on the line in Whitelist.txt containing 8.6.48 AND on all lines before and after that. After checking and confirming 8.6.48 was one of the IP blocks used by the google spider, I decided I could NOT leave that IP block out of Whitelist.txt. Lacking any further explanation for why the FOREACH loop concluded 8.6.48 was the same as, I decided to relace 8.6.48 with the 255 IP addresses from to That didn't work either because was "judged" the same as! So much for the theory the problem had something to do with 3-part IP addresses! Next, I tried changing my IP address to see what happened. That resulted in my NEW IP address matching an entirely different 3 part IP number in Whitelist.txt. Arghhhhh! Then I took a deep breath, stopped, sat back and thought about the situation for a minute. By definition, if a visitor is wandering through these directories they're disobeying my stated robots.txt rules. AFAIK, NO spiders should EVER be allowed to disobey those rules. Frankly, I don't want to grant ANY spider... even Google's spider -- a "pass" if it's trying to search my forbidden areas. So in the end, I decided it was best to delete ALL rows in Whitelist.txt and thus block every visitor that tries to access those areas. Conclusion for FIMBLE: At best, this Whitelist code is buggy as hell and needs to be totally rewritten so that it's reliable. Question: Am I overlooking something critical here or thinking about this blocking disobedient spiders situation wrong? If so, can someone please explain why I need this Whitelist feature at all? Thanks!
  6. websissy

    Margin Report v2.10

    Hurray! :D After days of carefully installing new versions of margin report and testing and finding bugs and fixing them and retesting until I got the code for each version working right, and then starting over again and applying the next set of updates, I've finally managed to get Margin Report working 100% right all the way through v3.0b as far as I can tell. It even records product cost into the order-products table when the sale takes place (like it was designed to do). It also calculates the correct margin percentage for each order, and accurately reports sales for today, yesterday, this week, last week, this month, last month, this quarter, this half year, year-to-date and "forever-to-date" (i.e. all orders) too. It does NOT however, attempt to handle price adjustments based on product attributes (size, color, etc.) Not even Abysynth's v3.0 patches to the original v1.0 code were getting product costs recorded into the order-products (a.k.a. order-items) table correctly; but my cart does that too now. At this point, I think I could even add daily, weekly and monthly sales reports, cash sales reports, credit card sales reports, weekly, monthly, quarterly, semi-annual and annual sales AND gross profit reports and Cost of Goods Sold reports. Reports of sales, costs and margins by manufacturer / supplier / vendor and other reports are possible as well. The fact is I found most of the answers to the bugs I identified right here in this forum thread. So, if I can do it at age 60, you can too, folks. Furthermore it's a worthwhile project to undertake; because in the process I've learned a lot about where the data resides and how the tables are structured and how the mysql queries work with PHP to make all that stuff work together. So far, I've successfully installed the OSC product, designed, installed and tested my own custom OSC template that's used throughout the new site I'm building, installed, tested and successfully implemented Dynamenu, installed and tested Simple Category Descriptions, Enable/Disable Categories, Easy Populate and Margin Report. At this moment I feel like I own the world. B) But tomorrow morning, there'll be a new mountain to climb. My next project is Orders Tracking. Then its Quick Books Interface, OllaCart and Ultimate SEO. Other than that, I've got basically nothing to do here... :'( Wish me luck! :-"
  7. websissy

    Margin Report v2.10

    sjnelle is right. The way the code was written on a multi-item order the margin percentage reported for the whole order was actually the margin percentage for the last product on the order. To make things worse the old formula rounded off the last two digits of the calculated margin percentage. That caused a 47.51% margin to be reported as 48% and a 32.49% margin to be reported as 32%. sjnelle's fix fixes the problem.
  8. websissy

    Enable/Disable categories contribution

    I struggled all day today to get this contribution and all its updates installed. Just when I thought I was finished, my tests turned up this *&^$%#@ error: 1054 - Unknown column 'p.products_id' in 'on clause' I fought this one for 4 hours until I had cross-checked everything and was convinced I had made no errors in applying the patches. Finally, in frustration, I came here looking for an answer and there was YOUR answer posted here just 10 hours ago. Hallelujah!! And thanks for saving my sanity! :thumbsup:
  9. I downloaded Linda McGrath's Attributes Copier & Sorter V5.0 from this site and carefully followed her step by step install instructions until I reached the program compare step. Now, I'm stuck! I'm running source code version 2.2ms2, and the version her patches were written for was an earlier release of the code than I have. So, my programs are later code versions than the ones she made her changes to. In short, I can't tell which changes from the patched older release of these programs she provides should be moved forward (as Her enhancements) and which ones should be left behind as obsolete code. Arggggh! It's impossible for me to distinuish her changes from changes made to the version I received. The four programs with extensive enough changes that even Linda says they should be compared include: /catalog/product_info.php - I have v1.97 ? 2003 - She had v1.87 ? 2002 /admin/categories.php - I have v1.146 ? 2003 - She had v1.138 ? 2002 /admin/products_attributes.php - I have v1.52 ? 2003 - She had v1.48 ? 2002 /admin/includes/header.php - I have v1.42 ? 2003 - She had v1.19 ? 2002 Can anyone provide instructions for applying Linda's patches to the 2.2ms2 version of this code? I can't do anything without guidance about how to apply her changes to the current release! :-( I do have backups and can roll back... but I've done everything except this final step!! Can anyone help me? Please... Thanks!
  10. websissy

    Help on:

    I'm reading Mike Graves install doc for Attribute Manager v4b In the readme file he refers to "Attributes Mod version 2.02.MS1 by countezero". I have been unable to find this mod or identify this user on the osC site. :huh: Since the Attribute Manager v4b Mod appears to rely (at least partially) on the presence of this mod, can anyone tell me where to find it? :-" Thanks!
  11. websissy


    Hello, tlynch! Congratulations on your success with this Authorize.net connection problem. :thumbsup: I'm new to this and am although I've got 35 years in the computer biz, I'm not much of a PHP hacker. However, I will definitely be needing to connect my store to Authroize.net as soon as I get everything else working. If you believe you've solved this problem, would you please post detailed before and after snapshots of the code changes you've made or at least a step-by-step guide to on the order of "open this file", "find this text", "make this change" hack instruction? Frankly, some of us will never be able to do what you've done without such guidance. Thanks! And again, congrats... :)