Azure ACS +表单值存储

发布于 2024-12-18 07:22:57 字数 411 浏览 1 评论 0原文

我在我的 ASP.net MVC 3 网站(也在 Azure 中托管)中使用 Azure ACS,场景如下: 用户首先进入我的网站并填写单字段表单,然后他们需要选择提供商并登录,但首先我想存储字段值,以便当他们登录回来时我能够创建具有该值的配置文件对于登录的用户。

所以我相信当他们第一次进入网站然后离开登录并再次进入网站时,这是两个不同的会话,我对吗?这就是使用会话状态(通过 SQL Server)存储的数据在登录后返回时不存在的原因,对吗?如果这是真的,那么最好的方法是什么?如果不是,那么我在存储临时数据时做错了什么,对吗?

谢谢

更新: 我发现 HttpContext.Application 状态可以保存数据,但我仍然不确定考虑到它在 Azure 中,在控制器中使用它是否是一个好主意,它是否可以在生产中正常工作?

I'm using Azure ACS in my ASP.net MVC 3 website (hosted in Azure too), the scenario is this:
A user first enters my website and fills a one field form, then they need to chose a provider and login, but first I want to store the field value so when they come back from login I'm able to create a profile with this value for the loged in user.

So I believe when they first enter the site and then leaves to login and enters the site again those are two different sessions am I right? and that's the reason the stored data using session state (through SQL Server) is not present when they come back after login am I right? if this is true what would be the best approach then? if not then I'm doing something wrong storing temp data right?

Thanks

UPDATE:
I have discovered that HttpContext.Application state works keeping the data, still I'm not sure if it's a good idea to use it in a controller considering it's in Azure, will it work on production properly??

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

酒与心事 2024-12-25 07:22:57

您可以使用 wctx URL 参数在 WS-Federation 重定向序列中传递状态。在处理初始 POST 请求的操作中,您应该获取要保留的表单参数,然后重定向到身份提供商选择页面(这必须是自定义页面),并将表单参数附加到 URL。当用户在您的页面上选择 IP 时,您可以使用 wctx 参数再次传递该参数。 WS-Federation 被动请求者配置文件表示,当 IP 将用户重定向回您的站点时,最终应将其返回给您。

这有一些详细信息

http://msdn.microsoft.com/en-us/library /bb608217.aspx

编辑: 当用户最终返回您的应用时,从请求中获取 wctx 参数。在操作代码中放入类似这样的内容:

var fam = FederatedAuthentication.WSFederationAuthenticationModule;

if (fam.CanReadSignInResponse(System.Web.HttpContext.Current.Request, true))
{
    string wctxValue = this.HttpContext.Request.Form["wctx"];
}

我的偏好是让 wcxt 参数表示重定向 URL(URL 编码),并将您的参数作为查询参数,以便它成为以下内容的 URL 编码版本:

wctx=https://yourserver/yourapp/yourpage?yourparameter=foo

然后是接收的操作来自 ACS 的重定向将简单地提取 wctx 的值并对其进行重定向,而无需任何其他处理。这让事情变得简单。

You can pass state around in the WS-Federation redirect sequence using the wctx URL parameter. In the action that handles the initial POST request, you should get hold of the form parameter you want to keep, then redirect to you identity provider selection page (this will have to be a custom page) with the form parameter appended to the URL. When the user selects an IP on your page, you can pass the parameter on again using the wctx parameter. The WS-Federation passive requestor profile says that this should be returned to you eventually when the IP redirects the user back to your site.

This has some details

http://msdn.microsoft.com/en-us/library/bb608217.aspx

Edit: To get the wctx parameter out of the request when the user finally comes back to your app. Put something like this in the action code:

var fam = FederatedAuthentication.WSFederationAuthenticationModule;

if (fam.CanReadSignInResponse(System.Web.HttpContext.Current.Request, true))
{
    string wctxValue = this.HttpContext.Request.Form["wctx"];
}

My preference is to have the wcxt parameter represent a redirect URL (URL encoded) with your parameter as a query parameter in that so it be a URL encoded version of this:

wctx=https://yourserver/yourapp/yourpage?yourparameter=foo

Then the action that was receiving the redirect from the ACS would simply pull out the value of wctx and do a redirect to it without any more processing. This keeps things simple.

魔法唧唧 2024-12-25 07:22:57

另一种方法是将需要在数据库中传递的任何数据保存下来,并仅传递一些引用回数据库记录的 ID。您将将此 ID 传递给 IP,并通过 wctx 返回(正如上面 Mike 提到的)。

这将解决 URL 长度有限的问题(如果您的数据非常大)。当然,您需要管理这些数据的删除,但这应该不难。

Another approach would be to save whatever data you need to pass around in the Database, and just pass around some ID that refers back to the database record. You'll pass this ID to IP and back through wctx (as Mike mentioned above).

This will solve the issue of limited length of URLs (in case your data is very large). Of course you would need to manage deletion of this data, but this shouldn't be hard.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文