Working with dynamic sub-domains with struts2 - struts2

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.

Related

Rails uses different default url options in views vs controllers?

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?

Running jira behind an apache: what is the proxyName configuration for?

from the documentation it seems that I have to edit the server.xml file to set: proxyName, proxyPort, scheme.
Not only doesn't it explain what those settings are for, but I also can't find any motivation behind it. Doesn't the usual apache reverse proxy configuration just suffices?
The specific parameters you refer to in server.xml file are Tomcat <Connector> attributes.
The practical impact is that Jira or third-party apps will sometimes use these attributes to construct fully-qualified URLs to refer back to Jira, and which also sometimes get passed on to the client browser. The attributes configured here should match the base URL configured in the main Jira system configuration.
For example, Jira may send redirects to the user's browser if it detects that you are accessing Jira from something other than the canonical URL as configured here. It will also occasionally construct fully-qualified URLs (rather than relative URLs) in certain parts of the application.
You also generally need to have correct values set for these attributes (as well as the base URL) if you want Application Links and the UPM (app manager) to work correctly.
For local testing or development purposes, it is generally acceptable to remove these attributes entirely (it will stop auto-redirection from happening), so long as you're always accessing Jira from the base URL, and knowing that you may have issues with AppLinks or the UPM. Removing them is certainly better than having an incorrectly-configured proxyName, which would otherwise generate redirects to the wrong place.

How can I use Domain-based routing?

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

Modifying URLs on a Rest Server in Delphi

I've written a REST server in Delphi XE (using the wizard) and I want to change the URLs a bit so that instead of having
http://192.168.1.84:8080/datasnap/rest/TServerMethods1/GetListings
I get something that looks more like http://192.168.1.84:8080/GetListings
Is there a nice easy of doing this?
The naming convention is (Delphi XE3):
http://my.site.com/datasnap/rest/URIClassName/URIMethodName[/inputParameter]
You can easily change the "datasnap" and "rest" part of the URL in the TDSHTTPWebDispatcher component properties. You can change the Class Name and Method Name of the URL by simply changing the name of your class and method. However, you still have to have 4 components to the URL, so for example it could be:
http://my.site.com/api/v1/People/Listing
See here:
http://docwiki.embarcadero.com/RADStudio/XE3/en/REST#Customizing_the_URL_for_REST_requests
You could put IIS or Apache in between to accomplish this, and indeed rewrite the URL to point to your service the way you like.
That provides some more advantages anyway (security and scalability mostly). For example, you can create a fail-safe setup with double servers, or you can create multiple machines with your service, and have your web server do the load balancing for example.
You'll get extra logging capabilities, and if you easily want to serve other web content it's easy to have a full fledged web server anyway.
URL rewriting is usually done in the web server configuration, in Apache using entries in the .htaccess file

Account based lookup in ASP.NET

I'm looking at using ASP.NET for a new SaaS service, but for the love of me I can't seem to figure out how to do account lookups based on subdomains like most SaaS applications (e.g. 37Signals) do.
For example, if I offer yourname.mysite.com, then how would I use ASP.NET (MVC specifically) to extract the subdomain so I can load the right template (displaying your company's name and the like)? Can it be done with regular routing?
This seems to be a common thing in SaaS so there has to be an easy way to do it in ASP.NET; I know there are plugins that do it for other frameworks like Ruby on Rails.
This works for me:
//--------------------------------------------------------------------------------------------------------------------------
public string GetSubDomain()
{
string SubDomain = "";
if (Request.Url.HostNameType == UriHostNameType.Dns)
SubDomain = Regex.Replace(Request.Url.Host, "((.*)(\\..*){2})|(.*)", "$2");
if (SubDomain.Length == 0)
SubDomain = "www";
return SubDomain;
}
I'm assuming that you would like to handle multiple accounts within the same web application rather than building separate sites using the tools in IIS. In our work, we started out creating a new web site for each subdomain but have found that this approach doesn't scale well - especially when you release an update and then have to modify dozens of sites! Thus, I do recommend this approach rather than the server-oriented techniques suggested above based on several years worth of experience doing exactly what you propose.
The code above just makes sure that this is a fully formed URL (rather, say, than an IP address) and returns the subdomain. It has worked well for us in a fairly high-volume environment.
You should be able to pick this up from the ServerVariables collection, but first you need to configure IIS and DNS to work correctly. So you know 37Signals probably use Apache or another open source, unix web server. On Apache this is referred to as VirtualHosting.
To do this with IIS you would need to create a new DNS entry (create a CNAME yourname.mysite.com to application.mysite.com) for each domain that points to your application in IIS (application.mysite.com).
You then create a host header entry in the IIS application (application.mysite.com) that will accept the header yourname.mysite.com. Users will actually hit application.mysite,com but the address is the custom subdomain. You then access the ServerVariables collection to get the value to decide on how to customize the site.
Note: there are several alternative implementations you could follow depending on requirements.
Handle the host header processing at a hardware load balancer (more likely 37Signals do this, than rely on the web server), and create a custom HTTP header to pass to the web application.
Create a new web application and host header for each individual application. This is probably an inefficient implementation for a large number of users, but could offer better isolation and security for some people.
You need to configure your DNS to support wildcard subdomains. It can be done by adding an A record pointing to your IP address, like this:
* A 1.2.3.4
Once its done, whatever you type before your domain will be sent to your root domain, where you can get by splitting the HTTP_HOST server variable, like the user buggs said above:
string user = HttpContext.Request.ServerVariables["HTTP_HOST"].Split(".")
//use the user variable to query the database for specific data
PS. If you are using a shared hosting you're probably going to have to by a Unique IP addon from them, since it's mandatory for the wildcard domains to work. If you're using a dedicated hosting you already have your own IP.
The way I have done it is with HttpContext.Request.ServerVariables["HTTP_HOST"].Split(".").
Let me know if you need more help.

Resources