0

I feel fairly confident that I have this wrong (or backwards). I'm looking to determine what environment a request is coming from, so that I can determine what database to access (based on the referrer url).

The end point is a "self-hosted" API on one of our servers, and I'd like to send requests from both development and production to the service, and handle the requests accordingly. I'd like to avoid adding additional frameworks, as well as avoiding having to handle the environment in each action call.

Here's what I have going so far.

public ServiceProvider svc;
public ECTaskService lab;

public BaseAPIController()
{
    //I WAS HOPING FOR THE ENVIRONMENT REFERENCE HERE.... 
    svc = new ServiceProvider();
    lab = new ECTaskService();
}

My hope was that I could access the filter context below from the constructor above to pass the environment down to the service provider, which would handle the all of the facets of the database / dev environment as needed.

public class LabelServerFilter : ActionFilterAttribute {
    public override void OnActionExecuting(HttpActionContext actionContext)
    {
        Environment(actionContext);
        base.OnActionExecuting(actionContext);
    }

    public override Task OnActionExecutingAsync(HttpActionContext actionContext, CancellationToken cancellationToken)
    {
        Environment(actionContext);
        return base.OnActionExecutingAsync(actionContext, cancellationToken);
    }

    public string Environment(HttpActionContext actionContext)
    {
        try
        {
            var env = "PRODUCTION";
            Uri referrer = actionContext.Request.Headers.Referrer;
            if (referrer != null)
            {
                string clientDomain = referrer.GetLeftPart(UriPartial.Authority);
                if (clientDomain.IndexOf("myinternalurldev") > -1)
                {
                    env = "DEVELOPMENT";
                }
            }
            //Console.Write("[" + env + "]");
            return env;
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message, ex);
        }
        return "PRODUCTION";
    }
}

Thanks in advance!

sohnryang
  • 725
  • 2
  • 13
  • 27
Middle Class Lowlife
  • 33
  • 6
  • 2
    IMO this is a dangerous path to walk down. Instead of letting on instance of your API have access to both the dev and production databases, you should instead deploy an API for each environment, where the API only connects to a single kind of database. Using your current approach, a developer mistake could easily allow code that accesses your production database by accident. With a one-to-one mapping between an API instance and an environment, this type of accident is much less likely to occur. – J.N. Sep 12 '17 at 14:04
  • I totally agree with your reasoning. There are a lot of moving parts and separate deployments to manage for this solution, as the "self-hosted" console / windows service part is basically a web API to a whole label printing solution, and the UI is it's own site that talks to that one end point using javascript, MVC / Web API 2. I can manage the URL separately for the web API / MVC part (app/web.config), but I haven't quite figured out how to get javascript to swap URLs during deployment. I was hoping to avoid lots of manual changes, and this seemed like one solution to that problem. – Middle Class Lowlife Sep 12 '17 at 17:07

0 Answers0