Question

I am upgrading a website written using ASP.NET 1.1 and the logic for the login page includes verifying the credentials, calling FormsAuthentication.SetAuthCookie() and populating the Session with the user information.

I am updating this page to use Login controls and the Membership API and am trying to wrap my head around the concepts that have been changed.

1. Most of the samples I see do not do anything on the login button event handler, so is the logic of setting the cookie abstracted out into the control?
2. Also, how do I check if a user is logged in or not on other pages. Does it still store user information using the Session?
3. How do I check if a user belongs to a particular role or not (Earlier, I would look in the Session object to do something like this)
4. Is the Session a bad way of storing user info?

Thanks

Answer 1

If you’re using membership along with the login controls, the api handles authenticating the user when the login button is clicked. You can also handle the event if there is other stuff you need to do when a user logs in. If you don’t use membership, you’ll need to handle the login click and authentication yourself.

you don’t necessarily need to check if a user is logged in if you have the authentication set up correctly in the web.config, but if you have pages that logged in users and anonymous users can both access you might want to look at the loginview control. You can also check if a user is logged in using the Page.User.Identity.IsAuthenticated method.

To check if a user is in a role, just use Page.User.IsInRole(“role name”) or System.Web.Security.Roles.IsUserInRole(“username”, “rolename”)

I don’t think session is a bad way to store user info, but if you’re using membership then I don’t see the point.