Got an app running great on Heroku, only issue is that their custom-domain SSL solution is way expensive (http://docs.heroku.com/ssl), leaving piggybacking of their *.heroku.com as an only viable option. The good thing is that my app only requires SSL for a couple of pages (for ordering). Right now, I use "ssl_required" in my controller for those couple actions. Any idea on how to create a before_filter that would bump the user to https://myapp.heroku.com just for those two actions and redirect to http://www.myapp.com for anything else? Ugly ugly, but seems like the best way to go for now.
You could hack/monkey-patch:
SSL Requirement plugin (github.com/rails/ssl_requirement), so that it redirected to different hosts.
BTW if you plan to host multiple applications, they can share one multi-domain certificate (and one pricey SSL Addon). Here's more detailed description: http://wojciech.oxos.pl/post/277669886/save-on-herokus-custom-ssl-addons
Related
I'm using a domain name with this general structure: http://mydomainname.com/
However, when I click it, I get a 404 message saying:
And when I look in the URL, it's not http://mydomainname.com/ but surprisingly http://mydomainname.com/YkPWZ/.
How did YkPWZ/ appear automatically and what can I do to eliminate this issue? Sometimes accessing http://mydomainname.com/ works fine, but most of the time the browser automatically tacks on some random characters at the end of the URL, throwing the 404 message. This is not a browser-specific issue and I've had a few colleagues replicate this issue on different operating systems (both desktop and iOS).
P.S. If it matters at all, I generated my website using Github Pages (markdown files, not HTML).
I'm quite certain this is an issue on the GoDaddy side of things, though I'm unable to find any official documentation on the subject. As noted in comments above, the redirect isn't coming from GitHub Pages.
I found an old thread discussing the issue. Here is a brief summary:
GoDaddy may use redirects like this to handle load balancing on their shared hosting servers.
In several cases, users contacted GoDaddy to ask about the problem and
had the issue resolved, but
were never told the technical specifics of what was happening.
If you wish to stay with GoDaddy I recommend contacting them and sending them to the link I found above. They may be able to resolve the issue for you, though I wouldn't expect an explanation.
Alternatively, you can use another web host. In many circles, GoDaddy isn't rated very highly. It's lucky that there are so many web hosts to choose from. Alternatively, you can use a custom domain directly with GitHub Pages, bypassing a third-party host entirely.
I'm building a tenanted Rails application on Heroku which uses subdomains for each tenanted instance. The problem is I can't seem to get CloudFlare to properly cache a subdomain.
I have my Application hosted on heroku at say whatever.herokuapp.com
And using CloudFlare I'm pointing my main application at heroku's CNAME (whatever.herokuapp.com) and that works fine.
I'm using a wild cards *.mydomain.com on Heroku and then using CloudFlare again to point at them.
So say I create an app myinstance.mydomain.com on CloudFlare -> whatever.herokuapp.com
because I'm using the *.mydomain.com on Heroku it works fine.
BUT when I try to turn on the Acceleration (CloudFlare caching) it immediately breaks and all I see is a CloudFlare error Error 1001 telling me:
Most likely: if the owner just signed up for CloudFlare it can take a few minutes for the website's information to be distributed to our global network.
From their help desk:
Fundamentally in a standard set up the domain needs to be added to
CloudFlare in order for us to understand how to route traffic for that
domain.
If you wanted a setup where anybody in the world could CNAME to your
CloudFlare configuration, that is possible but it's an Enterprise
feature. We call it "Managed CNAME" - if that's something you're
interested in do let me know and I can put you in touch.
FYI, CloudFlare Enterprise averages at $5,000 a month.
CloudFlare is great in that it just works without much customization starting at zero cost, but unless your multi-tenanted app is for Bank of America or other Fortune 500 company I'd suggest something like Fastly ($5-50/month) or some other DIY caching solution that allows you to setup caching as you need rather than a one-size-fits-all top down solution.
https://devcenter.heroku.com/articles/fastly
Works directly with Heroku but there might be other solutions that work equally well.
That error can also occur if you're pointing a domain/subdomain not on CloudFlare to a domain that is on CloudFlare (creates a DNS resolution lookup error). I would probably contact CloudFlare support for additional assistance and troubleshooting.
I've been googling for the past hour on this but can't quite get it nailed down. Perhaps you guys can assist here!
Here's what I'm trying to do:
Old site is:
old.tld
New site is:
new.tld
A bunch of folks access one particular legacy url on the old site via SSL, i.e.:
https://www.old.tld/old_url
I've just setup a brand new site on Heroku, running Rails 3, on the new domain.
I also have installed Heroku's SSL Endpoint Add-on and am using a new secure subdomain:
secure.new.tld
I've got a bunch of redirects & constraints in my Rails routes.rb to redirect old -> new and pass the appropriate requests. Everything works perfectly for the non-SSL stuff.
The only thing I can't seem to get working properly is the redirects of
https://www.old.tld/old_url -> https://secure.new.tld/new_url
Safari doesn't seem to mind, but Chrome is throwing a "This is probably not the site you are looking for!" error. It says (only when trying via SSL):
"You attempted to reach www.old.tld, but instead you actually reached a server identifying itself as secure.new.tld" Etc.
(which is exactly what I want, but Chrome doesn't seem to approve ;)
Any thoughts on how to properly configure?
The seamless solution it is to get a SAN (Subject Alternative Name) certificate that has both the old name and the new name.
Another way is to insert a non-secure request in between the two secure requests: redirect from https://www.old.tld -> http://secure.new.tld -> https://secure.new.tld. I haven't actually tested this, but it should work in theory. If it doesn't "just work", then you might try adding an actual page at http://secure.new.tld with a message and a link to https://secure.new.tld.
I could use some wisdom from any developers who have worked with Rails and SSL. I have a fairly simple app and I'm in the process of implementing payment processing. Obviously payment processing calls for SSL, so I'm setting that up now.
My intention when I started working on this today was to find the simplest / cleanest way to enforce SSL on specific controller actions - namely anything having to do with payment. I figured there was no reason to run the rest of my site on SSL.
I found the ssl_requirement gem which seems to take care of setting SSL per-controller-action without much difficulty, so that's good. I also found this question which seems to indicate that handling SSL with a gem is now out-of-style.
I also found several answers / comments etc. suggesting that a site should just use Rack middleware like Rack-SSL to force the entire site to SSL mode.
So now I'm kind of confused, and not sure what I should do. Could anyone with experience working with Rails 3 and SSL help me understand:
Whether I should force the whole site to SSL, or only per certain actions.
What gotchas to look out for using SSL in Rails (I've never done it before).
If per-controller is the way to go, whether it makes sense to use the ssl-requirement gem or whether I should just use the new routing and link helper options...
I'd very much appreciate your insight, this has become a paralyzing decision for me. Thanks!
I've found myself "paralyzed" by this decision in the past, and here's what I think about each time.
First, keep in mind that some browsers will throw pop-up warnings if you keep switching out of and into SSL, or if you serve some content (the page) with SSL and other content (images, css) without. Obviously that's not a good experience for users.
The only possible downside to requiring SSL everywhere is performance. But unless you're expecting 1000+ users/day who will be doing lots of things that *don't * require SSL, this is negligible.
SSL is handled at the Apache/Nginx/whatever level. So if you decide to put your entire app behind SSL, it makes most sense to deal with it at the Webserver level (redirect http:/yoursite.com to https://yoursite.com.
And if, for performance reasons, you decide not to put everything behind SSL, then it still could make sense to handle SSL redirects at the Webserver level. Allowing your user through your Webserver, then sending him through half Rails stack, just to boot him back out to start over again is very wasteful.
Of course there's something to be said for simplicity and domains of knowledge, which would suggest handling redirects in your Rails app or middleware, since it "knows" what's safe and unsafe.
But those are things you'll have to weigh yourself. It depends on whether raw performance or simplicity of development/maintenance is more important.
I usually end up with a virtual host for http://mysite.com which redirects everything (or sometimes only certain uris) to https://mysite.com/$1. Hope that's helpful.
I am completely new to ruby and I inherited a ruby system for a product catalogue. Most of my users are able to view everything as they should but overseas users (specifically Mexico) cannot contact the server once logged in. They are an active user. I'm sorry I cannot be more specific, and the system is private so I cannot grant access.
Has anyone had any issues similar to this before? Is it a user-end issue or a system error?
Speaking as somebody who regularly ends up on your user's side of the fence, the number one culprit for this symptom is "Clueless administrator". There are many, many sites which generically block either large blocks of IP space or which geolocate and carve out big portions of the world.
For example, a surprising number of American blogs block Asian countries (including Japan) out of a misplaced effort to avoid DDOS attacks (which actually probably originated in Russia or China but, hey, this species of administrator isn't very good on fine tuning solutions). I have to hop over to my American proxy server to access those sites.
So the first thing I'd do to diagnose your problems is to see whether your Mexican users are making it to the server at all, or whether they're being blocked somewhere earlier (router? firewall? etc). Then, to determine whether the problem is on your end or their end, I'd try to replicate the issue with you proxying your connection through a Mexican proxy and repeating the actions they took to cause the issue.
The fact that they get blocked after logging in could indicate that you have https issues , for example with an HTTPS accelerator installed [1], or it could be that your frontend server is properly serving up the static content but doing the checking on dynamic requests only.
[1] We've seen some really weird bugs at work caused by a malfunctioning HTTPS accelerator.
If it's working for everyone else then it would appear that the problem is not with Ruby or Rails working, since they are...
My first thought would be to check for a network issue: are the Mexican users all behind the same proxy server and/or firewall?
Is login handled within the Rails application or via some other resource? Can you see any evidence that requests from Mexican users are reaching your web server at all?
Login is handled by the rails app. Am currently trying to hunt down the logs, taking some time as again I am new to this system.
Cheers guys
Maybe INS is cracking down on cyber-immigration.