FormsAuthentication class c# - c#

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.

Related

asp.net session and forms authentication time performance hit on server?

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.

Determine when an ASP.NET Forms Authentication will expire

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);
}

C# cookie based authorization

I am implementing C# authorization using jquery cookies for my page. I set/encrypt username and password in the cookie and in my admin page, if I recognize cookie, then the user is authorized. If not, he gets redirected to the login page. The problem is, that cookie is read after page is loaded, so I can manually hit admin page and only in couple seconds it will get redirected. How do I prevent loading admin page for visitors, who have no cookie yet? What is a correct architecture for cookie based authorization?
Note: I am not using ASP.NET roles or User tables. I implemented my own tables for users.
I suspect that you're re-inventing the wheel. You don't have to use the Membership Provider and ASP.Net membership schema in order to take advantage of forms authentication. When the user logs in, simply drop the Auth Ticket (cookie) on them and you're done. You can then simply do the admin check on the admin page.
Some suggestions below...
Edit: I originally posted a means of storing roles in the Auth Ticket via UserData, but I think it's overkill for this situation.
Web.config:
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="30" slidingExpiration="true" />
</authentication>
. . .
<membership>
<providers>
<clear />
</providers>
</membership>
Post login:
When the user submits their username and password, validate them and check to see if they are an admin:
if (UserIsValid(username, pwd)) // some validation call
{
FormsAuthentication.SetAuthCookie(username, true);
}
Admin.aspx:
Finally, a quick hack to restrict access to an admin page. When the page loads, check that the user is / is not an admin:
if (!IsAdmin(User.Identity.Name)) // some admin call
Response.Redirect("Default.aspx");
The problem is, that you use client side code for your security check. If someone would disable JavaScript completely, he would never be redirected. Move the check to your server side code.

Cookie doesn't persist

I've got an issue with my cookies. I'm authenticating users through LDAP and as long as the browser remains open users don't have to log back into the tool. They can even close the tab that's fine so long as the browser is open.
But the cookie gets removed the moment the user closes the browser. I've searched google a lot for this and I can't get any of the solutions to work such as this one or that one for example.
Here's my setup once they authenticate on my logon page:
String encryptedTicket = FormsAuthentication.Encrypt(authTicket);
//Create a cookie, and then add the encrypted ticket to the cookie as data.
HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
//Add expiration date to the cookie
authCookie.Expires = DateTime.Now.AddMonths(1);
//Add the cookie to the outgoing cookies collection.
Response.Cookies.Add(authCookie);
//You can redirect now.
FormsAuthentication.RedirectFromLoginPage(txtUsername.Text, false);
My Web.Config looks like this:
<authentication mode="Forms">
<forms loginUrl="Logon.aspx" timeout="43200" name="adAuthCookie" path="/" slidingExpiration="true" />
</authentication>
Whatever I do the ASP.NET_SessionId and adAuthCookie cookies are always set to expire "When I close my browser".
I want to avoid my users to always have to login when they close their browser and instead just do it once a month.
Sounds like you need to set a machineKey in your web.config.
If one is not specified either there or machine.config, it will be generated on start up and reset everytime the website is restarted, invalidating the encryption in the cookie.
machineKey element
Make sure browser is not set to delete cookies on close. There is such paranoid setting somewher in security options (I think in IE it is Advanced -> Security ->Empty temporary folders...)
Use Fiddler or other tool to make sure you send cookies with correct expiration to the browser. This way you verify where error is server or client side.

Logon identified -- any backend storage of this number?

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.

Categories

Resources