I'm having some security issues with certain subdomains when I have force_ssl enabled in production.rb.
It seems something like https://subdomain.example.com works fine, but I have a client linking to https://www.subdomain.example.com and that www is throwing things off. My routes file is already a bit complex but I'm drawing a blank on how best to handle this redirection. I think I need to check for the number of subdomains present and just remove the first one, right?
Related
I use a subdomain that I use for my development site, with the tld being production. I password protect the subdomain and instruct robots not to traverse etc. It has worked for 9 years. I came in after not updating my website for the past year, and found that the "root" path specification (e.g. "/subdir/file.html") now no longer resolves to root of the subdomain, but to the tld.
e.g. I go to "mysubdomain.mysite.com". I notice that the address bar shows mysite.com/mysubdomain/index.html" (seems wrong). Then, clicking a link coded as "/subdir/file.html" goes to mysite.com/filex.html rather than mysubdomain.mysite.com/filex.html.
So, I think maybe there is a problem at the hosting site, maybe something I should modify in cpanel, but not sure.
I'm working on a Rails 3.1.0 app that needs to have ssl in some pages depending on the user.
I setted config.force_ssl to false in config/enviroments/staging.rb. Added a before filter that decides whether or not to redirect to http. The redirect works in development if I clean the cache.
The thing is in staging, it results in a redirect loop. I believe that force_ssl uses a permanent redirect, therefore when the DNS is asked about a page in my app, it still tries to redirect to the page with ssl. Does this make any sense?
What are my options?
EDIT
I cleaned the cache. This only solves the problem the first time I enter the page. Lets say I refresh all cache and enter the http page. This displays the http page. When I exit the page, enter another page that has ssl and try to go back to the http page, the infinite redirect starts again.
The solution I implemented was to redirect to a unsafe subdomain. Let's call it 'unsafe'. So when I need to redirect to a http page, I redirect to http://unsafe.mydomain.com. This solves the infinite redirect, but some https pages are still being cached.
I guess the real question is when is it useful to use :status => :moved_permanently because It seems it causes the page to cache and it becomes dificult to clean this cache?
Firstly, why are you not just forcing SSL for all pages? There is very little performance overhead but running in mixed mode you introduce a the potential of leaking what you thought were secure cookies if you're not careful. SSL everywhere :)
Now to your question, I doubt this has anything to do with DNS and is more likely to do with the regex of pattern matching logic around when it should redirect. Does it include the hostname/domain? If so does it match the domain you run as in staging?
I'm running into an issue with getting the right cookies for the current subdomain. I have two different instances of the same application, one running at the www subdomain and the other running at the test subdomain, but it seems like the test app is pulling in cookies from the www instead, even if there are explicit cookies for .test.domain.com (because it's different instances the same application, the cookie name is the same, but I am not looking to share sessions or cookies between the two instances).
Is there any way to specify what domain Rails should be looking for its cookies for? I have config.cookies.domain and config.action_controller.session[:domain] both set to "test.domain.com" (on the test app), but it doesn't seem to make any difference (and, as well, the cookies being set by the test domain are for some reason ending up with the domain .test.domain.com instead of test.domain.com and I'm not sure why, or if it's relevant).
Update: To make this more complex, I realized I do actually need the dot-prefaced cookie domains (ie. .test.domain.com and .domain.com), because in general, subdomains are supposed to share the main domain's cookies and session (it's only that the test subdomain is actually it's own application rather than being a subdomain of the main application). Obviously .domain.com cookies will apply to test.domain.com, but is there any way to make the explicitly test.domain.com ones take priority?
We need to default URL to unique name. If it is www then with no prefix or vice versa. So decision to be made is either stick with www or with no prefix.
With no prefix cookie is set for all sub domains. What are other downsides for it? Or benefits?
Basically we need this for OpenID as OpenID will make users look different if they came from www or with no prefix.
As our site is new so we can go with either one. Also, how the domain name looks is not much of a concern.
You probably want to redirect (with a HTTP 301 - Permanent Redirect) one to the other anyway, since maintaining consistent urls is much easier that way. So whichever you decide, just make sure the actual authentication is done after the redirect, and users looking different won't be an issue.
That said, if you want www or not depends entirely on how other things in your appliction works. You mention that cookies for domain.com will be saved for all subdomains - is this something you want? Are you ever going to need to differentiate (for example, by allowing users to set up their own authentication systems for subdomains as a shared hosting service might do)?
If none of the differences you find between including and excluding www matter to your application, I'd go for not using www. The main reason for this is my picture of current trends on the internet - more and more applications (SO is an example of this) tend to leave the www out, both when linking to their own sites, and in marketing of different kinds.
However, the main point is make both work. You don't want your site to break because the user did(n't) type www at the beginning of the url.
By not using the www subdomain, you can suffer a performance hit when delivering static content, as noted here: http://developer.yahoo.com/performance/rules.html#cookie_free. As I understand it, if you use http://example.com/ and http://static.example.com for static content, any cookies you set on the main domain will be passed with requests to your static subdomain.
This can be avoided quite easily, by buying a distinct domain for static content. However, this can certainly be dealt with by using a www subdomain.
Then again, this is a very minor con, and really only comes into play when you're dealing with a high-demand site. (For example, Digg uses http://digg.com and http://*.diggstatic.com).
Ultimately, I would say that this is such a minor problem that it can probably be dealt with if performance starts to suffer. Don't optimize prematurely, and all that...
And, as #Tomas Lycken points out, make sure you account for www even if you don't use the subdomain.
I have a website (www.mydomain.com) that is secured with an SSL certificate. It is an ASP.NET website and I have forced certain pages via code to be required to use the https:// prefix. If they don't it will redirect them to the https:// equivalent. Is this a good practice? Is there an easier way to do this? Not every single page requires SSL.
Also, when the users use my URL in the form of mydomain.com instead of www.mydomain.com they get a certificate error because the certificate was registered for www.mydomain.com. Should I use the same approach as I am with the http:// and https:// issue I mentioned above? Or is there a better way of handling this?
Your approach sounds fine. In my current project, I force HTTPS when a user goes to my login page, (Based on a config flag which lets me test locally without dealing with needing a cert). This allows me to access other pages unsecured which is handy.
I have a couple places where our server grabs the output of other pages (rendering to html to PDF and fetching dynamic images for example). Because of our environment, our server can't resolve it's public name, so if we were to force ssl at the site we'd have to add, our internal IP address (or fake the domain name).
As for your second question you have two options to handle the www.example.com vs example.com. You can buy a certificate that allows you to have multiple domain names. These are known as UCC certificates.
Your second option is to redirect example.com to www.example.com or the other way around. Redirecting is a great option if want your content to be indexed by google or other search engines. Since they will see www.example.com and example.com as two seperate sites. This means that links to your sites will be split reducing your overall page rank.
You can configure sites in IIS to require a Cert but that would A) generate an error if someone isn't visiting with https and B) require all pages to use https. So, that won't work. You could put a filter on IIS that checks all requests and redirects them as https calls if they are on your encryption list. The obvious drawback here is the need to update your list of pages every time a new page is added (e.g. from an XML file or database) and restart the filter.
I think that you are probably correct in building code into the pages that require https that redirects to an https version if they arrive via http. As far as your cert error goes, you could redirect with a full path (that includes the www) instead of a relative path to fix this problem. If you have any questions about how to detect whether the call uses https OR how to get the full path of the current request please let me know. Both are pretty straightforward but I've got sample code if you need it.
UPDATE - Josh, the certs that handle multiple subdomains are called wildcard certs. The problem is that they are quite a bit more expensive than standard certs.
UPDATE 2: One other thing to consider is to use a Master page or derived class for the pages that need SSL. That way, instead of duplicating the code in each page you can just declare it as type SSLPage (or use the corresponding Master page) and have the Master/Parent class handle the redirect. Again, you'll need to do some URL processing if you take this approach but it is pretty trivial.
Following is something that can help you:
If it is fine to display all your website pages with https:// then you can simply update your code to use https:// and set two bindings in IIS. One is for http and another is for https. In this way, your website can be accessible through any of the protocol.
Your visitors are receiving a name mismatch error because the common name used in your SSL certificate is www.mydomain.com. Namecheap is providing RapidSSL certificates through which you can secure both names under single SSL. You can purchase this SSL for www.mydomain.com and it will automatically secure mydomain.com (i.e. without www).
Another option is you can write a code to redirect your visitors to www.mydomain.com website even if they browse mydomain.com.