I'm designing a web application in MVC/WebApi where the user will have to provide his secret passphase on eachtime he does some action in my app.
To make his life easier, I would like to store this passphase somewhere. I was thinking about a user session or a cookie. How would I do that?
There is a lot of information about this subject around here.
in a nutshell, if authentication is what you are after, Microsoft has several frameworks/solutions for this. search for forms authentication(the easiest to apply) , identity, membership, OAuth 2.0, java web token.
The cookies and session are working same as asp.net and MVC.
session is stored in the server,cookies are stored in the client browser
session can degrade the performance of server by storing the data
There is more information to know about session and cookie just watch following videos
https://www.youtube.com/watch?v=PmziMRE9NQ8][1]
watch the part 60,61,62 these are free videos and you can get more knowledge After watching these videos
Related
I'm using a login form to authenticate users.
FormsAuthentication is right out as it stores sensitive user/role membership in either client-side in a cookie or within the URL. Within the URL is a huge security risk, so I won't even get into that. With the
FormsAuthentication cookie, this creates problems with a) security where the client is in the position of dictating it's own roles; and b) way too much data stored in cookies. Since I'm gaining nothing through security and loosing out big time on the size of user data storage, I'd rather just work with Sessions.
I'd like to reuse something like FormsAuthentication for all its basic login form-handling features. But i would rather have it store user data server-side in perhaps Session rather than client-side all stuffed into a single cookie. I'd rather just authenticate against a Session token of some sort.
I have no database and local disk storage of user data is forbidden. I rely on a 3rd party authentication service provider, and a requirement is that I must reduce chatter with this service. Thus, sessions for temporary storage of user info. Sucks, but that's not necessarily the problem I'm asking about. Also, a requirement is that I must set/use HttpContext.user and likely Thread.CurrentPrincipal for use later on in such things as AuthorizeAttribute, for displaying user info in views, etc.
So FormsAuthentication stores all user data client-side in a cookie. Whereas Session stores all data server-side and just relies on a simple client-side token cookie. However, Session is not available anywhere during the asp.net startup and authentication steps. Is there an equivalent forms "membership" provider that stores all data in Session server-side instead of client-side?
If there is no Session equivalent...
Where do I set HttpContext.user and Thread.CurrentPrincipal to make both values available throughout the rest of both MVC apps without interfering or messing up other MVC components?
Hinging on #1, is Session available at that entry point? If not, how do I make it available so I can create the Principle/Identity object using the data stored in Session?
This can't possibly be a unique requirement. Are there libraries already available which handle this?
Session stores information in a client-side cookie too! (or in the URL if cookieless).
If you want to authenticate a client, he'll have to provide some kind of credentials - usually an encrypted token in a cookie once he has logged on. If not a cookie, then what do you propose?
You should use FormsAuthentication. The sensitive information stored in a client-side cookie is encrypted using a key that should only be known to the web server. "the encryption methods being public knowledge" doesn't mean that you can decrypt the data without access to the appropriate cryptographic key.
You mention "roles" and a "third-party authentication provider". If your third party is also providing roles (i.e. an "authorization provider" as well as an "authentication provider"), then it would be reasonable to cache roles obtained from the provider on the server. Session is not available when a request is being authorized, so the best solution is to use the Cache (System.Web.Caching.Cache).
Personally I would encapsulate this in a custom RoleProvider. The custom RoleProvider would implement GetRolesForUser by getting roles from the third party on the first call, then caching them in Cache.
Not sure if I like what I'm about to suggest, but you could do the following:
Leverage the Application State or System.Cache as a global storage for user credentials.
Use an InMemory database (like RavenDb) which can also have encryption (in memory, I believe).
Using the Application state as a place to storage relatively common / frequent stuff I think is not a great place because of
Scaling / locking issues? <-- just a gut feeling.
Permenant data? so you have users in the website's memory .. then the website crashes or recycles, etc... what happens now to that data?
RavenDb is awesomeballs - go.use.it.now.
I understand that you are not storing anything locally, so whenever a user hits your system, you need to refresh your inmemory cache, etc. Fine. A pain in the f'ing butt , but fine none-the-less. (EDIT: unless the data has been cached in memory .. that is)
Anywys, two suggestions.
ProTip:
Oh! move away from role based shiz and start using Claims based identity stuff. Yes, it still works with IPrincipal and HttpContext.User, etc. So all previous code is NOT busted. But now it's baked into .NET 4.5
Awesome Video on this for you, me, everyone!
Finally - bonus suggestion
A nice package that auth's with either Facebook/Google/Twitter. You said you're keeping the user cred's on another site (good move!). If you're using other providers, then stick with DNOA or SS.
GL!
I am using Asp.Net/C# and Visual Studio 2008 to build an application.Right now I want to create a login page for my application , I would like to ask you guys , what would be the best approach to it.Should I go with Forms Authentication in Asp.Net or Should I try looking at Ajax Login with Asp.Net.Which would be more appropriate.If possible please let me know some of the pros and cons of the approaches.Also could anyone suggest me some links for a good starting point.
Any suggestions are most welcome.
Thanks
I think you have to go for Forms Authentication. below is advantages of it.
1) users do not have to be member of a domain-based network to have access to your application.
2) Web applications, particularly commercial sites where customers order products, want to have access to user information. Forms authentication makes these types of applications easier to create.
3) Keep personalization cookies that contain user-specific preferences and non-sensitive data separate from authentication cookies.
4)Consider reducing the cookie lifetime to reduce the time window in which an attacker can use a captured cookie to gain access to your application with a spoofed identity.
List the steps to use Forms authentication in a web application?
1.Set the authentication mode in Web.config to Forms.
2.Create a Web form to collect logon information.
3.Create a file or database to store user names and passwords.
4.Write code to add new users to the user file or database.
5.Write code to authenticate users against the user file or database.
Hope this info is helpful to you make decision
Use OAuth for login.
It has ASP.net binding too..
http://oauth.net/code/
Hey folks, I would like to know is there any way i can maintain stuffs like log-in,log-out,user-session..etc without using membership in ASP.NET MVC?
Faraaz.
There are three provider models concerned with the areas that you are referring to.
The MembershipProvider is concerned with authentication, validating users and storing data related to the user such as last login date, username, etc.
The RoleProvider is concerned with authorising users for particular areas of your application.
The SessionStateProvider is concerned with storing session for your application.
You can write your own custom provider for any of them if the default providers are not suitable. You could roll your own authentication, authorisation, or session management without the providers, however there would be quite a bit of work involved more so than implementing your own custom provider.
You can use the Session object to store session scoped data.
But for authentication/authorization you will need to come up with your own scheme.
You need to use the Session dictionary and a session state server. See http://msdn.microsoft.com/en-us/library/ms178581.aspx for more info.
Word of warning: In my experience the InProc session state mode only preserves the values you put into Session for the lifetime of the current HTTP request. They don't persist across requests as you might expect, even when you're using a single HTTP server and you'd think in-memory storage would persist. This may only occur while debugging using the built-in http server in VS2010, but even so it can cause you a lot of trouble trying to understand why state information isn't being saved.
We're creating a new consumer/public-facing ASP.Net web app. There are two concerns:
--Use cookie or cookieless forms authentication?
--If we decide not to use cookies at all, how would you store the data that would otherwise be stored in the cookie (Customer ID, AffiliateID, etc.). Does the ASP.Net authentication framework track something like CustomerID?
For a normal web app there is no good reason to use cookieless authentication - Fear of cookies died out about a decade ago.
For actual data, the session object is generally a better choice than individual cookies - The session cookie is a single value that effectively gives you a key to whatever session data you have stored on the server. There are certain specialized cases where there are problems with using session, for example in multi-server deployments, but in for most applications it is simple and adequate.
The standard forms authentication system does track the username - generally this is enough to look up whatever data you need from your database if you don't want to keep anything in the session.
If you're doing authentication, cookies are the usual method. It's very rare these days that people will have cookies turned off because so many sites already depend on them.
Having said that, ASP.NET does support "cookieless" authentication. Basically it just adds the authentication token as a parameter on the URL. It parses all outbound URLs to ensure that they also include the token information. Personally, I wouldn't bother with this and just go with requiring cookies. There are a few additional headaches when trying to go cookieless (for example, it can make SEO that much harder, because the search engines will see a different URL every time it crawls the page).
Can someone explain the concept of sessions in ASP.NET? How do I use them, and how do cookies fit in?
Session is a per-user object for persisting state between HTTP requests. It is good for storing information that you will need on the server to properly serve requests back to the user (e.g. user name, email, etc.).
ASP.NET places a cookie on the client's machine that contains a GUID (in the case of cookieless sessions, this GUID is placed on the URL). This GUID is the user's session ID. This identifier is retrieved on each HTTP request from the client by the ASP.NET runtime. Subsequently this identifier is used to rehydrate the user's session data from the session's data-store (either in memory or in the database).
ASP.NET State Management Overview
"Use ASP.NET session state to store and retrieve values for a user."
Session State Overview
Background
Code Examples
Class References
Sounds like you're pretty new to ASP.NET. Rather than posting vague questions here, I would suggest you head over to http://www.ASP.net and check out their tutorials. They've got a lot of walkthroughs and articles that will give you a good overview of how ASP.NET state works.
A question like this makes me want to point you over to a post I did a while back (Should I Use a Framework While Learning Web Development) which will give you a heads up to other areas you might want to study up on. The topic of sessions is one of those bullet points.
I think that the idea of a session is well covered in the above posts so I won't further detail that!