I've got a website where on the majority of computers it works absolutely fine, redirecting users to the correct pages using the .htaccess file.
However, some computers seem to be ignoring the rules in the .htaccess file (maybe even the .htaccess file completely).
RewriteEngine On
RewriteBase /
RewriteRule ^procyon$ /procyon.php [L]
When a user visits http://www.blackroc-technology.com/procyon it redirects them to a product page. However, for some users they get a 404 error.
Someone in the same building as me (same internet connection) is suffering from this problem - I've tried both IE and Chrome and neither work so it doesn't appear to be a browser issue.
There's also a handful of customers on other internet connections to ours which have reported the problem.
Any thoughts on this? It's seems very odd to me and hard to debug!
If you can reproduce both cases, working and not working, then do an client side HTTP capture, e.g. using Fiddler.
You can then diff the successful/unsuccessful request to try to narrow down the issue e.g. if bad requests always fail and good requests always succeed, when re-requested from Fiddler, regardless of which network, computer they are issued, then it is likely a server side issue (.htaccess or httpd.conf setting sensitive to one of the request attributes).
At the very least you will have a better idea of exactly what is transpiring vs just the end result of a 404.
You can also similarly enable logging on the server side (ideally in a staging enviroment, not production) e.g
RewriteLogLevel 9
to get more details on why bad requests result in a 404
Related
We have a FAQ page /faq (tab style) where every question should have its own 'ghost' url/page. So users could visit eg.
/faq/question-1
/faq/question-2
/faq/question-3
The problem is question-1, question-2, question-3 are not actual pages but just sections on /faq. For SEO, aesthetics and usability reasons we do not want to work with ?q= or #
I've searched and tried every .htaccess thread I came across but without result.
Is there a way we can show the page/faq when visiting /faq/question-1 and keep the url /faq/question-1 with mod_rewrite? (we cannot hardcode it because we do not know all future question slugs) So basically something that tells the browser: if the first url part is /faq/, just ignore everything that comes behind but keep the url.
Thanks
This is a trivial rewriting task and it is unclear why this should not work for you:
RewriteEngine on
RewriteRule ^/?faq/.+ /faq [END]
Since you claim that you "tried every .htaccess thread you came across" and this clearly works the question is: why not in your setup? But since you did not tell us anything about your setup we cannot really offer more help...
These are some general hints though which you should go through:
Where did you implement the rules you tried? In the http server's host configuration or in a distributed configuration file?
If you are using a distributed configuration file (".htaccess") then how did you make sure such files are interpreted by your http server and how did you test that?
Did you check your http server's error log file for hints?
Did you make sure that you are not actually looking at cached responses? So did you really test with a fresh anonymous browser window using a "deep reload"?
Since the CMS you are using requires own rewriting rules, where did you add those rules you tried? Remember: the order is important!
I run a service where I offer css files and scripts and images for a third party website www.myfantasyleague.com that is a football hosting service for fantasy football and recently they have went through some changes over the last couple of years.
I am trying to block certain websites on their servers that are using my work fraudulently, while allowing the folks whom purchase my work on the same domain to be able to use my work and it not be blocked by the HTA file. Once you create a football site MFL gives it a permanent server number and 5-digit code that never changes now from each year it stays the same. Here is a link to a MFL search for the word football, and you can see there are many sites and if you click on a few they all have different 5 digit IDs and some have different server ID’s.
The site I want to start with to block, would be this site url below, and the MFL domain has an option to have http and https now, so getting both protocols would be idea.
SITE TO BLOCK EXAMPLE
https://www67.myfantasyleague.com/2019/home/63928#0
SITE TO ALLOW EXAMPLE
http://www51.myfantasyleague.com/2019/home/46087#0
On myfantasyleague domains they give each site its own 5-digit unique code at the end of the url, and also many are on different server id’s, like the www67 and the www51, and you see those 2 links one is https and one is http.
In the past I use to use this code below and it will still work today, however once I add it to my root access file, it takes out both sites and I can’t have that, as I want to be able to control which sites are blocked by the server number and the 5-digit league ID if possible.
CODE THAT I TRIED THAT WORKED BUT KILLS ALL SITES FROM THAT DOMAIN NAME.
RewriteEngine On
RewriteCond %{HTTP_REFERER} https?://(www\.)?www(67).myfantasyleague.com.+(63928) [NC,OR]
RewriteRule .*\.(jpe?g|gif|bmp|png|js|css)$ [L]
Maybe i can turn that URL to be blocked into the actual IP and try blocking the IP?
I don't know what else to try and it might not even be possible i dont know. I appreciate any and all feedback.
Thank you
Though the pattern you posted certainly can be improved there is no reason why it should "block" all referrers from that host, if those sites send a referrer header at all ... Keep in mind that such header is optional and can be modified easily, so anyone can work around limitations you implement based on that header.
Blocking an IP on the other hand means you block all services from that host which is not what you want, as I understand. The numerical addition to the "www" prefix indicates that the service operator uses sharding to balance request load, an old and outdated approach. You can expect that to change any time, either for individual sites or in general, so better not rely on it. You are only interested in the numerical ID at the end of the referring URL.
Your issue with that approach you posted however is the actual rewriting rule: it is syntactically invalid. So I would expect it to raise an internal error, thus blocking all requests. I would suggest something like this instead:
RewriteEngine On
RewriteCond %{HTTP_REFERER} !/63928$ [OR]
RewriteCond %{HTTP_REFERER} !/63927$ [OR]
RewriteCond %{HTTP_REFERER} !/63926$
RewriteRule ^ [F,NC]
This would actively white list specific sites by mentioning their numerical ID and block all other requests by sending out a "Forbidden" header.
Please note that I have not actually tested above code, it might contain some minor glitch which you might have to fix. For such things it is important to have access to the http servers error log file. Not sure if you have it in your situation...
I am Tani.
We are currently having an issue with a web service for a client wherein certain accesses to our page are resulting in an infinite redirect loop. We have been unable to reproduce the error, but because the issue is apparently solved by clearing the cache, it seems to be the case that cache data from a previous version of the site (different server, same domain) is resulting in unwanted redirects for some reason we are not quite certain of (again, nobody at our company can reproduce the behavior).
While investigating this, we discovered something odd. We are currently building a webpage with a series of unsecured landing pages that all transition to a single SSL-secured form. However, accessing the form via HTTPS (.htaccess always rewrites the request to use HTTPS when moving into a form action) will cause all future requests to the server to be interpreted as HTTPS, even those that are normally unsecured, until the cache is deleted.
By looking at the server's access log, we can see that this the request is being changed to HTTPS before it even hits our .htaccess. However, because the request is coming to the server with the S appended, we have no way of knowing what is causing the switch to SSL. It can be consistently reproduced by opening the secured form in one tab and then refreshing the other. We have tried restarting the servers, clearing the caches (application, firewall, etc.), but nothing seems to effect it.
The question itself is two-fold: first, is it a reasonable conclusion that this SSL-rewriting may, when combined with an old cache, result in an infinite redirect loop? And second , does anybody have any ideas which might cause HTTP requests to be rewritten as HTTPS?
Thank you for your time.
My site was working fine for the last couple of months and suddenly stopped working. and the issue was backend was working fine but the front end does not load at all.
then I contacted server providers they saying they have not done any changes to the server and asking me to contact Joomla support to see any in-depth errors. they even said they cant find any issues from the logs.
Then what I did was I reinstall VirtueMart (mind you this is an e-commerce site). then it started to work again from the front end. but I realize follow on pages aren't working. so what I did was I remove url re-writing and change the .htaccess code to txt.
so the issue I am having now is I can see index.php file in the URL. but whenever I try to change use url rewriting and enable .htaccess I get this error
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster#domain.au and inform them of the time the error occurred, and anything you might have done that may have caused the error.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
anyone have any ideas?
Suddenly stopped working, without any change from your end ?
Try to step backward and recall anything you did before the issues.
The virtuemart re-installation should not have any relation with the SEF settings and the htaccess.
All these seem to be a combination of different issues.
Have you made any changes on the htaccess file ?
Go in Joomla Global configuration and disable SEF settings. Set URL rewriting to No. Then try to load pages in the front-end.
If you need SEF URLs, follow these instructions about how to enable this feature in Joomla:
http://docs.joomla.org/Enabling_Search_Engine_Friendly_(SEF)_URLs
This should be a quick one... here is my current .htaccess file:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
What I need to do is make sure that if http://www.mydomain.com/cart/ is reached, it needs to force HTTPS ... so /cart/ and anything within /cart/
Once the request has been sent to http://www.mydomain.com/cart/, if there is any sensitive data in the request, it's too late. Force it to break! At least, it will give you an indication that there's something wrong with your links. More details in previous answers:
https://stackoverflow.com/a/8765067/372643
https://stackoverflow.com/a/8964190/372643
[ ... ] by the time the request reaches the server,
it's too late. If there is a MITM, he has done his attack (or part of
it) before you got the request.
The best you can do by then is to reply without any useful content. In
this case, a redirection (using 301 or 302 and the Location header)
could be appropriate. However, it may hide problems if the user (or
even you as a developer) ignores the warnings (in this case, the
browser will follow the redirection and retry the request almost
transparently).
Therefore, I would simply suggest returning a 404 status:
http://yoursite/ and https://yoursite/ are effectively two distinct sites. There is no reason to expect a 1:1 mapping of all
resources from the URI spaces from one to the other (just in the same
way as you could have a completely different hierarchy for
ftp://yoursite/).
More importantly, this is a problem that should be treated upstream: the link that led your user to this resource using http://
should be considered as broken. Don't make it work automatically.
Having a 404 status for a resource that shouldn't be there is fine. In
addition, returning an error message when there is an error is good:
it will force you (or at least remind you) as a developer that you
need to fix the page/form/link that led to this problem.
EDIT: (Example)
Let's say you have http://example.com/, the non-secure section of your site that allows the user to browse items. They're not logged in at that stage, so it's fine to do it over plain HTTP.
Now, it's cart/payment time. You want HTTPS. You send the user to https://example.com/cart/. If one of the links that sends the user to the cart part is using plain HTTP (i.e. http://example.com/cart/), it's a development mistake. It just shouldn't be there. Making the process break when you thought you were going to be sent to https://example.com/cart/ allows the developer to see it (and, once fixed, the user should never have the problem).
If it's just about the point to the HTTPS section of your site (typically, an HTTP GET via a link somewhere), it's not necessarily that big a risk.
Where automatic redirects become even more dangerous is when they hide bigger problems.
For example, you're on https://example.com/cart/creditcarddetails and you've filled in some information that should really just stay over SSL. However, the developer has made a mistake and a plain http:// link is used in the form. In addition, the developer (a user/human after all) has clicked on "don't show me this message again" in Firefox when it says "Warning: you're going from a secure page to a non-secure page" (by the way, unfortunately, Firefox warns a posteriori: it has already made the insecure request by the time it shows the user that message). Now, that GET/POST request with sensitive data is sent first to that incorrect plain http:// link and the automatic rewrites tells the browser to try the request again over https://. It looks fine because, as far as the user is concerned, this all happened in a fraction of a second. However, it's not: sensitive data was sent in clear.
Making the plain HTTP section of what should only be over HTTPS not do anything useful actually helps you see what's wrong more clearly. Since the users should never end up there anyway if the links are correctly implemented, this isn't really an issue for them.
Try adding this before the other rules (but after RewriteBase):
RewriteCond %{HTTPS} off
RewriteRule ^cart/(.*)$ https://www.mydomain.com/cart/$1 [R,L]