Zen Cart – 403 error

Home Forums BulletProof Security Free Zen Cart – 403 error

Tagged: 

Viewing 11 posts - 16 through 26 (of 26 total)
  • Author
    Posts
  • #10089
    AITpro Admin
    Keymaster

    Yes, that is exactly what I was looking at instead of the dot (.) issue that was very confusing and had me looking in the wrong place.  It should technically work, but you mentioned in your email that you have done some additional custom things.  Specifically you are somehow calling wp-load.php in Zen Cart.  Logically this could be doing something like confusing your main WordPress website as to where WordPress is actually loading from.

    Okay.. I am making a call to wp-load.php in Zen Cart, but this only is there so that I can use WP shortcodes in Zen Cart.

    That was the main reason I had you try adding RewriteBase to the /pub .htaccess file.  Normally what RewriteBase will accomplish is to force all rewriting to ONLY the RewriteBase you add in that .htaccess file.

    There is another factor going on here as well.  You are disguising/hiding the URL in the Browser so the final URL actually downloads from the main WordPress site’s URL without having the full URL path to the actual displayed.

    So considering all of these things/factors above the conclusion I get from all of these things is that WordPress does not and cannot differentiate between your /pub folder/site and your WordPress folder site.  You have somehow managed to force something that I did not think is possible.  So I assume the side effects of this are that Rewriting is totally out of whack – to put it in laymans terms.

    So the dilemma is this – how do you continue to disguise/hide the download URL and once again get control of and compartmentalize your separate websites.  Since you are forcing them to be combined somehow then you will now need to figure out how to combine them, but also keep them separate in order for rewriting to work correctly.

    Without knowing every single factor in your setup/this equation I can only generalize what I see as the overall issue/problem.

    #10108
    DivaVocals
    Participant

    I have WordPress installed in the site root (mysite.com) and Zen Cart installed in a sub-directory (mysite.com/shop). So of course the .htaccess from the parent site (WordPress) will be inherited by all the sub-directories. Therefore the WordPress .htaccess file WOULD impact Zen Cart since Zen Cart is in a sub-directory. It’s the parent directory’s htaccess rules that was the issue all along (hence why my solution worked) not my integration to show a WordPress slideshow and a coupla WordPress widgets in Zen Cart..

    “You are disguising/hiding the URL in the Browser so the final URL actually downloads from the main WordPress site’s URL without having the full URL path to the actual displayed.”

    This is not correct.. The downloads in Zen Cart are NOT coming from the main WordPress site’s URL at all.. They were ALWAYS coming from Zen Cart, and they are “disguised” via a re-direct so that the location of the downloads directory is hidden (for security purposes)… Again THIS was never the issue.. This was validated by the fact that the downloads worked JUST fine if I turned off the BPS .htaccess file and used the default.htaccess file. My later troubleshoot turned up the issue in the .htaccess file.. The issue plain and simple is that one directive in the parent .htaccess file was sending the visitor to a 403 page when attempting to download a file because there was a “dot (.) in the URL path (of the download URL) that which would match this condition”.

    ” Since you are forcing them to be combined somehow then you will now need to figure out how to combine them, but also keep them separate in order for rewriting to work correctly.”

    My WordPress and Zen Cart sites are not combined at all. and I think that is the part that you have mis-stated/misunderstood here. All that I’ve done is use existing WordPress functionality to display WordPress content inside Zen Cart.. Specifically shortcodes and widgets.

    ” Specifically you are somehow calling wp-load.php in Zen Cart.  Logically this could be doing something like confusing your main WordPress website as to where WordPress is actually loading from.”

    Not somehow.. I include a require_once statement which calls the wp-load.php file in Zen Cart. As long as I have the correct path to wp-load.php defined. It doesn’t confuse ANYTHING..

    <?php
    /**
    * WordPress Integration
    * call for WordPress code
    *
    */
    define('WP_USE_THEMES', false);
    require_once(DIR_FS_WORDPRESS . 'wp-load.php');
    ?>

    You can include wp-load.php in order to gain access to core WordPress functions outside WordPress. The data can be accessed on ANY SITE (even Zen Cart), even if the output takes place in the root of the WordPress installation. Basically you can access WordPress data, functions, or shortcodes from anywhere. Since WordPress 2.5 it’s wp-load.php file provides this ability.There’s info on the WordPress site which explains this. (See all the articles which discuss “The Loop”)

    This technique is described in MULTIPLE places across the web. Here’s just a FEW examples:

    1. http://wpengineer.com/1038/embed-wordpress-functions-outside-wordpress/
    2. http://davidwalsh.name/wordpress-recent-posts
    3. http://www.hongkiat.com/blog/display-wordpress-sidebar-on-other-non-wp-sites/

    Anyway, again, thanks for your help.. I’m gonna work on this one last conflict.. I think it’s simply a matter of finding the right directive to add to the parent .htaccess so that it doesn’t interfere with the .htaccess I need for the store’s re-write module..

    #10114
    AITpro Admin
    Keymaster

    Yes, .htaccess files are hierarchical/recursive, BUT are also designed to work in a compartmentalized way.  The best Site Security Architecture/Design technique is to compartmentalize your security so that 1 website’s .htaccess file does not affect another site’s .htaccess file.  This allows you to create separate and unique security rules per site.

    If the parent directory has an .htaccess file that uses mod_rewrite and a child/subdirectory does not have an .htaccess file  that uses mod_rewrite then the child/subdirectory will have the rules from the parent diretory’s .htaccess file applied to its directory.

    If the parent directory has an .htaccess file  that uses mod_rewrite and a child/subdirectory has an .htaccess file  that uses mod_rewrite then the child/subdirectory site will follow the rules in its own .htaccess file and NOT the parent .htaccess file rules.

    A standard technique to Turn Off security in a child subdirectory or other site directory is to use the RewriteEngine Off directive in a child/subdirectory.  What that clearly demonstrates is how .htaccess files/rules can be compartmentalized per directory.  By creating an .htaccess file with ONLY this one line of code in that .htaccess file:  RewriteEngine Off and putting that .htaccess file in a subdirectory then that parent .htaccess file rules will NOT be applied to that child/subdirectory folder.

    Yes, I am familiar with calling wp-load.php within the SAME website directory.  I have never heard of wp-load.php being called in another directory other than the directory where WordPress is actually installed under.  I checked those links you posted and apparently you can call wp-load.php outside of a WordPress.  I was not aware that that would work.

    So yes it is possible to control all websites from 1 root .htaccess file, but here is the problem I found and that you also found.  Why is a simple and standard RewriteRule NOT working correctly?  Something is definitely wrong if that very basic and simple rewriterule is NOT working.

    I have a hunch that this has something to do with the way the URL is being hidden.  Example:  .htaccess rules with look at the URI/URL, but if you are doing something else to force the URI/URL to be something different then .htaccess code cannot be adapted to work in that way.  It works at the Server configuration level for a case like this and would not work at the URI/URL level.

    #10130
    AITpro Admin
    Keymaster

    Just for the heck of it as this may be of some use here and demonstrates a usage of where .htaccess code would work together with changing the URI/URL and handle rewriting accordingly.  This is how .htaccess code can be used to Cloak a URL.  At the time I posted that .htaccess code I used Redirect instead of RedirectMatch.  RedirectMatch is a much better directive to use because it allows you to use Regular Expressions code and the “Redirect” directive does NOT allow you to use Regular Expressions code.

    Source:  http://affiliates.ait-pro.com/65/bps-pro-affiliates-faq/

    Instead of having your Affiliate link displayed like this to visitors:
    http: //affiliates.ait-pro.com/po/?ap_id=XXXX

    Your Affiliate link will be displayed like this to visitors:
    http: //www.YourWebsiteDomainName.com/bps-pro

    If your website is in your root folder add this .htaccess code to your root .htaccess file:
    Example root folder website:
      www.example.com

    # BPS Pro Affiliate Links – Replace the X’s with your Affiliate ID
    Redirect 301 /bps-pro http://affiliates.ait-pro.com/po/?ap_id=XXXX

    If your website is in a subfolder add this .htaccess code to your root .htaccess file:
    Example subfolder website:
      www.example.com/YourWebsiteSubfolderName

    # BPS Pro Affiliate Links – Replace the X’s with your Affiliate ID
    Redirect 301 /YourWebsiteSubfolderName/bps-pro http://affiliates.ait-pro.com/po/?ap_id=XXXX

    The link code that you would add to your Posts, Pages or Sidebar for root websites is:
    <a href=”http://www.YourWebsiteDomainName.com/bps-pro”>BulletProof Security Pro</a>

    The link code that you would add to your Posts, Pages or Sidebar for subfolder websites is:
    <a href=”http://www.YourWebsiteDomainName.com/YourWebsiteSubfolderName/bps-pro”>BulletProof Security Pro</a>

    #10147
    DivaVocals
    Participant

    “I have a hunch that this has something to do with the way the URL is being hidden.  Example:  .htaccess rules with look at the URI/URL, but if you are doing something else to force the URI/URL to be something different then .htaccess code cannot be adapted to work in that way.  It works at the Server configuration level for a case like this and would not work at the URI/URL level.”

    The issue was that one directive.. PERIOD.. Nothing more.. nothing less.. Removing the offending directive SOLVED the issue.. It denied access to all file names starting with dot. I changed it to some thing that achieved the stated objective of that directive: “DENY ACCESS TO PROTECTED SERVER FILES – .htaccess, .htpasswd”. You are looking for an issue that IS NOT THERE.. 🙂 You seem to think there is STILL an issue.. I am reporting that there REALLY IS no issue now..

    “So yes it is possible to control all websites from 1 root .htaccess file, but here is the problem I found and that you also found.  Why is a simple and standard RewriteRule NOT working correctly?  Something is definitely wrong if that very basic and simple rewriterule is NOT working.”

    Nothing is wrong beyond some simple CONFLICTS with the .htaccess file which I’ve fixed..

    “Yes, .htaccess files are hierarchical/recursive, BUT are also designed to work in a compartmentalized way.  The best Site Security Architecture/Design technique is to compartmentalize your security so that 1 website’s .htaccess file does not affect another site’s .htaccess file.  This allows you to create separate and unique security rules per site.”

    But I don’t need or necessarily WANT to do this.. I don’t look at these as TWO SITES.. they are ONE site with a both a blog and a store.. Again, you are STILL assuming the issue was caused by displaying WordPress code on my Zen Cart store.. and this was NEVER the issue.. My method of having a Zen cart store in a sub-directory of my Zen Cart site is not something I’ve NEVER done before.. I’ve NEVER had any issue with this configuration.. What was different this time was the fact that this is the FIRST Zen Cart site I’ve built which that sold virtual (downloadable) products.. Hence the issue I had and reported.. (which is now FIXED)

    “Just for the heck of it as this may be of some use here and demonstrates a usage of where .htaccess code would work together with changing the URI/URL and handle rewriting accordingly.  This is how .htaccess code can be used to Cloak a URL.  At the time I posted that .htaccess code I used Redirect instead of RedirectMatch.  RedirectMatch is a much better directive to use because it allows you to use Regular Expressions code and the “Redirect” directive does NOT allow you to use Regular Expressions code.”

    Right.. Except I don’t plan to write directives for each and every URL in my store.. There is a re-writer module which will do this and all I need to do is find the correct .htaccess directives for the parent .htaccess to support it.. I have the author of the store’s re-writer module working with me to help me tweak the shop’s .htaccess file to work correctly.

    “Yes, I am familiar with calling wp-load.php within the SAME website directory.  I have never heard of wp-load.php being called in another directory other than the directory where WordPress is actually installed under.  I checked those links you posted and apparently you can call wp-load.php outside of a WordPress.  I was not aware that that would work.”

    Been able to do this since WP v2.5. And YES it works so long as you call the correct path to wp-load.php in your code.

    Anyway, I’ve just one more .htaccess problem to resolve so that the parent .htaccess doesn’t interfere with the store’s URL re-writer mod (re-write = pretty links for the store). Thanks for the help.. I think I’m all good now..

    #10150
    AITpro Admin
    Keymaster

    Ok great!  Thanks.

    #10151
    DivaVocals
    Participant

    “A standard technique to Turn Off security in a child subdirectory or other site directory is to use the RewriteEngine Off directive in a child/subdirectory.  What that clearly demonstrates is how .htaccess files/rules can be compartmentalized per directory.  By creating an .htaccess file with ONLY this one line of code in that .htaccess file:  RewriteEngine Off and putting that .htaccess file in a subdirectory then that parent .htaccess file rules will NOT be applied to that child/subdirectory folder.”

    Right, but I like the solution I came up with better.. I did not like the directive that restricted files simply because the filename contained a dot (.)

    #10152
    AITpro Admin
    Keymaster

    That rule also protects protected Server folders that are named starting with a dot:  Example:  .logs, .errordocs, etc etc etc.  In any case, you are doing something custom with your websites so your alternative code works fine for your particular scenario.  I doubt many folks would use a dot at the beginning of a folder or file name as this is not industry standard, but of course that is always possible.  This is the first time this issue has ever come up in over 3 years and 1,000,000+ users so yeah it is a very rare scenario. 😉  Anyway I’m glad it is documented so that if I ever do come across this again then I will know exactly what the issue is.

    #10156
    DivaVocals
    Participant

    “That rule also protects protected Server folders that are named starting with a dot:  Example:  .logs, .errordocs, etc etc etc.  In any case, you are doing something custom with your websites so your alternative code works fine for your particular scenario.  I doubt many folks would use a dot at the beginning of a folder or file name as this is not industry standard”

    I don’t agree with the “industry standard” part of your statement, but I am a tad too busy to find samples that contradict this statement right now.  I need to stress again that I AM NOT doing anything all that custom or unique either as you keep trying to emphasize.. There are whole modules/plugins/blog articles that execute the functionality I have in my store/blog.. As I am familiar with both WordPress AND Zen Cart I know this to be true..

    As for protecting files that begin with a dot,  files that begin with a dot are already blocked by default in most Apache installations for most competent hosts at the SERVER configuration level. I’m not concerned with this nearly as as I do have a competent host, and I may in fact remove the replacement directive I posted earlier..

    Let’s just say we will agree to disagree on this point..

    Also let’s not forget.. Zen Cart has been around for nearly 10 years. The developers are smart, and not inclined to use substandard coding methods.. So I will say this again.. There is ABSOLUTELY NOTHING wrong with the Zen cart downloads function, and it was NEVER the issue to begin with.

    But now if you ever run across this issue again, you now know the reason.. You may not have run across this before because I suspect most folks would come straight to the Zen Cart forum..

    #10162
    AITpro Admin
    Keymaster

    It is not a matter of agreeing or disagreeing and is instead a matter of using different methods.  No big deal.  Just wanted to point out some stuff.  There is always going to be several different ways/methods to accomplish the exact same things. 😉

    #10164
    DivaVocals
    Participant

    Gotcha!

Viewing 11 posts - 16 through 26 (of 26 total)
  • You must be logged in to reply to this topic.