Flixon Templates + Caching

forumuser · April 29th, 2009, 07:02 AM

hi - i have been using the new flixon templates to generate some code and was wondering...say for example, i have a login screen and a user successfully logs in. i then want to store that user in session...or someplace else? i have been looking at bizobject.cs and it contains a lot of cache code. is there a mechanism in there i could/should be using instead of vanilla session?

thanks for any replies.

Lee Dumond · April 29th, 2009, 12:12 PM

What exactly do you mean by "store the user in session"?

The Session object is unique to each user. Not sure why you would want a user's session to store the user itself? Normally, the user's logged-in state is persisted via an authentication ticket that is passed back and forth on each request via a cookie.

forumuser · April 29th, 2009, 04:20 PM

hi lee,
thanks for your reply. it was simply so that i could have access to various user fields during a user's visit. ie i create a user when a user logs in and i want to have access to various fields of that user during their visit to the site. i'm not clear that all these fields are contained within the ticket?

Lee Dumond · April 29th, 2009, 04:51 PM

The authentication ticket contains no field information whatsoever. It only contains a encrypted key that identifies the user.

Depending on which properties you need at runtime, you can do one of the following:

1. Use the Membership API to get user-related information. You can use the GetUser method to retrieve an object representing the current user:

MembershipUser currentUser = Membership.GetUser();

Then, you can access the properties of currentUser.

2. If you use the ASP.NET Profile system, you can store any additional information you want about the user (personal info, contact info, etc), then use the Profile object to retrieve that information.

Profiles offer a much more reliable alternative to Session state for storing user information. Unlike Session state, profile properties are strongly typed, meaning that their types are known at design time. This lets us access them without casting, do compile-time checking on them, use Intellisense with them, and so on.

3. Finally, you can store personal user information in your own custom tables, and write your own API for accessing the data. That's a lot of work that probably isn't necessary unless you have some special need, like needing to run a lot of custom queries against the data.

forumuser · April 30th, 2009, 03:27 AM

hi lee. i use my own tables for storing user info, since i didn't like the way that the profiles thing serialised everything. anyway, i guess you have clarified the situation for which many thanks.

cohdr01 · July 18th, 2009, 11:03 AM

Hi,
I'm want to filter the article list (in the webpart) by the user information.
The code I wrote is getting the current user information using the code below -

Code:

MembershipUser usr = Membership.GetUser();

However, when the code is running in the GetArticlesRSS.aspx.cs, it always returns null.

The same code in the welcome box is returning the right information, but I didn't figured out what is differnet.

Any help will be appriciated.
Dror