403 on product link

[wizardofaus]

Added to dev environment.

http://dev.anchortex.com/index.php/military-clothing-equipment/night-vision-equipment/tpl-t15-thermal-imager-detail is an example of a 'broken' page -- links on that page cause Forbidden errors.

The OSURL output is in the breadcrumb section at the bottom of the page.

Interestingly, one link that does not generate Forbidden errors is at the top of the page -- the link to the Armasight item (http://dev.anchortex.com/index.php/military-clothing-equipment/night-vision-equipment/tat163cn5apmr01-detail).

However, using that 'next / previous item in category' link to attempt to go to one of our 'broken' pages gives an Error Updating Page popup.

Not sure what that means, diagnostically.

--Austin Cushing

[Studio 42]

ON refreshing page it work.
Is this not a cache or rewrite problem in your server settings ?

[oab]

I thought I'd mention my experience with word specific 403 error Got a site that whenever I tried to use the word 'contributor' in the article it would throw a 403. Turned out to be mod security in cpanel so the hosting company had to make a rule to allow that word. Just thought I'd mention as you say it happens with those two specific words.

[GJC Web Design]

It has to be a server problem .. where is the host in all this?

the above page for me is a 200 but all the supplementary elements are 403
refresh makes no difference but if I try the url in the response tab of the console it is fully there

if I try a direct call to a 403 they are there

e.g.  http://dev.anchortex.com/images/virtuemart/product/TPLogic-t15.jpg

have u zipped this install up and thrown it on another server to test?

[diri]

@diri, Cloudflare is a  content delivery network service. See https://www.cloudflare.com 

@jenkins: I know this but, I did some further investigations It looked like a cloud being hosted at cloudflare.

Nevertheless, back to the problem:

From my point of view there are few possible scenarios to cause such errors.

1. Flacky server because it does not cause each error all the time. Could be an overload as well (doubt it, should give error 500).
2. Unknowon (?) filtering proxy provided by hoster. At 1und1 there is such a beast but, AFAIK it only limits number of possible sessions (and causes problems because servers in normal hosting are running in cgi mode) without further filtering.
3. htaccess

Especially htaccess can cause such behaviour very easy and problematic installation is running in a sub-domain (dev).

Does this sub-domain have it's root inside the directory whery (main-)domain is located?

Is there an active and valid .htaccess in directory which can influence server's behaviour in relation to directory of sub-domain dev?

Example to illustrate it (my english is not fluent enough ATM ):
1.
/var/www/htdocs <- main root with htaccess accessible and active for webserver
/var/www/htdocs/dev <- sub domain

or is it like this:
2.
/var/www/htdocs/www <- main root with htaccess accessible and active for webserver
/var/www/htdocs/dev <- sub domain

[wizardofaus]

It has to be a server problem .. where is the host in all this?

the above page for me is a 200 but all the supplementary elements are 403
refresh makes no difference but if I try the url in the response tab of the console it is fully there

if I try a direct call to a 403 they are there

e.g.  http://dev.anchortex.com/images/virtuemart/product/TPLogic-t15.jpg

have u zipped this install up and thrown it on another server to test?

I have, unfortunately, and the problem persists -- testing a backup installed on a different server and hosting platform, the exact same problem occurs. Likewise, on a fresh install with just the #_virtuemart_* and mainmenu segment of #_menu copied over, the exact same problem occurs. For the time being, I'm basically just avoiding using the words that trigger it until I can figure out why it's mortally offended by them.

Diri: dev.anchortex.com is indeed currently hosted in a subdirectory of www.anchortex.com, although I am changing that in the near future; the problem exists on either dev.anchortex.com or www.anchortex.com even when the .htaccess file is removed or replaced with a Joomla default version.)

I actually checked mod_security to see if anything is triggering it that would thus logically cause the problem, but the logs don't give any indication of rules being triggered during testing... (doesn't mean it isn't the problem, just means I haven't figured out how to prove it if it is.) I even turned mod_security off temporarily to test and that didn't stop the problem.

The problem is reproducible for a very specific set of circumstances (although live URLs have been fixed, just search for 'thermal' and the problem remains - page loads but any link from that page fails with a 403); therefore I can't just blame it on a flaky server (especially since the problem is precisely reproducible on an alternate server.)

[Studio 42]

http://dev.anchortex.com/military-clothing-equipment/night-vision-equipment is working
http://dev.anchortex.com/index.php/military-clothing-equipment/night-vision-equipment do a 403
Use apache rewrite can solve the problem
In your Joomla config> SEO Settings > Use URL Rewriting Yes can perhaps solve this problem ?
If you already use URL Rewriting, then try to force in .htaccess to remove index.php/ and redirect to short version without index.php

[diri]

Diri: dev.anchortex.com is indeed currently hosted in a subdirectory of www.anchortex.com, although I am changing that in the near future; the problem exists on either dev.anchortex.com or www.anchortex.com even when the .htaccess file is removed or replaced with a Joomla default version.)

This leads me to another question:

Do those sites (www., dev.) use the same database?

Some time ago (J 2.x times) I had this constellation (sub directory + same db) for few days to test some updates. It caused never ending problems - path not found has been the easiest one, the worst has been suddenly occuring capability to get "headless" access to Joomla's backend without login due to an unknown redirect. I can only recommend to avoid it in any case.

My normal standard setting is to have a separate directory for every (sub-)domain "beside" the other ones. This saves me a lot of trouble for having to watch only one setup - no influence by any other application needs. Even using same db in another sub domain for testing makes no problem than, absolute path to root of sub domain is the one and only difference (edit) except web link due to other domain.