Search Results

Search found 5 results on 1 pages for 'iprinciple'.

Page 1/1 | 1 

• Accessing Session and IPrinciple data in a Master View in Asp.Net MCV

  - by bplus

  I currently have a abstract controller class that I all my controllers inherit from. In my master page I want to be able to access some data that will be in Session and also the currently user (IPrinciple). I read that I could use the contructor of by abstract base controller class, that is I could do something like public BaseController() { ViewData["SomeData"] = Session["SomeData"]; ViewData["UserName"] = this.User.Identity.Name; } I could then access ViewData["UserName"] etc from my master page. My problem is that both Session and User are null at this point. Does anybody know of a different approach? Thanks in advance.

  Read the article

• Storing extended IIdentity in HttpContext.Current.User (IPrinciple)

  - by UpTheCreek

  I have created an ExtendedId class which extends GenericIdentity. (This stores Id as well as name) In a httpmodule I stored this extended id in Current.User like so: HttpContext.Current.User = new GenericPrincipal(myExtendedId, roles); Problem is, later, how do I get at my ExtendedId type again? If I try this: ExtendedId eId = (ExtendedId)HttpContext.Current.User.Identity; I get a casting error. I have a feeling I'm doing something stupid here with casting, but I'm a bit foggy this morning.

  Read the article

• MVC 2 AntiForgeryToken - Why symmetric encryption + IPrinciple?

  - by Brad R

  We recently updated our solution to MVC 2, and this has updated the way that the AntiForgeryToken works. Unfortunately this does not fit with our AJAX framework any more. The problem is that MVC 2 now uses symmetric encryption to encode some properties about the user, including the user's Name property (from IPrincipal). We are able to securely register a new user using AJAX, after which subsequent AJAX calls will be invalid as the anti forgery token will change when the user has been granted a new principal. There are also other cases when this may happen, such as a user updating their name etc. My main question is why does MVC 2 even bother using symmetric encryption? Any then why does it care about the user name property on the principal? If my understanding is correct then any random shared secret will do. The basic principle is that the user will be sent a cookie with some specific data (HttpOnly!). This cookie is then required to match a form variable sent back with each request that may have side effects (POST's usually). Since this is only meant to protect from cross site attacks it is easy to craft up a response that would easily pass the test, but only if you had full access to the cookie. Since a cross site attacker is not going to have access to your user cookies you are protected. By using symmetric encryption, what is the advantage in checking the contents of the cookie? That is, if I already have sent an HttpOnly cookie the attacker cannot override it (unless a browser has a major security issue), so why do I then need to check it again? After having a think about it it appears to be one of those 'added layer of security' cases - but if your first line of defence has fallen (HttpOnly) then the attacker is going to get past the second layer anyway as they have full access to the users cookie collection, and could just impersonate them directly, instead of using an indirect XSS/CSRF attack. Of course I could be missing a major issue, but I haven't found it yet. If there are some obvious or subtle issues at play here then I would like to be aware of them.

  Read the article

• Using IPrinciple.Identity.Name as a key in a dataBase to identify user's rows.

  - by bplus

  I'm writing a small intranet app that uses Windows Authentication and Asp.Net MVC. I need to store various bits of data in a db against each user. As far as I can tell the IPrinciple object does not seem to have something like a unique id. So I was thinking I could just use User.Identity.Name as a unique value to identify rows in my db. Is this a bad idea? Is there an alternative to this approach? Thanks for any help.

  Read the article

• set current user in asp.net mvc

  - by Tomh

  Hey guys, I'm not sure if this is the best way to do it, but I want to keep a user object alive during all requests of the current user. From reading several resources I learned that you should create your own IPrinciple which holds this. But I don't want to trigger the database every authentication request. Any recommendations on how to handle this? Is caching the db request a good idea? protected void Application_AuthenticateRequest(Object sender, EventArgs e) { HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName]; if (authCookie != null) { FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value); User user; using (HgDataContext hg = new HgDataContext()) { if (Session["user"] != null) { user = (from u in hg.Users where u.EmailAddress == authTicket.Name select u).Single(); } else { user = Session["user"] as User; } } var principal = new HgPrincipal(user); Context.User = principal; } }

  Read the article

1