When you log on to an ASP.NET app you are issued with a logon cookie (I think it's called ASPX_AUTH or similar). What is the structure of this cookie? Does the server actually maintain any logon state, or is it purely what's within the cookie (in which case, can I force a very long logon state by chaning the cookie expiry?)
Tx, AJ.
The cookie is hashed and encrypted.
If you modify it, it will become invalid.
This behavior is controlled by the protection attribute of the <forms > element in Web.config.
If you want a long logon state, or for the login to not timeout, set two things in forms entry in the web.config:
timeout="_numer_of_minutes" slidingExpiration="true"
This will keep your user logged in.
Related
we have two part for authentication in web site. the first use in admin and the second use for users to enter to site.when admin authentication in site and go to user page ,make error.how to create different authentication for those?web config code:
<authentication mode="Forms">
<forms loginUrl="~/admin/Login.aspx" timeout="2880" />
</authentication>
Based on your reply in comments...
we read users permissions on sign on.when i use User.Identity.IsAuthenticated then its return true.but this Authenticated for admin.how to make different Authenticated for users?
Checking whether a user is authenticated is different from checking a user's permissions. Authentication only tells you that the person visiting your site has authenticated themselves (i.e. logged on to their account).
What's missing in your equation is the authorization phase (Remember college/uni? Everyone is issued ID cards, on access to the college/uni grounds you authenticate yourself, staff members also authenticate themselves, students won't have authorization to enter the staff room or perform certain tasks, but staff members do).
We implement this using what's called Roles, every user should have a Role. Every Role should have a set of Permissions associated with it, for now I wouldn't worry about Permissions as it can get real complicated real quick, if you focus on ìmplementing roles alone for now, it would be enough to get you going.
Once every user has a role associated to their account, you can check their Role instead of whether they're simply authenticated, which doesn't tell you much.
There should be an extension method to the IPrinciple interface along the lines of GetUserRoles() already implemented in framework, User.Identity.GetUserRoles() something along the lines of that.
So I was given the task to set the session time out to 24hr, doing some reading on the web i found out that i also need to set the forms authentication to that time frame so the user is not logged out. My question is , are there any drawbacks on the server side? Will it work harder/slower thanks to the fact that it has to keep all those sessions in check ?
Will it work harder/slower thanks to the fact that it has to keep all
those sessions in check ?
There is no performance improvement or slow down for Server except that user doesn't need to re-login and server doesn't need to authenticate the user again.
Once user is logged-in, server checks authentication cookie whether is still valid on every post back (doesn't matter how long or how short you set the timeout).
Normally, you want to set form authentication time out to be larger than session time out.
For example,
<authentication mode="Forms">
<forms loginUrl="~/Account/Login.aspx" timeout="2880"/>
</authentication>
<sessionState timeout="1440"/>
Its actually a bit more complex than that. I can't remember which is which but they have different expiries. Session timeout resets with every request whereas the forms auth ticket only resets after at least half the time out has expired. So this needs to be double the size of the session timeout.
Is it possible to determine the date & time when an ASP.NET session will expire when using Forms Authentication?
I would like to warn users when their sessions are about to expire. There is no session state & sliding expiration is disabled. Here are some of the system.web settings:
<authentication mode="Forms">
<forms defaultUrl="Default.aspx" loginUrl="Login.aspx" requireSSL="false" enableCrossAppRedirects="true" cookieless="AutoDetect" timeout="2" slidingExpiration="false"/>
</authentication>
<sessionState mode="Off"/>
The timeout / lifetime of a session is easy to determine, but should the user refresh the page within the session windows, adding the lifetime value to the date-time at reload will not be accurate.
Using an authentication cookie with FormsAuthenticationTicket ticket encrypted as its value, one can decrypt it to get the expiration date-time.
Although some AJAX calls may be made, the user might interact with the UI without any post back or request to the webserver.
Any ideas on how I can achieve this type of behavior without the use of cookies?
I have a similar problem. In my case given the low number of users, im opting for a better user experience with a polling ajax call on the page to call back into the server and check the expiration ticket. You may be able to get away with tweaking the below code and including expiration info in the page via http and keeping track of time in client javascript if you dont want to go the ajax route.
if (User.Identity.IsAuthenticated)
{
var identity = (FormsIdentity)User.Identity;
viewModel.UtcInactivityExpiryDate = identity.Ticket.Expiration.ToUniversalTime();
}
If you go the ajax route, there is another gotcha. You have to stop the ajax call itself from renewing the inactivity timeout if you are using one. You can do that by overwriting the new authentication cookie with the original one. at the end of your ajax request.
var requestCookie = HttpContext.Current.Request.Cookies[".ASPXAUTH"];
if (requestCookie != null)
{
HttpContext.Current.Response.Cookies.Add(requestCookie);
}
How can I remember a user that is logged in without having a security issue? Currently, I am storing the id and a guid into two different cookies and compare them when there is no session alive. If it match then I re-create the session. Btw, both id and guid are nore encrypted.
Is this method safe enough, or should I follow a rather distinct way?
Since cookies can be easily stolen by use of XSS, does not matter if you place information in just one cookie or two, because a theft will take them all.
I have solved with a more complex procedure: I place one encrypted cookie divided in 2 parts (but 2 cookies will work as well), one fixed and the other variable each session. Both are saved also on server side to check: they are only session identifiers, no sensible information contained in the cookie, the correspondence with the user id is saved on the server.
If a fake user enters the account with a stolen cookie, the variable part (or cookie) will change, so when real user connects again he will not be able to enter and you will have the proof that an unauthorized access occurred: then you can delete the permanent session on server side (defined by the fixed part or cookie) in order to avoid any further access by the theft. The real user will re-login and create a new permanent session with a new cookie. You can also warn him that you saw a security flaw, suggesting him to reset password (operation that should never be accessible directly from cookie) or to use another browser for unsafe navigation.
If you save additional user information (user-agent, IP by location) you can check cookie validity also on them in order to avoid even the first entrance of the fake user.
I would recommend you using forms authentication for tracking logged in users in an ASP.NET application.
If I call FormsAuthentication.SetAuthCookie("john", true), is the users name stored in the cookie?
What I'm trying to find out is if the users session times out and then the user revisit the site again, Request.IsAuthenticated is set to true, but where is the users name coming from?
Session timeout and authentication timeout are two separate things. You can have sessions time out without invalidating the authentication.
Yes, the user's name is stored in the authentication cookie. It is encrypted, however.
You can use your browser to examine the content of your cookies. For example my stack over flow cookie looks like:
F650CE82F53D2C39C8C06B5F26EB34E20FEAC3585035E2A6E9FA30B8ECF5051F4D9C8....
The value is an encrypted goo of a username and potentially the user roles.
The cookie is good as long as you want it to be. It isn't tied to the session.
In your sample code you created a persistent cookie, so it lives for the life of the cookie, even if you close your browser. Now if the cookie is memory based, it lasts until you close your browser, even if the expiration time would let it live longer.
Here are the default values:
<forms loginUrl="Login.aspx"
protection="All"
timeout="30"
name=".ASPXAUTH"
path="/"
requireSSL="false"
slidingExpiration="true"
defaultUrl="default.aspx"
cookieless="UseDeviceProfile"
enableCrossAppRedirects="false" />
As from this MSDN page it sets forms-authentication ticket to either cookies or in URL if CookiesSupported is set false.
When you set second argument as true, the cookie is persistent so when user visits second time (after session timesout) your app gets the cookie with auth-ticket and so it get the user details (as far as I think).
If you don't want to make this happen I think either setting the second argument to false:
FormsAuthentication.SetAuthCookie("john", false);
or explicitly clearing the ticket (and so cookie):
FormsAuthentication.SignOut();
will work for you.