1

I'm building an MVC4 application that is starting to take shape and I want to deploy it privately for staging and preview purposes. I would like only a select few people to be able to access the full application. Most of the application is public, but there is a private area as well that requires the user to login.

I'm looking for the most unintrusive way to privately deploy this application to staging/preview. By unintrusive I mean that I don't want to toggle more than a few lines of code, preferably just a flag in the web.config, to deploy it normally vs privately.

I also want this authorization to overlap the site's existing authorization functionality. In other words, when the person goes to the preview URL I give them, they are brought to a landing page where they must log in using the username/password I also gave them. Once they login, they should be brought to what will be the actual landing page if the application was in production. However, they should NOT be logged in to the application itself (this is what I mean by overlap). This way, they can use the application as normal (registering, then logging in a second time to get to the application's private areas.)

I'd like to have something along the lines of this in my web.config:

<StagingAccess deployPrivately ="true">
    <StagingUsers>
        <StagingUser>
            <UserName>JoeShmoe</UserName>
            <Password>Staging123</Password>
        </StagingUser>
    </StagingUsers>    
</StagingAccess>

Such that I can simply toggle deployPrivately, add a StagingUser node for a select user, then deploy to my host using Web Deploy.

Some steps would be perfect as I've never actually deployed an MVC app before, let alone like this. But I really need to start being able to show the application to people without exposing any of my code and without a remote desktop to my machine, which makes the app seems laggy.

parliament
  • 21,544
  • 38
  • 148
  • 238
  • 1
    where do you intend to deploy production? will it be a cloud? – Dave Alperovich Jan 30 '13 at 16:25
  • No it won't be to a cloud, Thanks. – parliament Jan 30 '13 at 16:36
  • 1
    consider using azure as your staging environment. You can lock it off and getting a limited usage account shouldnt cost more than $80/month – Dave Alperovich Jan 30 '13 at 16:44
  • Do I have to write additional code to make my application a "cloud application" or is this simply a matter of choosing Azure as my hosting provider? Can you provide a link, guide, or full answer to help me understand the steps needed to take? Thanks – parliament Jan 30 '13 at 16:56
  • Ok I found what I needed. For converting an existing MVC app to Azure: http://blogs.msdn.com/b/bursteg/archive/2009/05/23/asp-net-mvc-on-windows-azure-asp-net-mvc-web-role.aspx And for deploying that solution to the cloud: http://dotnetslackers.com/articles/aspnet/Developing-ASP-NET-MVC-4-Application-and-Deploying-to-Windows-Azure-Cloud.aspx Thanks for your help. – parliament Jan 30 '13 at 20:46
  • sorry didnt notice the posts. good luck. – Dave Alperovich Jan 30 '13 at 20:57

1 Answers1

1

How about a combination of Authorization Rules: http://weblogs.asp.net/gurusarkar/archive/2008/09/29/setting-authorization-rules-for-a-particular-page-or-folder-in-web-config.aspx and Web.Config Transformations? http://msdn.microsoft.com/en-us/library/dd465326.aspx

Then you would Publish the application using VS with a specific configuration chosen - I believe this could help you accomplish your goals.

da7rutrak
  • 548
  • 3
  • 13
  • I believe the Authorization Rules link you posted does not apply to MVC architecture that uses virtual directories not phsyical folders/files locations. The resources I need to protect are my controllers. +1 for Web.Config transformations, selecting a specific web.config transformation will make it more convenient however doesnt address the root problem. Thanks – parliament Jan 30 '13 at 16:54
  • 1
    You're correct that they are essentially "virtual" resources - however Authorization Rules do work (though not generally accepted as "good practice" but should work for your limited use case. I'm confident there is another solution, however I don't believe it will be as simple as doing some xyz.config changes. – da7rutrak Jan 30 '13 at 17:00