I just noticed today that a website I am creating has the WWW or non-WWW problem. If you go to http: //www.taskconductor.com, it is a different page with the same content as just http: //taskconductor.com.
If you were to login (username: show#412customs.com, Pass: tester) at http: //www.taskconductor.com, then try to go to http: //taskconductor.com (without the WWW), it will make you log in again. Then as you can see, when you check your cookies, you can see that there are two sets of cookies. One for http: //taskconductor.com and one for http: //www.taskconductor.com.
I have seen that this is a problem, but do I need to make a redirect? and if so, does it have to be index.php? I would really prefer to have all of my main content on index.php.
How can I get around this?
Do you know what web server you are using? If you're using apache, you can rewrite the URL in the .htaccess file. This will allow you to funnel all your traffic to with your non-www domain. I did a quick google and found this sample code:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.example.com$ [NC]
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]
Source: http://yoast.com/how-to-remove-www-from-your-url-with-mod_rewrite/
I was able to set my php "setcookies" to have a specified domain.
My original setcookie string was: setcookie('ver_ame', $email, time()+2592000);
This only allowed the cookie to be set on whatever type of page it was on. If it were on http: //taskconductor.com it would set the cookie for that, and also the same if it were http: //www.taskconductor.com.
If your setcookie string is: setcookie('ver_ame', $email, time()+2592000, "/", ".taskconductor.com");
The additional "/" shows the cookie to work on any of the directories under the root. The ".taskconductor.com" part would be showing which domain to use. The fact that it has a period before the web name shows that this cookie will work on any subdomain or its own domain.
Thank you all for the responses and help! It all works now! THANK YOU!
Better than using URL rewrites is to set your cookies to work for subdomains. For example, if you set the cookie for mydomain.com, then it will not work for sub.mydomain.com. However, if you set the cookie for .mydomain.com (notice the period), then it will work for mydomain.com, sub.mydomain.com, foobar.mydomain.com etc.
If you explicitly set your cookie domain to taskconductor.com (no www), then the same single set of cookies will be used for both the www and the naked domain. You'll just need to modify your PHP to specify a cookie domain.
I would recommend you do as others are suggesting and do a redirect to whichever version you want to use as the canonical URL. It's bad practice to have duplicate content across multiple (sub) domains. But, it's also a good idea to understand the domain scope of cookies that you set.
Related
I'm having difficulty finding out what it means when I have the response header Non-Authoritative-Reason : HSTS
I have searched a lot but just came up with some explanations about HSTS (redirection from HTTP to HTTPS). Can anyone help me with that? By the way I'm using Chrome.
Thanks
The server you are trying to connect with uses strict-transport-security (HSTS) to ensure https only is used with this site rather than the default http.
This means if you enter http://www.servername.com then Chrome will automatically convert this to https://www.servername.com.
This is a security feature to prevent use of http, which is unencrypted and which can be read and altered by a hacker. This can be set by the server telling Chrome (via a special HTTP Header sent in response to requests) that it uses HSTS. This setting is then cached by Chrome for the given amount of time as defined in the max-age value in that header. Additionally the site owner can submit their site to a preload list that is automatically included in Chrome - which protects even the first visit as normally you need to visit the site to receive the header to activate this.
The way Chrome shows this in the network tab is by creating a dummy 307 response with a redirect to the https version of the address. But that's a fake response and is not generated by the server - the reality is Chrome did that internally before the request even went to the server.
To clear this setting for a site you can type the following into Chrome's URL field: chrome://net-internals/#hsts and then search for your site and delete it. You may also set this at a top level domain and include subdomains so you may need to delete from there. Alternatively you can just alter your server config to publish the header with a max-age of 0 and revisit the site to clear this, then stop publishing the header, which can be helpful for other browsers where it's not quite as easy to clear this.
Note you cannot clear this setting if a site is on the preload list as this is embedded in the web browser's code. The site owner can submit a request to be removed from the preload list but this takes several months to go through the release cycle for Chrome and no defined timeline for other browsers. Chrome also provides no way to override preloaded settings - for security reasons.
Some additional info to BazzaDP's answer...
The Non-Authoritative-Reason : HSTS returned in the response is not something you have configured, but rather Chrome itself. Since Chrome hijacks the request, Chrome will also add this particular header to tell HSTS is enabled. Looking at the network tab, you will see the fake 307 response with this header set.
All this is done since you included the Strict-Transport-Security header on your server.
If you want to go all in, here's the HSTS preload list
According to MDN (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security):
The Strict-Transport-Security header is ignored by the browser when
your site is accessed using HTTP; this is because an attacker may
intercept HTTP connections and inject the header or remove it
And the HSTS Preload list deployment recommendations mention:
Add the Strict-Transport-Security header to all HTTPS responses
The HTML5 Boilerplate shows how to only set Strict-Transport-Security over HTTPS (in apache):
# Set 'Strict-Transport-Security' over HTTPS only!
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ %{ENV:PROTO}://%1%{REQUEST_URI} [R=301,L]
</IfModule>
Not loading few icons when it loads 1st time at any browser in OpenCart 2.0.3.1, also add to cart button dose not works at 1st time load.
Site URL- http://www.allcardecor.com/
I tried clearing my cache, reinstalling all my modules.
You're having a cross-domain issue with your request. When I load that page in my console I see this error:
Font from origin 'http://allcardecor.com' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.allcardecor.com' is therefore not allowed access.
You'll note that your site http://www.allcardecor.com, is calling on the FontAwesome files from http://allcardecor.com. The browser is seeing this as two different domains.
You'll want to setup a canonical name for one of the domains in your DNS so that it's recognized as a legitimate alias for the other.
https://en.wikipedia.org/wiki/CNAME_record
You should also setup CORS so that you can call scripts from approved sites without running into cross domain errors:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
For someone who might still need this. The problem is due to cross domain issue as Jocko has pointed out.
Another way to fix this is to redirect all requests to your site to particular subdomain, e.g. yourdomain.com => www.yourdomain.com and link all resources as such.
On Apache, in .htaccess file, add the following lines:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourdomain.com [NC]
RewriteRule ^(.*)$ http://www.yourdomain.com/$1 [L,R=301]
On Nginx, checkout this link.
If I have a dynamic page, where it takes in an id parameter like example.com/posts.php?id=2, how do I make a RewriteRule in htaccess so that the url shows the title of the post rather than its id, so for example posts.php?id=2 shows a post with a title of "PHP is cool", I want the url to be rewritten like example.com/2/php-is-cool or something like that? Would that be possible if the title value is stored in a MySQL database?
Additional Info:
This is how my htaccess looks like:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^mydomain\.com$
RewriteRule (.*) http://www.mydomain.com/$1 [R=301,L]
ErrorDocument 404 /index.php
ErrorDocument 403 /index.php
php_value post_max_size 20M
Basically, I have a MySQL database which stores blog posts in a table called posts. The posts table has an id attribute (which is the auto-increment primary key), a title attribute, and a content attribute. When I access mydomain.com/posts.php?id=X, it will show my post with an id of 'X' from the database on the webpage. I just want to be able to re-write the URL such that it shows the title of the page. I'm doing this primarily for SEO, not aesthetics. Is this possible using htaccess, or would I have to approach this differently?
Rewrite rules apply to the way the URL is handled on your backend (apache). Using mod_rewrite to rewrite those URLs will not affect what the user is seeing in their browser's URL bar unless you redirect the user to a new URL (using a 302 redirect, for example), which would cause the browser to reload the page.
You can achieve what you're asking for using the HTML5 pushstate feature (with a fallback to URL hashes if pushstate is not supported in that browser).
Take a look at this URL for more details:
http://badassjs.com/post/840846392/location-hash-is-dead-long-live-html5-pushstate
Also, you could use BackboneJS and its Router feature to handle your page and URL handling logic in the browser.
http://backbonejs.org/#Router
This is a very application specific kind of solution and this answer cannot go into more details without knowing your exact configuration, application logic, etc.
If you're doing it for SEO only, the easiest way is to pass all URLs to one single script which analyses the request and delivers the content from the database.
Like in
RewriteRule (.*) index.php?url=$1
Of course you will have to exclude index.php from the rule.
hello i have the following problem regarding mod_rewrite:
i have build a page that is called example.php
now i'm still searching for a rewriterule for the following issue:
because of different languages but the same content of the page example.php i would like to have a rewriterule when an user is entering for example site.com/beispiel.php
what will be the same word for example in german. so there is only one page. but the imaginary url site.com/beispiel.php would be the same content.
so if there is someone who knows how to solve this problem i really would appreciate. thanks a lot.
I was thinking about it :
If you use the google translator as shown in translate a PHP $string using google translator API
Then redirect from PHP to
www.yoursite.com/translate.php?translated_language=keyword_from_script
Then use a mod_rewrite from the last answer with that parameter, it should work?
Redirections and internal redirections are two different things.
An HTTP Redirection with a code 302 or 301 imply several HTTP request and the user will see at the end that he has been redirected to /example.php. An internal redirection means serving one file B on the server for a file A requested, without the user knowing it.
Internal Redirection does not need mod-rewrite's rules. The Alias and AliasMatch directives could be used to map some requested files to a real file.
Alias /beispiel.php /path/to/my/docroot/example.php
External Redirection could also be performed without mod_rewrite, by using Redirect and RedirectMatch directives.
Now you could also use mod_rewrite to perform these two types of redirections (internal & external).
# internal alias
RewriteRule ^beispiel.php$ /path/to/my/docroot/example.php [L]
# Or external redirection, with a R tag
RewriteRule ^beispiel.php$ example.php [L, NC, R=302]
With external redirections qlways Start by trying some rewriteRiles handling 302 redirections. When it will be working you could use 301 redirects as the browser store 301 results and do not ask anymore before restart.
If you have a big number of rediirection to perform and you are not stuck with .htaccess files (i.e. you can edit the real apache configuration files), you could have a look at RewriteMap to speed-up your rewriteRules.
Right now I have a website with all the href and src point to /some/url. There's always a slash in the beginning.
I'm currently testing the site using a subdirectory on the server, which has the address of http://somedomain.com/subdirectory/ (production would be http://somedomain.com)
Is there anyway to temporarily convert the /some/url from http://somedomain.com/some/url to http://somedomain.com/subdirectory/some/url without actually changing each of the href and src properties. From what I can make out of the base tag, it doesn't work like that. Also changing the RewriteBase from / to /subdirectory also doesn't work (Not too familiar with mod_rewrite, maybe someone can fill me in on that)
in .htaccess file in somedomain.com dir U can put:
Options +FollowSymLinks
RewriteEngine On
RewriteRule (.*) http://somedomain.com/subdirectory/$1 [r=301,nc]
I haven't tried it, but mod_proxy_html might be able to do this. From the documentation:
mod_proxy_html is an output filter to
rewrite HTML links in a proxy
situation, to ensure that links work
for users outside the proxy. It serves
the same purpose as Apache's
ProxyPassReverse directive does for
HTTP headers, and is an essential
component of a reverse proxy.
For example, if a company has an
application server at
appserver.example.com that is only
visible from within the company's
internal network, and a public
webserver www.example.com, they may
wish to provide a gateway to the
application server at
http://www.example.com/appserver/.
When the application server links to
itself, those links need to be
rewritten to work through the gateway.
mod_proxy_html serves to rewrite foobar
to foobar
making it accessible from outside.