I need to quickly wrap some security around an existing ASP.Net 2.0 web app. After thinking about it for a moment, I remembered that Microsoft created that Membership and Roles paradigm a couple of years back, and that Visual Studio could essentially create everything for you.
Thus I forged forward using the built in ASP.Net Web Site Administration Tool and created a simple little security framework around the application. After setting all of the options, Visual Studio created a nice little SQL Express DB called ASPNETDB.MDF right under the newly created App_Data directory of my website. This works great until you deploy it.
After trying to push this app to my DEV server I realized that it's not going to work unless you have SQL Express installed on the hosting machine. Worse yet, I figured that there's essentially no way this would work under a load balanced environment considering the DB itself will only be isolated to one of the N nodes.
Rather than work to script out the DB and shove it into my existing SQL box...I figured I'd ask the StackOverflow if there is a better solution for simple yet secure ASP.Net websites.
I'd love to maintain the existing model yet have the database become a local, or flat-file DB baked right into the application. For the time being I'm even fine with deploying the flat file with each user or role change to counteract the load balanced sites in PROD.
Is there not a way to create some sort of similar setup with a flat file? I thought that was the point of the App_Data folder?
You could use a custom Role & Membership provider that supports a flat file, like XML. Here is a link to a XML Membership provider, I've seen similar implementations for Roles.
XML Membership Provider
it's not going to work unless you have SQL Express installed on the hosting machine.
Not necessarily. If you still want to use default membership/role providers you can either have the DB server on the hosting machine or have one instance of the DB as a separate server (just change the connection string for providers).
Worse yet, I figured that there's essentially no way this would work under a load balanced environment considering the DB itself will only be isolated to one of the N nodes.
This statement is not really correct in this particular situation.
With load-balancing you will not have isolated database, but rather a separate database server.
I'd love to maintain the existing
model yet have the database become a local, or flat-file DB baked right
into the application. For the time
being I'm even fine with deploying the
flat file with each user or role
change to counteract the load balanced
sites in PROD
If you say that application with proper SQL DB will not scale, I do not understand how flat-file storage can.
You still can keep local SQL Server database and it will work as long as you take responsibility of maintaining the database consistency across different nodes.
In your situation, I would personally use default membership/roles provider as you do now.
But when deploying, just change the connection string to the proper database server.
You will need a database for other stuff anyway, so why not use the same database for all data withing the application (including membership/roles).
Regards.
I found an excellent solution to this here...http://aspnetxmlproviders.codeplex.com/. Using the dynamic XML you can hack out a simple provider based security model in no time flat.
Related
I know such questions have already been asked many times, but I am here with my scenario. Kindly do not delete or vote to close.
I have an asp.net application with L2S and SQL 2008 R2 as backend
Using N-Layered architectured
Mostly normal crud operations to be performed.
Use of Sessions and View States
Manual Login / Logout(User and Roles management) , no .net Membership has been used.
No services used yet, might be a later part.
Third Party controls like Telerik or Infragistics also are in use.
I want to know:
Do i need to change entire application to Azure Web Application?
If not, is it possible to deploy it directly over the cloud , on MS or any other, as we normally do in IIS?
If not, Is there any third party migration tool available to make my plain old web application cloud-compatible, without affecting existing codes ?
I want cost effective and easy to go steps?
Thanks in advance
Yes that should be possible. You almost certainly do NOT have to change your whole application.
Linq2SQL is fine, I run an Azure site with L2S without any problems
You'll have to deploy your DB to a SQL Azure database. There are some restrictions, like all of your tables must have a primary key. A bigger list is here: http://msdn.microsoft.com/en-us/library/windowsazure/ee336245.aspx.
Also, when generating your SQL scripts, be sure to select SQL Azure as the database engine type: http://mooneyblog.mmdbsolutions.com/index.php/2011/09/22/generating-azure-friendly-sql-scripts/
What do your N-layers look like? If they are DLLs, it's fine. If they are web services, you'll need to create web roles for them. If they are windows services, you'll need to port them to a worker role.
Most crud and view state and manual authentication code is fine
For session, it depends on what you are doing (memory vs database). But you'll have the same challenges that you would have if you deployed to any web farm
For Telerik, I'm sure they have to have some support for Azure, and I don't think they would be doing anything crazy that would not work Azure. You should check out their website to verify compatibility.
Also, make sure you are not writing to the hard drive anywhere and expecting it to be there later, because instances can be started and stopped and reimaged at any point. If you're doing that, you'll need to change it to use something else like blob storage.
I have an ongoing series of blog posts that walk through some of the steps, which should help: http://mooneyblog.mmdbsolutions.com/index.php/category/azure/
Good luck!
I don't see any hassles to deploy your web application into the cloud.
You don't need to convert your entire application to anything else.
After all you can just try to deploy it now with the trial subscription in Windows Azure which is free for three months.
There is a fairly big stuff of new technology in Windows Azure such as service bus, azure storage, access control service, etc. However it's not necessary to use all them right now. It's prety easy just to move the existing app into the cloud.
You can deploy it to Azure web site.
That should be easier if you don't want to use SQL Azure and cloud storage.
This is my first foray into building a secure web application. It will be on the internet, and it comprises an IIS server (hosted by ISP) and SQL 2008 db (Also hosted by ISP.
As a quick and dirty test I am just using the template in Visual Studio. I have configured authentication by just using the wizard on the ASP.NET configuration tool. However, this creates a database that is hidden within the web app.
I would prefer to keep the user credentials on the SQL server, as it seems like best practice to allow for scalability. However, how do I do this? I have limited access to the database - I can create tables, but don't think I'll be able to run any tools on the server to create the right schema. Can anyone point me in the right direction? Done some googling, but keep seeing ASP.NET 1.1 articles, which makes me think I may be missing something, and there is a better way of doing this in ASP.NET 4.0.
Create a User table in SQL Server that stores user login and password. You can hash the password so that it's not visible even to admins themselves including yourself. Then using LINQ to pull during form authentication to check login name/password against the User table.
You can also use embedded SQL or stored procedure in place of LINQ. However, embdedded SQL is highly unsafe so that leaves stored procedure and Linq. I would prefer using Linq if you are familiar with it. Or using stored procedure which is always the safest.
You don't "have to" use the entire ASP.Net Membership framework to use Forms Authentication. It does a lot of the plumbing for you (security, etc), so if you can, it's probably best you use it - more so, if you're getting started.
You can use Forms Authentication with any auth scheme you want (pre-existing or something you create yourself). Here's an overly simplistic sample where you can see that you can even hard-code the auth scheme (not that you should, but it shows you the possibilities).
Lastly, if you can't run the command line ASP.Net tool aspnet_regsql.exe, the sql scripts to create the schema are in: C:\Windows\Microsoft.NET\Framework\[Framework version].
So for .Net 4, it would be: C:\Windows\Microsoft.NET\Framework\v4.0.30319
Both install and "uninstall" sql scripts are there - e.g.
InstallMembership.sql
UninstallMembership.sql
... and so on....
Can I convert a non-MVC asp.net application to be Azure compatible ? Or If i want to create an Azure web application, should it be MVC one ?
The other answers answered your question about converting your app to MVC for deployment to Azure (you don't need to).
If you're creating a new web application and go with ASP.NET MVC (which I'd recommend), just remember if you go with MVC3, you may have to make some of the MVC3 DLL's CopyLocal for your deployment, as it won't be part of your web role instance. At least that's how I still understand it. The 1.4 SDK of the Azure SDK doesn't have a MVC3 Web Role template yet.
See this post on steps to get your MVC3 app Azure-ready.
Hope this helps.
You may take a look at the following blog post for migrating an existing ASP.NET application to Azure. It should not necessarily be an ASP.NET MVC application. Any ASP.NET application will work.
azure has 2 roles
1. a webrole
2. worker role
web role is nothing but an asp.net app. so no need to convert it into an MVC app just any asp.net thing will do fine
Yes, you can. But you need to be aware of certain limitations too, none of which were mentioned in the answers already given:
Your application should be stateless, unless you are running a single instance (for most apps 99,9% reliability is OK, but there are some where you want 99,95%, so you need at least two instances + it gives you additional benefits of a load balancer, etc.). The reason for this is that if you have more than one instance, the load balancer will deliver the request to a different instance. You can use AppFabric Cache to solve this.
You don't have a file system - this is not entirely true, but in reality you should never rely on having local files. All you image uploads (e.g. user profile pictures) should be uploaded to a blob storage and linked to there. How you do this is another matter, and one that can be approached differently depending on the architecture of your existing application. You can get away with files, by using Azure Drive, but it's slow as hell.
No Event Log / RDP - this is also only partially true, but you should rely on other ways of getting diagnostics information from your role. While you can RDP to your role instance, there are better ways (e.g. Azure Diagnostics storage).
Database should be chosen carefully. Sure, you have SQL Azure available, but it's expensive (1 GB = 10 USD/ month). If you can get away with stuff like Table Storage, you may save on some costs. Again, this depends a lot on the architecture.
As for the second part of your answer. MVC as a pattern is nice. It saves you a lot of time, it's much more adapt for the Web as WebForms ever will be. The event based system was designed for Desktop applications, and it was forced onto the web. However, going to Azure does not imply a requirement to go to MVC. What I suggest you do however, is treat it as a nice jump-start opportunity to look into MVC and see how it could help you write your apps better & faster.
As with any other case involving architecture of apps, it depends. If you used common patterns (e.g. IOC, Repository), you will have a really easy time moving any app to Azure.
I am a newbie to ASP.NET - so what is the pattern to use Isolated Storage vs. Session state for web applications?
I have a use case where when a user logs into the application, I need to create his profile information which will persist throughout his session.
Does it make sense to store this in session or should I use Isolated Storage (assuming the client is on a Windows machine)
Thanks!
ASP.NET has a profile provider that's built to store a user's profile.
You could use your own provider that's session backed if you really only want the profile to last for the duration of the session.
Your last comment makes me think you want to use isolated storage on the client machine; I don't think you can access isolated storage on the client from a browser w/o an ActiveX control or something like that.
Isolated storage is not used in asp.net applications for storing profile info - this is generally used in .net apps running on the client side.
To get profiles up and running, see any of the many posting on it.. a good one by Dino Esposito
http://msdn.microsoft.com/en-us/magazine/cc163724.aspx
and
http://msdn.microsoft.com/en-us/library/2y3fs9xs.aspx
The configuration is there by default but in visual studio you will want to bring up the admin site for your web app to make sure everything is setup.
Using web applications or web sites also gives you different access to profile properties. One will strongly type them, one will not.
All,
We have a ASP.NET application working on our staging server/DB. The application works fine. We are using ASP.NET Memebership/Roles, etc.
Now it's time to deploy the application to production. As part of the deployment, we want to copy/migrate the ASP.NET Memebership database to the production servers.
Can we simply do this via SQL Server's export/import functions? Will the applications IDs and role IDs that move to the production DB make sense when the ASP.NET application is deployed on the new boxes?
Thanks,
John
Yes, this is fine. The IDs are all for internal storage, so no issue. Just make sure the config matches and you are good
You might want to look at RedGate's SQL Data Compare as a more robust (configurable) solution to moving data between databases. I think you'd probably be ok doing a simple export/import, but you'd need to be careful of autogenerate columns.
Use the Database Publishing Wizard from within Visual Studio?
http://social.msdn.microsoft.com/Forums/is/vssetup/thread/42bbad47-5b6e-4e99-8d27-07bcbd123064
Everything should work fine on the production server.