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.
Related
I've got a .Net application running inside a Citrix environment and I need a way to identify the user logged on to the citrix client using forms authentication. Is this possible? I've seen some post regarding a Citrix SDK but not sure if solves my issue...
I'll preface my statements by saying I know next to nothing about ASP.NET and Forms Authentication (which from brief Googling appears to be a way to implement custom auth in ASP.NET).
Any app running a Citrix session will have access to the identity of the user. It will be running as the users' identity already and so you can query the current security principal to see who the current user is. You don't need to use any special Citrix SDKs. It's a common assumption by devs that they need to do special stuff as soon as their app is running under Citrix. However in most cases you can develop your app as-if it were running on the users' local desktop, and just deploy it on a Citrix server instead.
So for a regular .NET desktop app you can use properties like: Environment.UserDomainName and Environment.UserName to get details about the current user. Other stuff of interest is System.Security.Principal.WindowsIdentity, you can use the GetCurrent() static method to get the current users' identity.
Now as I said initially this maybe different for your case as it sounds like forms authentication is some kind of custom auth mechanism, so what I've said may not apply. But hopefully I've given you some useful pointers.
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.
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.
We have many custom built web applications (both external & internal) written in Classic ASP and ASP.NET 2.0 technologies. Internal users can upload files to these websites, which can then be viewed by External Users. In some cases, external users can upload documents as well.
Screenshot #1 gives a brief idea about the existing architecture.
Internal users upload documents to custom web applications. These documents are stored in a folder structure defined under the web application.
Meta data and user permissions like who can access the documents are stored in SQL Server database.
The same set of documents that are being uploaded to custom web applications also exist in SharePoint. However, the custom web applications are unaware of SharePoint. So, users have to download them from SharePoint and then Upload it to the custom web applications. We are currently using SharePoint 2010.
External users can also upload documents to the custom web applications. The meta data and user permissions of the document are saved into database based on the user who is uploading the document.
Screenshot #1:
Screenshot #2 shows the architecture that I am trying to achieve. I have done very little SharePoint development. Mostly, I have used the SharePoint web services to retrieve some list content but nothing more than that. Our future Custom Web Applications might be written using ASP.NET MVC. Please find the questions after the screenshot.
Screenshot #2:
Here are my questions:
I would like to have internal users continue to upload and maintain their documents in SharePoint. User security model is already defined in the SQL Server database. This security permissions should be available in the SharePoint document properties so users can choose who can view the document from the custom web applications. How can I achieve this? Should I have to copy the SQL Server user permissions info to SharePoint?
I believe that SharePoint Web Services or Business Connectivity Services (BCS) can help in retrieving the document and its related info from SharePoint. Which one of these would better suit this scenario?
Custom web app should display only the committed versions of the documents. If a user has checked out a document in SharePoint to make any changes, that checked out version of the document should not be visible to External users. Is that possible?
Has anyone tried this approach? Are there any pitfalls with this model? Are there any performance concerns with this design?
Will this design be of any hindrance if I rewrite our existing applications using ASP.NET MVC?
Is it possible to make use of SharePoint search feature within the custom web application (ASP.NET Web Forms / ASP.NET MVC)? In other words, can I send search criteria from custom web app and have SharePoint do the search and return the results back to custom web app?
I really appreciate your inputs.
Thanks in advance.
Question 1
Hard to say without having more details. So I'm going to assume that you currently use Active Directory for your authentication store. So this means that your SQL Server defines a list of roles and then has assigned memberships to these roles. I'm going to assume that your assigned membership is to AD users or groups. If this is true then I think your on the right path to push your permissions from SQL Server into SharePoint. SharePoint's API will accommodate what you need to do, however SharePoint has no built into mechanism for syncing your permission changes so that means you end up writing a whole lot of plumbing code. I would recommend that you research products that can handle the synchronization for you. Microsoft MIIS (I believe it is called Forefront Identity Management now) offer a set of architecture patterns that you should investigate.
Question 2
SharePoint Web Services or the SharePoint Client Access Services should work fine. I would highly recommend that use a proxy pattern to isolate your application from SharePoint calls (so you can isolate your application from SharePoint upgrades and potential content management server changes).
Question 3
Yes, that is possible. If you are using the publishing features of SharePoint Server (NOT SharePoint Foundation) you will have an easy way of identifying the current published version. Otherwise the service account you query with should be setup so it can only read published versions then SharePoint will automatically trim your query.
Question 4
I have not personally tried this design, but I really like the concept of creating a content management domain and then putting an abstract service layer on top of it. Will you have scale problems, depends on how you configure SharePoint and your applications. You can do it right or wrong. An depth answer between the two cannot be covered here. My one piece of advice is to make sure you plan for caching in your service interfaces (cache, cache, cache).
Question 5
Not if you implement it as a Service Layer. You would just use a repository pattern to call the service and return back entities for your model.
Question 6
Yes, Search is exposed via an API so it can be wrapped in a service layer too.
Good luck and feel free to contact me directly for more in depth discussion.
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.