Why is it that if I create a cookie on www.example.com and check it on example.com, the cookie doesn't exist there? I am planning to just use .htaccess redirect non-www to a www domain. But how do I solve this?
Browsers are the main culprit here, not PHP. They store by domain, and don't know that www is a special case; from their perspective, www.mydomain.com and mydomain.com are different strings, and therefore have different security policies. However, there is something you can do.
When setting the cookie, use .mydomain.com (with the leading dot). This will tell your user's browser make the cookie accessible to mydomain.com and all subdomains, including www. PHP's setcookie has the argument $domain, but it's fifth on the list, so you may need to set $expire and $path to their default values in order to get at it.
setcookie('name', 'value', time()+3600, '/', '.mydomain.com');
For consistency, however, you may wish to consider rerouting all web traffic to a specific domain, i.e. send mydomain.com traffic to www.mydomain.com, or vice-versa. My vague knowledge of SEO (edit if incorrect) tells me that it's helpful so as not to have duplicate content, and it saves you all such authentication issues. Additionally, if you store assets on a subdomain, having cookies on there slows down traffic by having to transport it each time, so storing application cookies only on www earns you that speed boost.
Here is a tutorial on how to accomplish such a redirect in Apache.
setcookie("CookieName", "value", time()+3600, "/", ".mydomain.com");
I believe you can set the cookie at example.com (really .example.com) and it will be sent if they go to www.example.com, but not vice versa. This standard security policy is to prevent users' private data from being sent to unintended servers.
Personally, I use virtualhosts in my apache2.conf:
<VirtualHost *:80>
ServerName example.com
RedirectMatch (.*) http://www.example.com$1
</VirtualHost>
... in this example, everyone trying to load e.g. http://example.com/index.html is redirected to http://www.example.com/index.html.
because php translates www.mydomain.com differently from mydomain.com. If the domains are not 100% identical the cookie wont match.
And I'm sure the browser also looks for 100% match of the domain name before allowing servers to overwrite them.
Just use .htaccess to redirect. It's the only SURE way to tackle this in all browsers.
Related
So I want to force the user to access the https version of my page rather than the http. And according to this post all I have to do is this:
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.yourdomain.com/$1 [R,L]
But MY site resides in a folder within the main directory, so it's in www.domain.com/Folder. So should this htaccess code go inside the main directory or in the subdirectory. Because I do not want to change the way the access the main site, only the folder.
This is a not-so-good method of going about this, especially if you have access to httpd.conf. The better method is to create TWO virtual hosts. One for your standard port 80 stuff, which simply has an unconditional redirect to the SSL version, e.g. in pseudo-ish .conf talk:
<VirtualHost example.com:80>
RedirectPermanent / https://example.com
DocumentRoot /some/fake/path
</VirtualHost>
<VirtualHost example.com:443>
normal site stuff here...
</VirtualHost>
This has the advantage of leaving the redirect viable even if a config messup disables .htaccess files, plus serving up bogus/non-existent content if SSL dies for whatever reason.
You can leave it in the root directory but change it to:
RewriteRule ^(your-directory/.*)$ https://www.yourdomain.com/$1 [R,L]
Keep in mind, though, that before the redirect happens, the cookies and query parameters with possibly sensitive data has already been sent in clear text, so remember to use the secure cookie atribute if you use cookies.
Your site can be vulnerable if you're redirecting from http to https. Take a look at this for some more information on that.
http://www.thoughtcrime.org/software/sslstrip/
seems silly to "force ssl" till they fix the big gaping security hole it opens up in browsers in the name of "site verification"
this has no real basis and there is potential for abuse by a rogue CA, rogue state, or corruption.
(and the "verification" is useless anyway not being based on user wishes not anyone actually looking at the sites - there are plenty of phishing sites out there with "valid" certificates!)
there is way too much misinformation being bandied around about SSL
you get the same encryption with a self signed certificate but browsers tell users you site is "untrusted" (with of course no basis - "not checked" or "not verifiable" would be what any warning should actually say - warnings need to be informative not something that just scares users so much most of them just close them without even reading the rest of the warning!)
until this is fixed in browsers I cannot recommend the use of SSL at all in a web site context.
meanwhile all I can recommend to forget port 443 and implement your own encryption layer (or use something like ssh if it doesn't need to be a browser)
I am having a problem over and over where a member is logged into my site using www. and if he accesses a link without www., the session variables don't carry over.
What's the way to make them both access the same place?
Ideal
Your site should reside on one canonical domain. So you should pick either www. or the top level domain and change all your links so that they point to one web address. It would be wise to switch to setting the domain in a configuration and using that to create web addresses across your application - this way you can easily change the URL later if you wish.
If you are running Apache you can also easily redirect traffic from one domain to the other by adding the following to the .htaccess file of your site:
#enforce the use of the www. subdomain on the sites URL
RewriteCond %{HTTP_HOST} !^(www.).*$ [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
I should also mention that there is a growing movement away from using the www. subdomain as the main "URL" for a site. See: http://no-www.org/index.php
Less ideal
You change the cookie configuration when you set it so that it will work across domains. This is described on the setcookie() manual page with the domain parameter:
The domain that the cookie is available to. Setting the domain to
'www.example.com' will make the cookie available in the www subdomain
and higher subdomains. Cookies available to a lower domain, such as
'example.com' will be available to higher subdomains, such as
'www.example.com'. Older browsers still implementing the deprecated ยป
RFC 2109 may require a leading . to match all subdomains.
The only issue with this is that your site will still be accessible via two URLs.
Solution 1: Set the cookie's domain to the domain name without the www prefix (this way both requests should be sent with the cookie data).
Solution 2: Redirect everyone using the variant without the prefix to the one with the prefix (e.g. using mod_rewrite).
Modify your server configuration to 301 redirect traffic from 'yourdomain.com' to 'www.yourdomain.com'
when some user access the www.* site, redirect then to the other site automatically
There is a website with several subdomains.
On the main subdomain cookies are set:
#setcookie( $name, $value, $expires, '/', '.www.mysite.com');
I can see the cookie on www.mysite.com and sub1.mysite.com.
The directories are:
www.mysite.com: public/index.php
sub1.mysite.com: public/sub1/index.php
How can that be possible that I can't see it in the new subdomain sub2.mysite.com?
sub2.mysite.com public/sub2/index.php
Setting the domain to 'www.example.com' or '.www.example.com' will
make the cookie only available in the www subdomain.
If you want to make the cookie available on all subdomains of example.com (including example.com itself) then you'd set it to '.example.com'.
make sure the path is set to / so it works for the whole site, otherwise it might not work for sub directories on your site
Using # is not a wise act in general but using it in front of setcookie() is exceptionally unwise, if not to say a stronger word.
Subdomain should be set to .mysite.com'
path should be set, not omitted. If you want to have access to the cookie in any directory, set path to /.
Nevertheless, the reason can be any. One have to debug their code, not asking for the possible reasons.
I am currently running two websites. I am able to add my domains and set the root folder to / instead of /domain1.com and /domain2.com. That way both websites go to the same folder, however they both maintain their domain names (no redirects). My code determines whether the user is from domain1.com or domain2.com and displays the appropriate content using PHP.
Now, I have switched to another web hoster. The problem is that they don't allow you to specify where the root folder is: so it has to be /domain1.com and /domain2.com. They also don't seem to allow access to httpd.conf to edit VirtualHosts.
I have tried using .htaccess to do a redirect, but the problem is that when I go to domain2.com, it redirects straight to domain1.com, and it doesn't keep its host name of domain2.com.
I have also tried setting up symlinks, but it seems to be doing the exact same thing.
Is there any way to solve this?
Can you do a rewrite rule similar to the following (don't trust my syntax)?
# if domain2.com, send all requests to domain1.com
RewriteEngine on
RewriteRule ^(.*)$ ../domain1.com/index.php/$1
So if someone does go to domain2.com, all requests are passed through the index.php file on domain1.com for processing (I presume you're doing something similar already).
You should be able to set up symbolic links using ssh that don't redirect to the other domain. I have several .co.uk domains that use the same data as the .com that don't redirect. What host is it? You should be able to do this, maybe email them asking why it redirects.
Sure it's not in the htaccess file to redirect the domain2.com to domain1.com?
I have two domain for my site. The main site is example.net, and I have example.com.
If someone type example.com (or www.example.com, http://example.com or whatever) then I redirect them to example.net (my provider set domain redirecting).
So, is it possible, to take into a php variable if someone come from .com or directly type .net?
Thank you
If the host is doing the redirecting and you don't have control over it, then it might be worth looking at $_SERVER['HTTP_REFERER'] depending on how they are doing the redirect. Note that this is header not guaranteed to be there and can be spoofed by the client.
why don't use just redirect them to .net?from=com ?