469,591 Members | 1,519 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,591 developers. It's quick & easy.

Storing Role And User Id in UserData of FormAuthentication

hello,

i have been scouring the groups for the best possible solution to this
problem, but can't seem to find my exact scenario, so hopefully someone
can get me back on the right path. my situation is the following:

i have a asp.net app that uses formsauthentication, and in the UserData
field we store the role value of what the user is (ie admin, user,
etc.). i want to also store the user id in this UserData field so i
have added that and separated it by a comma, so the value would look
something like "Admin,123". so on the Application_AuthenticateRequest
event in global.asax.vb i can easily split the values on the comma and
then have the roles which are used in:

HttpContext.Current.User = New GenericPrincipal(id, asRoles)

to verify whether they have access to certain directories or whatnot.
but within this GenericPrincipal there doesn't seem to be a place to
store this User Id value and have it readily available from each page.
i know you can do something like HttpContext.Current.User.Identity.Name
and that will give you the name value that you stored in the
formsauthentication ticket, but there still isn't a way to get the user
id. i tried setting a session variable in the
Application_AuthenticateRequest event to store the user id, but kept
getting an error; my thinking was that this way the authentication and
session would still be in sync because every time the user
authenticated, the session variable would be set (and i wouldn't be
using the session variable on pages that did not require
authentication). i have also seen where the id is appended to the Name
in the ticket, and then split out, but that doesn't seem very .net like
to me.

so i guess my question is what am i missing? most examples i have seen
just store the "roles" in the user data field, and not multiple types
of data like user id, first name, last name, etc.

thanks to any and all who respond,
jamie

Nov 19 '05 #1
4 1803
Hi Jamie:

After you have assigned the GenericPrincipal to the
HttpContext.Current.User, you can always retrieve the User ID back from the
FormsAuthenticationTicket in the Context.User.Identity:

CType(CType(CType(Context.User.Identity,
System.Security.Principal.IIdentity),
System.Web.Security.FormsIdentity).Ticket,
System.Web.Security.FormsAuthenticationTicket).Use rData

---
www.societopia.net
"Jamie Pollard" wrote:
hello,

i have been scouring the groups for the best possible solution to this
problem, but can't seem to find my exact scenario, so hopefully someone
can get me back on the right path. my situation is the following:

i have a asp.net app that uses formsauthentication, and in the UserData
field we store the role value of what the user is (ie admin, user,
etc.). i want to also store the user id in this UserData field so i
have added that and separated it by a comma, so the value would look
something like "Admin,123". so on the Application_AuthenticateRequest
event in global.asax.vb i can easily split the values on the comma and
then have the roles which are used in:

HttpContext.Current.User = New GenericPrincipal(id, asRoles)

to verify whether they have access to certain directories or whatnot.
but within this GenericPrincipal there doesn't seem to be a place to
store this User Id value and have it readily available from each page.
i know you can do something like HttpContext.Current.User.Identity.Name
and that will give you the name value that you stored in the
formsauthentication ticket, but there still isn't a way to get the user
id. i tried setting a session variable in the
Application_AuthenticateRequest event to store the user id, but kept
getting an error; my thinking was that this way the authentication and
session would still be in sync because every time the user
authenticated, the session variable would be set (and i wouldn't be
using the session variable on pages that did not require
authentication). i have also seen where the id is appended to the Name
in the ticket, and then split out, but that doesn't seem very .net like
to me.

so i guess my question is what am i missing? most examples i have seen
just store the "roles" in the user data field, and not multiple types
of data like user id, first name, last name, etc.

thanks to any and all who respond,
jamie

Nov 19 '05 #2
wow, thanks a bunch, that is exactly what i needed. i'm kinda confused
by that statement though. could you please explain how that is working?

thanks,
jamie

Nov 19 '05 #3
"Jamie Pollard" wrote:
wow, thanks a bunch, that is exactly what i needed. i'm kinda confused
by that statement though. could you please explain how that is working?

thanks,
jamie


You are welcome. In your original code you created a GenericPrinciple
object using a FormsAuthenticationTicket. Therefore all you needed was to
retrieve the UserData property of the FormsAuthenticationTicket. (The
UserData has the User ID value that you were looking for)

---
www.societopia.net

Nov 19 '05 #4
yeah, i realized that part. i guess i just figured that there wasn't an
easy way to access that data without creating the ticket again and
extracting the data like in the Application_AuthenticateRequest Sub.
but this does exactly what i want. i guess my main questions is with
all the ctypes and everything? i mean i know what ctype does, just
kinda don't know how it's actually working.

thanks,
jamie

Nov 19 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by jas | last post: by
2 posts views Thread by Jesper Stocholm | last post: by
reply views Thread by Sean Patterson | last post: by
5 posts views Thread by Archer | last post: by
reply views Thread by Colin Peters | last post: by
2 posts views Thread by Anthony Smith | last post: by
2 posts views Thread by Anthony Smith | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.