While going through my site I found some links either go to a 403 forbidden error or the page load is broken. I have checked the error logs but did not come across anything for the issue. Here is one of the links https://www.anchortex.com/military-clothing-equipment/night-vision-equipment/tpl-t15-thermal-imager-detail. I am using PHP 5.6 (updating soon) , Joomla 3.9, and currently using VM 3.2. I have a test site that has updated PHP 7.2 and VM 3.4.2 but still have the same problem
can't get a single proper page from the site
http://forum.virtuemart.net/index.php?topic=104795.0
http://forum.virtuemart.net/index.php?topic=79799.0
added versions into original post
even https://www.anchortex.com/faqs is a 403 -- so not VM related
can't get a single page to render properly
try with htaccess disabled -- other than that ask the host what is .. do any sites work on this account?
I will try with htaccess disabled but once you click through the site with from that link nothing works, but if you start at the home page it works fine except for certain ones https://www.anchortex.com/
https://www.anchortex.com/military-clothing-equipment/night-vision-equipment/tpl-t15-thermal-imager-detail --
look at the network tab for this .. nearly everything is a 403
I can't see this is a VM issue
Apologies, my coworker posed the initial question under my account. I shall attempt to explain the problem more thoroughly, having had a chance to study it and figuring out parts of the actual problem.
For the record, anchortex.com is running on VirtueMart 3.2.14, under Joomla! 3.9.0 Stable [ Amani ] 30-October-2018 14:00 GMT, on MySQL 5.7.24, PHP version 5.6.38, using the Vermilion template from RocketTheme with significant modifications.
If you go to https://www.anchortex.com/, most of the links work normally. For example, going to https://www.anchortex.com/work-wear-protective-apparel/flame-resistant-outerwear you can then click on the first result (https://www.anchortex.com/work-wear-protective-apparel/flame-resistant-outerwear/berne-frhj01-fr-hooded-jacket-detail), and it too loads normally, and all links from that page work normally.
However, items with 'thermal' or 'armasight' in the URL, specifically, create pages where any link from that page generates a 403 error. This includes items with those terms in the slug, categories with those terms in the slug, search results with those terms in the URL... and I am at a complete loss for why this is occurring.
The problem appears to be version-agnostic and does not seem to be connected to anything but the data itself; I was able to replicate the problem by copying the mainmenu portion of the Joomla menu table (for the list of categories), plus all of the Virtuemart product tables, media tables, category tables, and manufacturer tables to a fresh install of Joomla -- http://dev.anchortex.com, running off of the protostar template with no adjustments and no initial Joomla plugins beyond Virtuemart itself. It is running on Joomla! 3.9.1 Stable [ Amani ] 27-November-2018 15:00 GMT, MySQL 5.7.24, PHP version 7.0.32, and Virtuemart 3.4.2. I did a quick replace to repair the file_urls that broke because the old version was looking for images/stories/virtuemart/* and the new version didn't require that inclusion to work properly, but made no other major changes to the data before beginning my testing. I added Akeeba Backup and Admin Tools in order to make a backup of the resulting site before tinkering, and to use Admin Tools to test basic problems that might ensue.
The category in which I was testing was http://dev.anchortex.com/index.php/military-clothing-equipment/night-vision-equipment -- and the item which I was testing was the Armasight TAT163CN5APMR01 ARMASIGHT by FLIR Apollo Pro MR 640 50mm (30 Hz) Thermal Imaging Clip-on System, which I was struggling to figure out why it was breaking. I carefully recreated the item piece by piece, and eventually worked out that if the slug was changed to something not containing the word 'armasight' or 'thermal', the problem vanished -- hence, the current URL of the Armasight product in question is http://dev.anchortex.com/index.php/military-clothing-equipment/night-vision-equipment/tat163cn5apmr01-detail . Likewise, clicking any of the non-thermal night optic items (such as http://dev.anchortex.com/index.php/military-clothing-equipment/night-vision-equipment/browe-combat-optic-bto-detail) works normally. However, clicking on one of the thermal imagers that has 'thermal' in the URL (such as the
Torrey Pines Logic T12 Weapon Mounted Thermal Imager at http://dev.anchortex.com/index.php/military-clothing-equipment/night-vision-equipment/tpl-t12-thermal-imager-detail ), generates the same problem where any link outwards from that page results in a 403 Forbidden error (and likewise, even the attempt to load the image results in the same problem.)
So in short, any page on either site that has 'thermal' or 'armasight' in the URL seems to break, and I have no idea why it is (or what other fragments might exist that need to be avoided). I can instruct them to work around the problem, but would prefer to understand what caused it in the first place or at least get some idea of where to look for it.
-- Austin Cushing
QuoteSo in short, any page on either site that has 'thermal' or 'armasight' in the URL seems to break,
first thought is do these clash with either a category SEF url or a menu SEF item?
disable SEF and try to navigate with the non SEF urls -- do they work to those pages?
modification/catalog/view/theme/default/template/product/product.tpl is not a Virtuemart file, so you certinaly dont use VIrtuemart at all
Hi,
I did have a short look at links mentioned and my very first assumption is htaccess and some filtering there related to content of current link.
2nd assumption is a flickery server because it denied access to vm-ltr-common.css when being called from not working page.
Even links to further products (product links on critical page) produce a 403.
You don't have permission to access /index.php/military-clothing-equipment/night-vision-equipment/tat163cn5apmr01-detail on this server.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.
edit:
htaccess would be of interest (deny / allow, rewriterules). Maybe there are some other security setting at server side as well.
Quote from: diri on November 30, 2018, 05:49:20 AM
Hi,
I did have a short look at links mentioned and my very first assumption is htaccess and some filtering there related to content of current link.
2nd assumption is a flickery server because it denied access to vm-ltr-common.css when being called from not working page.
Even links to further products (product links on critical page) produce a 403.
You don't have permission to access /index.php/military-clothing-equipment/night-vision-equipment/tat163cn5apmr01-detail on this server.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.
edit:
htaccess would be of interest (deny / allow, rewriterules). Maybe there are some other security setting at server side as well.
Unfortunately, the .htaccess file on dev.anchortex.com is the default version that comes with a standard Joomla install, where the problem is replicated; replacing the live site's .htaccess file with the default (or with none at all) does not solve the problem.
It's not outside the realm of possibility that the server is merely being cantankerous, but the below problems occur on every refresh of the affected pages, as opposed to 'sometimes it works and sometimes it doesn't' -- which would imply something is rotten that isn't just 'the server doesn't feel like loading a vital component this time around'.
Furthermore, as a prior component of testing, I took an Akeeba Backup to back up the site, then kickstart it onto a separate server (on a separate host and hosting platform) in order to test whether it's part of a faulty server configuration; upon doing so, the problems below are replicated precisely. That doesn't rule out a bad server configuration, of course, but it does provide supporting evidence for the thought that this problem is either within the #_menu table or the #_virtuemart_ tables. Combine that with the fact that the dev.anchortex.com site is currently running a fresh install of Joomla and Virtuemart with only the aforementioned tables brought over, with only Akeeba Backup and Admin Tools as extensions (and the problem was tested and proven replicated before those extensions were added), and I'm left puzzled and trying to figure out what would cause this.
Quote from: GJC Web Design on November 28, 2018, 19:38:05 PM
QuoteSo in short, any page on either site that has 'thermal' or 'armasight' in the URL seems to break,
first thought is do these clash with either a category SEF url or a menu SEF item?
disable SEF and try to navigate with the non SEF urls -- do they work to those pages?
Turning SEO off on dev.anchortex.com within Virtuemart config, and visiting the most problematic section (http://dev.anchortex.com/index.php/military-clothing-equipment/night-vision-equipment), this link to item does work (it loads, and links from this page also load):
http://dev.anchortex.com/index.php/military-clothing-equipment/night-vision-equipment/view/productdetails/virtuemart_product_id/11036/virtuemart_category_id/20
whereas with SEO turned back on in Virtuemart, this item does not work (it loads, but any link from this page generates a 403):
http://dev.anchortex.com/index.php/military-clothing-equipment/night-vision-equipment/tpl-t12-thermal-imager-detail
Likewise, on the Products By Brand page (http://dev.anchortex.com/index.php/shop-by-brand), with SEO turned off, this link works (it loads, and links from this page also load):
http://dev.anchortex.com/index.php/shop-by-brand/view/category/virtuemart_category_id/726
And with SEO turned back on, this link does not (it loads, but any link from this page generates a 403):
http://dev.anchortex.com/index.php/shop-by-brand/armasight
Quotefirst thought is do these clash with either a category SEF url or a menu SEF item?
by this I mean do you have categories and products that with full SEF could cause some conflict via same names etc? (unlikely but I have seen before)
Try installing this module with SEF on then u get an indication of where they are trying to be routed to ..
https://github.com/OSTraining/OSURL
other wise something drastic like test on another server or localhost
@wizardofaus:
Your host is located at cloudfare ... is it a virtual machine or kind of normal hosting paket?
Do you have all features needed to change behaviour of webserver at hand?
@diri, Cloudflare is a content delivery network service. See https://www.cloudflare.com
Quote from: GJC Web Design on December 03, 2018, 20:02:32 PM
Quotefirst thought is do these clash with either a category SEF url or a menu SEF item?
by this I mean do you have categories and products that with full SEF could cause some conflict via same names etc? (unlikely but I have seen before)
Try installing this module with SEF on then u get an indication of where they are trying to be routed to ..
https://github.com/OSTraining/OSURL
other wise something drastic like test on another server or localhost
Unfortunately, no, there are no duplicated products -- irrational as it sounds, it just literally seems to fail if 'armasight' or 'thermal' is in the URL anywhere at all, regardless of where and why.
I'll test out the module and see if it can provide further insights.
The fact that it only creates Forbidden errors (as far as I can tell) from pages with 'armasight' or 'thermal' in their URL, and does so even on a fresh install on a completely different server, tells me it (probably) has to be something wrong with the Virtuemart or menu data (the only content duplicated between servers), but I'm still not sure entirely why it's doing this yet.
I do have the ability to change aspects of the webserver to some extent (WHM access), but not necessarily the knowledge to know what needs to be changed, unfortunately. I have confirmed that the problem exists if an Akeeba backup is kickstarted onto a different server on a different hosting platform (anchortex.com and dev.anchortex.com are hosted through Bluehost; my private test area is hosted through InMotionHosting).
-- Austin Cushing
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
ON refreshing page it work.
Is this not a cache or rewrite problem in your server settings ?
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.
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?
Quote from: jenkinhill on December 04, 2018, 10:05:53 AM
@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
Quote from: GJC Web Design on December 10, 2018, 21:52:35 PM
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.)
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
Quote from: wizardofaus on December 17, 2018, 15:44:48 PM
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.