link_url not responding to config.action_controller.relative_url_root - ruby-on-rails

I'm running my Rails app on port 3000, with mod_proxy forwarding requests to /rails, to http://localhost:3000.
I'm attempting to make link_to take the subdirectory into account. (For example, /rails/user/login instead of /user/login)
But when accessing through the Apache proxy, this doesn't happen. It does, however, work when accessing http://mysite.com:3000 directly.
Any ideas? I'm tearing my hair out!

Related

Grails 2.2.5, Shiro plugin - non-standard port causing problems

I'm having great difficulty working out what's going on with a Grails 2.2.5 application which uses the Shiro plugin (v.1.2.1). This is on a system which has been working fine for a couple of years. It sits behind an nginx remote proxy server, which has hitherto been listening on ports 80/443. We've just moved the test rig, and it now shares a server with an Apache installation which has those ports, so we have nginx listening on ports 8070 for http and 8443 for https. It's largely working, but there are some puzzling problems with redirects when a user is not authenticated, and these problems seem to be coming from Shiro (although I'm having difficulty being certain).
Basically what's happening is that when an unauthenticated user goes to 'https://myapp.com:8443/admin/', the Grails application is issuing a redirect which takes them to 'https://myapp.com:8443/auth/login?targetUri=%2F' - i.e., the context has been stripped out. It should be 'https://myapp.com:8443/admin/auth/login?targetUri=%2F', and is so on the live server, which uses the standard ports (80/443). In fact, when I look at the Location header in the response, what it's actually responding with is 'http://myapp.com:8070/auth/login?targetUri=%2F' (i.e., with the http port, which is no problem as nginx is handling SSL).
Because my code, in AuthController.groovy, doesn't actually get involved until it receives the /auth/login request, this problem doesn't seem to be coming from anywhere in my code, and must be coming from the Shiro plugin. But why would the non-standard port be causing this problem (stripping out the context)? And more importantly, what can I do to solve it?
I think I may have been wrongly ascribing blame to Shiro or the Shiro plug-in here. I have solved the problem, which seems to be caused by a quirk in Grails itself.
In version 1 of Grails, one had to set grails.serverURL correctly in Config.groovy in order for redirects to work properly, but with version 2 that was no longer necessary, and in fact this property was commented out in a newly created app.
However, whatever was done doesn't seem to play nicely with non-standard ports. If the server port is something like 8070 or 8443, as I was using the redirect is incorrectly formed.
I have resolved the issue by reinstating grails.serverURL and making sure it's configured correctly. Now redirects work as they should again.

display domain instead of ip address as url

my website is www.somedomain.me, rented server from DigitalOcean, domian name is from Namecheap,
I redirected www.somedomain.me to http://104.236.xx.xx:6060/main/ ,
but when I open up www.somedomain.me it display the url as :
**http://104.236.114.32:6060/main/** or
**http://104.236.114.32:6060/main/resume.html** or
**http://104.236.114.32:6060/main/contact.html**,
how can i let it display as
**http://www.somedomain.me** or
**http://www.somedomain.me/resume.html** or
**http://www.somedomain.me/contact.html**
Thanks!
Lazy way?
Set up a URL Frame
Good way? The way the DNS gods intended?
If you have a dedicated IP, point it with an A record.
It's key to note A records can't specify a port. If at all possible, considering migrating your service to port 80? I understand sometimes this isn't possible but it'll make life a hell of a lot easier.
Edit: as for a redirect method, you could run a website on port 80 with like a line or two of HTML in an index.html to redirect to the proper port. Again assumes port 80 is unoccupied.
Previous post to clarify rewrite vs redirect
Michael makes a good point, however, in that if you want your customer to not have to include the port, you either have to do it for them via the redirect method you're using, or move your service to the default HTTP port 80. If you redirect the customer's browser to an IP address, that is what will be populated in the address bar and the Host header.
You might be able to do this thru Http Reverse Proxy. This wiki might guide you in the right track. You can use Heroku, Nginx, apache, etc. Though, apache might be overkill for the purpose.

Omniauth redirection working only in certain cases (with ports)

I'm setting up omniauth (just trying to get the facebook provider working for now).
I'm on my local computer running nginx on port 80. I route all requests to port 8080 and run the default webrick server on 8080.
I've set up omniauth pretty far, but now things only go smoothly in certain instances.
If my browser hits http://localhost/auth/facebook I get an error saying:
URI::InvalidURIError, the scheme http does not accept registry part: app_server (or bad hostname?)
If I hit however http://localhost:8080/auth/facebook, then facebook gives me an error message like Invalid redirect_uri: Given URL is not allowed by the Application configuration.". This makes sense since my site url is set to http://localhost not http://localhost:8080.
If I change the site url to http://localhost:8080, then things start to work (at least this far into the authorization process)
By the way, it's not just localhost by itself that is causing the problem. If I edit /etc/hosts and try something like dev.example.com it acts the same way, with dev.example.com not working and dev.example.com:8080 working.
Why can't I get it to work with just localhost? Is it something wrong with the way nginx and webrick talk to each other? I can't imagine that'd be the problem, but it's the only difference I see in what works and what doesn't. Any ideas why the URI error is occuring?
You need to edit the domain names for your facebook application. Go into https://developers.facebook.com/apps and edit the settings for that application. Set the site domain and app domains to whatever domain you want to allow redirection to (eg. example.dev)

Subdomains and locally installed Rails app

I can't figure out what I'm overlooking, perhaps it's obvious or lack of understanding.
The app I'm working with uses subdomains which on the hosting server work properly. I figured locally installing would kick up some issues around routing, so I read up on making changes to /etc/hosts and using the Ghost gem. Both seem to work fine i.e. localhost:3000/ becomes myapp.local:3000 but I don't understand how to go about logging into a subdomain account. Here's an example...
myapp.local:3000/session/new = the default login page for the app
myapp.local:3000/signup = default signup page
I can create an account here e.g. Sub1
The thank you page is shown w/ the reference to sub1.myapp.com which points to the hosted app (the local db shows this domain as well)
sub1.myapp.local manually added to /etc/hosts and dscacheutil -flushcache
sub1.myapp.local:3000/session/new is the subdomain
login attempts return that this isn't a valid domain. This seems to make sense because the local db shows the url as sub1.myapp.com on the hosting server.
So my question is whether there's a local workaround that I can use for development or have I totally missed a fundamental concept along the way?
you might just want to try putting the actual dot com in your /etc/hosts file.
ie:
127.0.0.1 sub1.myapp.com
127.0.0.1 myapp.com
127.0.0.1 anyothersubdomains.myapp.com
what this usually does is trick your computer into thinking it is the host of all of those, so you can't go to the real site anymore in a web browser.
if you do want it to be .local, presumably so that you can refer to the real online site while working on a local copy, you should probably take a look in app/controllers/application_controller.rb (sometimes application.rb) and look for logic in there that helps determine what to do depending on the subdomain. maybe its hard coded to only look for a .com or something.
If you are using the webrick server or something like Puma for development you can use lvh.me to access your subdomains. e.g.
http://sub.lvh.me:3000/
http://lvh.me:3000/ is equal http://localhost:3000/

Rails/Passenger/Apache: Simple one-off URL redirect to catch stale DNS after server move

One of my rails apps (using passenger and apache) is changing server hosts. I've got the app running on both servers (the new one in testing) and the DNS TTL to 5 minutes. I've been told (and experienced something like this myself) by a colleague that sometimes DNS resolvers slightly ignore the TTL and may have the old IP cached for some time after I update DNS to the new server.
So, after I've thrown the switch on DNS, what I'd like to do is hack the old server to issue a forced redirect to the IP address of the new server for all visitors. Obviously I can do a number of redirects (301, 302) in either Apache or the app itself. I'd like to avoid the app method since I don't want to do a checkin and deploy of code just for this one instance so I was thinking a basic http url redirect would work. Buuttt, there are SEO implications should google visit the old site etc. etc.
How best to achieve the re-direct whilst maintaining search engine niceness?
I guess the question is - where would you redirect to? If you are redirecting to the domain name, the browser (or bot) would just get the same old IP address and end up in a redirect loop.
If you redirect to an IP address.. well, that's not going to look very user friendly in someone's browser.
Personally, I wouldn't do anything. There may be some short period where bots get errors trying to access your site, but it should all work itself out in a couple days without any "SEO damage"
One solution might be to use Mod_Proxy instead of a rewrite to proxy traffic to the new host. This way you shouldn't see any "SEO damage".
I used rinetd to redirect the IP traffic from the old server to the new one on IP level. No web server or virtual hosts config needed. Runs very smoothly and absolutely transparent to any client.

Resources