Scratching my head over this.
Recently opened a new reverse proxy to our site via nginx to support a new domain. When you access via either old.server.com or new.server.com you hit our backend.
If you hit via old.server.com, all the url helpers work fine and produce valid absolute URLs. But if you hit via new.server.com (the new reverse proxy host) then url helpers only work correctly in views. URL helpers used in the controllers use the hostname plus the actual unicorn port -- which is incorrect for URLs we want to send out.
Even more confusing, this is only the case in the controllers. In the views, this works correctly in all cases. In order to make this work in controllers when using the new.server.com I need to override the default_url_options method in the ApplicationController.
Yes, I have both the Rails.application.routes.default_url_options[:host] and Rails.application.routes.default_url_options[:protocol] configurations setup correctly.
I feel like I probably missed forwarding some required header in the reverse proxy, but haven't figured it out. But more importantly, why are the views and controllers using different contexts for generating absolute URLs?
UPDATE:
The difference between the two hosts appeared to be the value being provided by the reverse proxy for the Host header. The "old" proxy was sending the public host for it, and the "new" proxy was sending nothing. Rails appears to use the Host header in constructing URLs in the absence of explicit data. In order to fix this I either need to set the Host header correctly or implement the default_url_options method in my controller.
So, I now have working code, but it seems like a Really Bad Idea(TM) that controllers and views are not using the exact same code/setup for creating URLs. Is this just standard rails, or did I miss some configuration?
Related
We're breaking our monolithic Rails application in to microservices. Our services are hosted on AWS and are behind ALBs. We cannot use host based routing as we are multi-tenant via subdomain, and it would be an SSL nightmare to maintain the required certs for each tenant/environment/service combination. So we are using path-based API routing with rules on the load balancer. A request looks like this:
Client -> www.example.com/api/:service_name/the_rest_of_the_path -> ALB -> route to rails service by name of :service_name
Because ALB cannot modify the path of a request before it sends it on to the serive, when it reaches the Rails services the path is still /api/:service_name/the_rest_of_the_path . This means in order to route to the proper controllers/actions in this case, we'd need to actually create a rails scope on namespace of /api/:service_name . This would work in theory but it has two drawbacks.
Firstly it means local developers have to deal with ALB/client specific concerns -- the path used for external service/cluster routing for ALB.
The second is that it couples the application to that path. If the load balancer decided the path should be /:service_name/the_rest_of_the_path instead then it would mean changing the application code in conjunction with the load balancer rules to accommodate it. It's not optimal and I'd prefer to avoid it if at all possible.
I thought then perhaps we could introduce a webserver to the mix, in between the load balancer and the application layer. I worked on a proof of concept for this and had it stripping out /api/:service_name before it got to the service -- leaving the Rails app with just "the_rest_of_the_path" which is all it cares about. Great! Perfect! Or so I thought.
It works well enough to route initial requests to, It however falls flat when any sort of redirects or links are used by taking the current path (as Rails sees it) in to consideration.
In the event /api/:service_name is stripped off before it hits the service, any subsequent links or redirects made from the Rails server itself naturally do not include it in there any longer. You may be on www.example.com/api/:service_name/foo/bar but Rails only thinks you're at /foo/bar. When it tries to tack something on to the path for a redirect or link like /foo/bar/baz, it loses the thing that identifies what service to send it to so the route dies at the load balancer.
This has particularly been an issue with Omniauth/Oauth2 flows for us. Omniauth wants to live at /auth/:provider by default. If the request path is actually /api/:service_name/auth/:provider then it won't match and the Oauth flow wont initiate. Further if there is a failure with the Oauth flow, Omniauth will hard redirect to www.example.com/auth/failure -- which of course does not resolve as the LB does not know where to route the request to.
If we provide a path_prefix to Omniauth as /api/:service_name/auth then it wont match when testing locally at /auth and it won't initiate the flow there.
We won't have control over all of the gems we use and where they redirect to so my question is: Is there a proper way of hanging Rails API microservices off a path on a load balancer, and not have to pull teeth to preserve the necessary prefix in all routes and links and redirects? Something that is essentially a global base href that we can set there, but not set locally so that we can continue to develop at localhost:3000/path instead of remembering to use (and coupling with) an LB path like localhost:3000/api/:service_name/path ?
I have two backends I want to serve from one Host. One from host.domain.com and the other from host.domain.com/path. The first frontend rule is straightforward: Host:host.domain.com.
The second is giving me some trouble. Based on the documentation I believe I should be using Host:host.domain.com;PathPrefixStrip:/path. This returns a 200 on host.domain.com/path, but when I click the link to somepage.html, it sends me to host.domain.com/somepage.html, so it returns a 404. If I go directly to host.domain.com/path/somepage.html it returns a 200. The link to somepage.html behaves correctly when I go directly to host.domain.com/path/index.html.
Are my assumptions/interpretations of the documentation incorrect or is this not an issue with Traefik at all?
This isn't really specific to traefik, any virtual path based reverse proxy that doesn't rewrite the contents of the web page returned (and few do this) have problems when the contents of that web page have absolute paths. The web page needs to either know about the "/path" and modify all the links it gives you, or use relative links, without a leading "/". This should be fixed within your website, web application, or hopefully a configuration for a web application. Depending on the application, once reconfigured, you may need to adjust the traefik rule to just "PathPrefix" instead of "PathPrefixStrip".
You should use a PathPrefix instead a PathPrefixStrip . The Strip rules remove the path before presenting it to the backend.
Since the path is stripped prior to forwarding, your backend is expected to listen on /.
I have a simple web server running Windows 2012 with IIS. I have half a dozen domains linked to this server that are basically not in use yet. I have a few more domains which are used but they could all have various subdomains that aren't supported by any site yet. So I have a default site in IIS set to catch all incoming requests that aren't handled by any other site on the server or any other server. And it's main purpose is to show a "Page not in use yet" message.
That's easy to set up but I want these pages to be a bit more fancy. So I want to have some kind of routing based on the domain name so example.com and sub.example.com and sub.sub.example.com would all be handled by the same view, but anotherexample.com would be handled by a different view and thirdexample.com by yet another view. And any domain that is not caught by this routing system would go to the default view.
And I wonder if there's a simple way to do this. Something like [route("example.com")] as a controller attribute which the system would recognize as the controller for a specific domain and it's subdomains. (And the URL path can be ignored.) I don't know if something like this already exists and have used Google but found nothing yet.
I can create a custom route, of course. But this tends to result in an if-then-else situation for all potential domain names. I need to know if there's a better method.
Use the URL rewrite module for IIS:
https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/using-the-url-rewrite-module
How do I create a sub-domain on my application server/container using Struts2.
For example, if I have a user called john15 I would like to dynamically create the sub-domain: john15.abc.com, after the user has signed in to my application at abc.com.
In general you can't. There are ways to achieve this but sub-domains are controlled by the application server and so any programmatic control over them are limited by what the container/application server offers and would probably not be portable.
Another solution (which acheives the desired effect but without trying to use struts2/application server interaction) is to use struts2 to develop a custom url tag which builds your desired urls. Then using something that re-writes urls (software such as squid, and like: http://en.wikipedia.org/wiki/Proxy_server#Web_proxy_servers). You can rewrite the URL into a format which is more acceptable to struts, possibly as a url parameter, or make it appear as part of the path which can then be parsed.
If you must do this I would advise the proxy server solution. Implement urls to reach your actions following the template:
abc.com/user/additional_path_and_parameters
then use the web proxy to rewrite user.abc.com/additional_path_and_parameters into the above.
Finally in creating that magical stuts2 url tag and possibly a reimplementation of the action tag too: You'll probably want to reuse the existing tag(s) and have it implement urls for "production" and "development" modes. In development the tag would behave exactly as the existing struts2 url tag does, but during deployment mode it will write your urls as you need them. This is important because you don't want to waste time setting up a proxy on your development machines, that would be a pain.
It is my experience that Angular Dart is agnostic to your backend server implementation. it doesn't care if your server is in java, ruby or whatever. Angular dart has the concept of views and has a module that deals with routing between them. these routes also modify the address bar of the browser when it changes views.
I have come across this issue. Though the angular router module will change the address bar, because said route doesn't actually exist as far as the backend server is concerned, and as such will always issue a 404 response.
If such is the case, then I find the ability to route to different pages via angular to be pointless. Might as well I code in a more traditional server oriented fashion to transition between pages, than to sue angular.
Is it that there is something that is missing? Is there a way you can can get your server to resolve to the correct angular page?
You can use usePushState: false then only the (client) local part of the URL is changed.
see https://github.com/angular/angular.dart.tutorial/blob/master/Chapter_06/web/main.dart#L27
This part after the hash is never sent to the server.
This might cause some additional work for SEO.
http://example.com/index.html#someRoutePath/anotherRoutePath
or you can configure your server in a way that each request is handled independent of the path in the request and use the route package server side too.
see also https://stackoverflow.com/a/17909743/217408
You can configure your backend server to point all routes to the same file (using some kind of wildcard route which all decent servers should support). So app/some/page and app/another/page would both be served app.html. Then on your app startup you could have Angular parse the URL of the page, and manually route to that page.
I have used this approach with a Polymer app (with the Route library) and it works great. It should work similarly for Angular.