We have an application which uses five subdomains. One of those subdomains is changing.
I would like to be able to redirect everyone hitting the old domain to be redirected to the new one, and ideally use the Rails router so that I leave the processing there using Rack.
Is there a way of redirecting all traffic to one domain, to be redirected to another.
e.g all traffic to foo.app.com get's redirected to bar.foo.com, whilst maintaining the full path & query string.
As I am hosting with Heroku I have no .htaccess.
Refraction may be able to help with that.
Related
We're trying to create pages in our Rails app that will eventually live on a subdomain of another partnering site. This would be like StatusPage, which allows users to create a status page with their account on the StatusPage site and then attach it to their own subdomain (e.g. status.usersite.com).
For example, if we wanted one of our pages (www.oursite.com/users/bobsplumbing) to be a subdomain on another site (ourservice.bobsplumbing.com), how would we go about it?
If it's useful info, we use Heroku to host the Rails app and we also utilize Route 53 and Cloudflare.
From your example I understand that you want to have multiple web apps since that would be your customer domain and your page will redirect to that page.
You will be better off to do NGINX (or whatever you use) redirects since they are faster and will take less time, being cached by the browser after the initial load.
To answer your question you can add this code to your routes:
sites = %w(bobsplumbing catsandboots)
sites.each do |name|
match "users/#{name}" => redirect("https://ourservice.#{name}.com")
end
You can also have a look at apartment gem.
I have a Ember 2 application (ember-cli) that uses a Rails API as the back end. For this application, I have enabled Wildcard DNS with my DNS Provider (Cloudflare). When a user signs up with my website, I want them to be able to use their subdomain to access their public home page.
For example:
A user named Steve signs up for my site located at awesome.com. So Steve browses to steve.awesome.com, which internally would translate to awesome.com/users/steve. How do I setup my Ember routes such that it can route based off of the subdomain?
I have come to a solution, but it isn't exactly what I was initially looking for. I realized there really isn't a reason why the URL has to be awesome.com/users/steve, and instead have decided that their subdomain (or custom domain) will act as their identifier. So let's say Steve browses to steve.awesome.com, I will figure out the host via window.location.hostname, and use that as a lookup key to pass to my Rails API and retrieve user data.
Not exactly the solution I originally was seeking, but it solves my issue!
Let's say I'm trying to create an application called Blue. Blue is a Ruby on Rails application that turns the background of any website blue. It also allows users to log in and keep track of the websites they've visited and turned blue.
In order to turn a website's background websites blue, I've created a web proxy that inserts <link HREF="http://www.example.com/blue.css" type="text/css"> into the response's body. The proxy is implemented as a rack application and is be placed inside the Rails routes using the approach from the Rack in Rails 3 Railscast:
root :to => BlueProxy, :constraints => { :subdomain => "proxy" }
I'm very concerned about security with this approach. I know by default the domain for the cookies in my application would be .example.com. If the user typed in a malicious URL, the website could manipulate the user's account. I could fix this by only allowing the www subdomain for cookies in the application. However, I'd also like the proxy to be able to store cookies for the proxied site as well.
Here are my three questions:
Is this a bad approach? Is there a better way to solve this problem?
What's the best way to keep sibling subdomain cookies separate in Rails?
Are there any other security concerns I'm missing?
This approach is dangerous, and I caution you against running a proxy for several reasons:
It brings up a host of legal issues ranging from people accessing illegal content to your hosting content for your own benefit (and modifying it).
Your bandwidth (and hosting fees) will explode if the site gets popular.
Loading content inside an iframe has ux issues, like the browser back button not quite performing as the user wants it to.
Running a proxy opens up several more attack vectors to your site (e.g. sending a permalink to a malicious site proxied through your site) that you'll have to consider from a security perspective.
Instead of running an open proxy (okay, maybe it's not completely open, but how hard is it for someone to sign up?) on your back end, consider using a browser extension or greasemonkey script on the front end that can get its set of rules from your rails app and then add the stylesheet changes on the client side.
I would like myapp.com/blog to redirect to www.myapp.com/blog. I've installed Refraction to do subdomain redirects at the Rack layer. That doesn't work on Heroku for /blog since my files in /blog are static assets. Any fix?
Sounds like you may be making this more difficult than it needs to be.
If you just want myapp.com/something to redirect to www.myapp.com/something, then goto the domain host that is currently handling the myapp.com domain and create a URL redirect record to do just that. This way, the redirect happens at the domain registrar before it even touches your Heroku server (which is how it should be handled).
An example of this would be to create the following records at your domain registrar (i.e. GoDaddy, NameCheap, etc): http://i.imgur.com/FJrMV.png
Those 3 IP addresses point to Heroku's servers. You should have already set up the custom domain add-on within Heroku if indeed you have some site similar to myapp.com and not myapp.heroku.com
Here's an article / video from Heroku that deals with a little bit of this as well: http://devcenter.heroku.com/articles/custom-domains
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.