This is odd, but we have written an asp.Net web application (all's well there) but now we are importing a large amount of data, and in this case, users with existing usernames and passwords. The import is being done with a desktop application.
I need to take each user from the old system, and create a corresponding user in the new system, and to do that I need to add each of them to asp.net membership services.
I'm at a complete loss as to how I can do this from the desktop. I mean, I've got references to System.Web.Security, but what would I put in my App.config?
I'm sorry, I don't think I fully understand Membership Services enough to phrase this question all that well. But can someone point me in the right direction please?
You should check following SO threads for more information :
Can you use the asp.net membership provider in a windows application?
Is using the ASP.NET Membership providers in winforms application a bad idea?
Related
I am trying to re-learn ASP.NET and building some application, however tutorial seems to be running shorts.
I understand ASP.NET comes now with built in membership which allows users to created and edit, login to users. However, is there a way for me to create a User Controller. From what I have read, its a big no, because it may conflict with the AccountController. Maybe this is wrong, but I would like to be sure first.
Also I understand that I can use the word [Authorize] in a controller ( action, or class ) to limit access to users. However if I provide [Authorize(Roles="Admin")] How can I define the roles to a users? Is there a field that already exists in the membership providing this or do i need to supply a second nuget packages. If its a field from the user, how does it know Roles is the value in the User tables?
You're confusing multiple things. Asp.net is the basic web technology, and there are three technologies that sit on top of that. Webforms, Web Pages, and MVC.
Membership has been a part of asp.net since Version 2, released in 2005. This is nothing new. There has been much written about it over the years.
If you're using MVC, which it seems you are, and you're using MVC4, then the default internet template uses SimpleMembership, which is not compatible with the built-in membership editor in Visual Studio (known as the Web Site Administration Tool or WSaT). This is only compatible with the old SqlMembership database tables, and SimpleMembership does not use those tables.
You can use SqlMembership with MVC4, but you have to configure it to use SqlMembership. Or, you can just not use WSaT and configure your user yourself.
Oh, and don't listen to people that tell you to create custom membership providers. This is the worst advice possible unless you know what you are doing, because it's non-trivial to create secure password hashing techniques. And 99% of people that try (even people that should know better) get it wrong unless they pay very close attention.
Use a provider from a reputable source unless you have VERY good reason not to. And then, check, double check, triple check your hashing code and then have an expert check it.
For Authentication and Authorization in asp.net, have a look at Forms Authentication and Membership Provider (and Role Provider for roles)
A quick search gives this article: Here
have a look at other searches for "Custom Membership Provider"
This also looks interesting: How do I create a custom membership provider for ASP.NET MVC 2?
I'd like to make an OOB Silverlight app based on the Silverlight Business Application template in Visual Studio. The template uses the default ASP.Net membership provider. I understand how to use that to add users and roles, etc. I've found plenty of tutorials on that. What I'd like to be able to do, is configure the Silverlight template so that it uses an existing ASP.Net membership base. We'd like this app to have a companion website (ASP.Net based).
To clarify: We've been able to setup an ASP.Net website and have created a SQL database with the required tables (aspnet_Users, aspnet_Membership, etc.). I'd like to configure a Silverlight app to access the same users and roles that are in those tables.
Can anyone help me out in terms of what I'd need to put in the Web.config? Do I just need a connection string? I'm new to ASP.Net authentication, but I'd rather use what ASP.Net gives me out of the box than have to write my own authentication service. I feel like this should be really easy, and is just a matter of pointing the Silverlight app in the right direction.
I'd like to use Silverlight 5 and .Net 4.5 if I can but I don't mind using an older version of either if it makes things easier.
You can just point the connection string to the existing database.
From this answer:
You can point your connection string for authentication to a database that all application can access.
So if you have the default database that .NET creates, you can point your other application to that as well for authentication.
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.
Currently, we have many web applications (external & internal) developed using Classic ASP through .NET 2.0 technologies. Each of those web applications have their own login screen authenticating against their own custom database or using Windows authentication. Users have access to one or more of these applications, meaning they have to log out and log back into applications that they would like to access. All applications share some part of the back-end data sources. Also, the business logic is embedded in the UI in addition to being duplicated across applications because there is no code/business logic sharing. Screenshot #1 gives a brief idea of the existing architecture.
Screenshot #2 shows the suggested architecture, which I hope will help in faster development, code/business re-usability and may be simpler maintenance. Users will access either external or internal url. In external, users will provide credentials and will be authenticated against custom database. In internal site, users will be automatically logged in using Windows authentication. After creating some samples, I have begun to like ASP.NET MVC 3. It keeps business logic separate from UI and I also like the unit testing capabilities.
Here are my questions:
Based on what I have found on the web so far, multiple authentications are not feasible within a single website. My understanding is that I have to host one website for each type of authentication (Forms and Windows). How do I redirect users to common landing page after they are authenticated so they can see the modules (links/menus) that they are authorized to access? Should I have to publish the same code set (dlls and content) to both the websites?
Has anyone faced a similar architecture problem? If yes, could you please share the challenges that you faced and how you tackled them? What are the industry standards in designing applications of this sort?
Does the suggested architecture make any sense or is it a really bad design? Are there any drawbacks in doing this in ASP.NET MVC 3?
I would really appreciate your inputs.
Thanks in advance.
I would set up a seperate web site which only handles the windows authentication. I would then rely on something like OpenID and/or OAuth to ask for credentials/token to make sure to user has proper access.
The user that want to sign in using windows credentials go through that process because you are right in that a IIS server running windows authentication is hard to mix with other stuff.
You can set up some kind of claim based network of thrust in which you applications get thier credentials from trusted sources and through that process you can negotiate and control access privileges cross many web sites. As long as your not doing custom hosting or white label branding you can have everything in one place (or even if you did you could design it so that you have a central solution of handing out authentication tokens).
Keep in mind the difference between Authentication and Authorization. You presumably want a single authentication mechanism (or maybe two, one for internal and one for external users). There is a similar post here that lays out some pretty good guidelines: How to allow multiple authentication methods in ASP.NET?
On one project we built a common controller class used in every page of the site. It handled authentication and access control. When a user tried to access any page it checked to see if they had a session identification cookie. If they did not they were required to authenticate(login). A challenge was doing a good implementation of the security. Current browsers have many flaws that make this difficult.
I'm not very experienced at using ASP.NET, but I've used built in membership providers for simple WebForms application, and I found them PITA when trying to extend the way they work (add/remove few fields and redo controls accordingly).
Now I'm preparing for MVC (ASP.NET MVC or Monorail based) project, and I'm thinking - is there a better way to handle users? Have them log in/log out, keep certain parts of the site available to certain users (like logged in users, or something similar to "share this with friends" feature of many social networking sites, where you can designate users that have access to certain things.
How best to acheave this in the way that will scale well?
I guess, I wasn't clear on that. To rephrase my question:
Would you use standard ASP.NET membership provider for a web-facing app, or something else (what)?
The Membership Provider in ASP.NET is very handy and extensible. It's simple to use the "off the shelf" features like Active Directory, SQL Server, and OpenLDAP. The main advantage is the ability to not reinvent the wheel. If your needs are more nuanced than that you can build your own provider by extending overriding the methods that the ASP.NET controls use.
I am building my own Custom Membership Provider for an e-commerce website. Below are some resources for more information on Membership Providers. I asked myself the same questions when I start that project.
These resources were useful to me for my decision:
Writing a Custom Membership Provider - DevX
How do I create a Customer Membership Provider - ASP.NET, Microsoft
Implementing a Membership Provider - MSDN
Examining ASP.NET 2.0's Membership, Roles, and Profile - 4GuysFromRolla
Create Custom Membership Provider for ASP.NET Website Security - David Hayden
Setting up a Custom Membership Provider - Channel 9
I personally don't think there is a need to use something other than the builtin stuff unless you either want to abuse yourself or your needs are impossible to satisfy by the builtin functionality.
Have you considered using ActiveDirectory for this? Or, perhaps, OpenLDAP? You can manage each user's groups, permissions, 'authority', and so on.
keep certain parts of the site available to certain users (like logged
in users, or something similar to "share this with friends" feature of
many social networking sites
I guess you must custom code your thing.
I also do not like the asp.net Membership and custom code my membership needs...
A nice membership provider is a really missing thing in asp.net side...
It depends.
If it's an internal application, Active Directory or OpenLDAP might be the way to go.
If it's a public application, I suggest to look at aspnet_regsql. You will be able to setup a database with Authentication in no time.