无法设置FormsAuthenicationTicket.UserData在cookie的模式 [英] Can't set FormsAuthenicationTicket.UserData in cookieless mode

查看:343
本文介绍了无法设置FormsAuthenicationTicket.UserData在cookie的模式的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想实现的这篇文章,但它不正确时,cookie是URI的一部分工作。

I'm trying to implement the "Writing Information to UserData" section of this article, but it doesn't work properly when the cookie is part of the URI.

我的代码:

// Create the cookie that contains the forms authentication ticket
HttpCookie authCookie = FormsAuthentication.GetAuthCookie( userName, createPersistantCookie );

// Get the FormsAuthenticationTicket out of the encrypted cookie
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt( authCookie.Value );

// Create a new FormsAuthenticationTicket that includes our custom User Data
FormsAuthenticationTicket newTicket = new FormsAuthenticationTicket( ticket.Version, ticket.Name, ticket.IssueDate, ticket.Expiration, ticket.IsPersistent, "foo");

// Update the authCookie's Value to use the encrypted version of newTicket
authCookie.Value = FormsAuthentication.Encrypt( newTicket );

// Manually add the authCookie to the Cookies collection
HttpContext.Current.Response.Cookies.Add( authCookie );

// Determine redirect URL and send user there
string redirUrl = FormsAuthentication.GetRedirectUrl( userName, createPersistantCookie );

HttpContext.Current.Response.Redirect( redirUrl, false );

在Cookie的使用,页面重定向,但与cookie信息没有得到正确的URI它,所以它循环回哪里Request.IsAuthenticated返回false我的登录页面。一个无限循环随之而来。

When cookieless is used, the page redirects but doesn't get the correct URI with the cookie information in it, so it loops back to my Login page where Request.IsAuthenticated returns false. An endless loop ensues.

我如何重定向到合适的URI?

How do I redirect to the proper URI?

推荐答案

我发现这是一个有趣的问题,所以我着手做一些挖掘,测试和调试的一点点到.NET Framework的源。

I found this to be an interesting problem, so I set about doing some digging, testing, and a little bit of debugging into the .net framework source.

基本上,你正在尝试做是行不通的。如果浏览器不支持cookie,你把Response.Cookies集合东西只是被忽略。您可以检查Request.Browser.Cookies,看看饼干的支持。

Basically, what you are trying to do will not work. Anything you put into the Response.Cookies collection will just be ignored if the browser doesn't support cookies. You can check Request.Browser.Cookies to see if cookies are supported.

在asp.net,无论会话状态和认证支持cookie的模式,但这并不能延长其他饼干。实际上,似乎会话和认证可以设置为,即使不同的操作模式本身。

In asp.net, both session state and authentication support a cookieless mode, but this does not extend to other cookies. In fact, it seems that session and authentication can be set to different modes of operation themselves even.

的认证系统可以存储它的在URI自己的数据,但它通过直接操作的URI本身确实如此。可悲的是,微软似乎并没有暴露了这些功能来验证模块外的代码。

The authentication system can store it's own data in the URI, but it does so by directly manipulating the URI itself. Sadly, Microsoft doesn't appear to have exposed these capabilities to code outside the authentication module.

基本上,如果你使用像FormsAuthentication.GetAuthCookie()和FormsAuthentication.SetAuthCookie()方法则认证系统将采取把这些信息到URI为你的护理自动的...但它不允许您提供一个定制的身份验证票证这些方法......所以你被卡住的缺省auth ticket.In这种情况下,你是你自己的存储任何自定义数据。

Basically, if you use the methods like FormsAuthentication.GetAuthCookie() and FormsAuthentication.SetAuthCookie() then the authentication system will take care of putting that information into the URI for you automagically... but it doesn't allow you to supply a customized authentication ticket to these methods... so you are stuck with the default auth ticket.In these cases, you are on your own for storing any custom data.

反正...

有真的是没有太大的优势,直接存储,如果一个身份验证票证自定义数据认证系统已经Cookie的......在cookie的模式,像持续性饼干已经没有什么意义,所以你至少一次每个会话反正重新生成数据。

There really isn't much advantage to storing custom data directly in an authentication ticket if the authentication system has gone cookieless... in cookieless mode, things like "persistant cookie" have no meaning so you'll be regenerating the data at least once per session anyway.

为你在哪里Cookie的,但仍然需要自定义数据这样是为了让Cookie会话,只是存储您的自定义数据为一个会话变量的情况下最常见的建议。会话ID将获得投入URI,但自定义数据将保留在内存中的服务器上。使用模式是相同的,无论如果会话Cookie的或没有。

The most common suggestion for cases where you are cookieless but still need custom data like this is to enable cookieless sessions, and just store your custom data as a session variable. The session ID will get put into the URI, but the custom data will stay in memory on the server. The usage pattern is identical no matter if your sessions are cookieless or not.

如果你真的想要,你能想出手动存储URI中的自定义数据的系统。最容易做的事情是把自定义数据到查询字符串或使用pathdata。我看不到任何真正的优势,这种过度的会话变量,除非你只是deperate不使用服务器内存(加入少许内存的服务器很便宜的,丑陋的URL和手动编写代码来处理它们可不便宜)。

If you really wanted to, you could come up with a system of storing the custom data in the URI manually. The easiest thing to do would be to put the custom data into query strings or use pathdata. I can't see any real advantage to this over sessions variables unless you are just deperate not to use server memory (adding a little memory to a server is cheap, ugly URLs and manually writing code to deal with them is not cheap).

这篇关于无法设置FormsAuthenicationTicket.UserData在cookie的模式的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆