【问题标题】:Retain session when calling from a different website从不同网站呼叫时保持会话
【发布时间】:2013-01-09 11:45:43
【问题描述】:

我有两个网站,分别是 website1website2

在 website2 中有一个登录页面。当用户单击登录按钮时,它将调用 website1 中的 HTTPhandler 来验证用户。成功验证后,用户信息将存储在处理程序的 Session 变量中。

然后它会重定向到website1中的page1.aspx页面。但是之前设置的会话在page1.aspx中不可用。会是什么问题?

我在第一个请求(从 webiste 2 调用网站 1 中的处理程序时)和第二个请求(从处理程序重定向到 page1.aspx)中检查了会话 ID,会话 ID 不同。

如何保留会话数据?

【问题讨论】:

  • 我假设你的意思是一个 HttpHandler?您是否像在这个问题中那样从中访问会话:stackoverflow.com/questions/1058568/…
  • 我们已经在使用 IRequiresSessionState 接口,并且我们能够从 HttpHandler 将数据存储在会话中
  • 如果两个网站在同一台计算机上,您可以使用 ASP.Net 缓存来存储身份验证数据。
  • 两个网站将在不同的机器上
  • 我相信默认情况下会话不会跨机器共享。你在分享会话吗? (进程外或 SQL Server 状态)

标签: c# asp.net


【解决方案1】:

您需要将会话数据存储在与两个网站共享的另一个进程中。 你可以通过两种不同的方式做到这一点:

  1. 配置 SQL 服务器
  2. 配置 SessionState 服务,一个用于共享信息的 Windows 服务。

在这两种情况下,您都必须更改两个 web.config 文件以支持新的会话模式。 IE。使用 SQL:

准备一个数据库(从命令提示符):

cd \Windows\Microsoft.NET\Framework\v4.0.30319
aspnet_regsql.exe  -ssadd -E -S localhost\sqlexpress

修改网页配置如下:

<sessionState mode="SQLServer"
        sqlConnectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;Initial Catalog=Test" allowCustomSqlDatabase="true"/>

您无需更改代码。

【讨论】:

    【解决方案2】:

    如果我错了,请纠正我,AFAIK 不同的域不能共享一个会话。处理此问题的一种方法是通过 cookie [加密值以确保安全] 将数据传送到另一个站点,然后将此 cookie 值复制到接收它的另一个站点中的会话并销毁 cookie。

    如果站点位于不同的服务器中,您需要处理“粘性会话”,以便服务器共享会话。

    【讨论】:

    • 我认为这不是一个好主意,因为它会允许会话劫持。
    • 我猜@jonathan 是对的,我更像是想找出一种可能性。同样,我也不确定。
    【解决方案3】:

    这种情况听起来有点类似于我之前经历和工作过的情况,其中一个 Web 应用程序充当登录页面,而另一个是完成所有工作的实际应用程序。我可以描述一下我所做的事情,希望对你有用。

    和你一样,我有一个有登录页面的网络应用程序(所以在你的例子中,这将是 website2)。提交登录表单后,我会重定向到 website1 中的虚假 Login.aspx 页面 - 我认为这是我们不同的地方,因为我不确定您使用 HttpHandler 的具体原因。

    就我而言,website2 Login.aspx 页面实际上只是进入 Web 应用程序的途径;它没有标记,只是代码隐藏,它将验证用户,执行设置(例如设置会话变量),然后重定向到另一个页面,例如Homepage.aspx。这种特殊情况对我有用,所以您的问题可能与使用 HttpHandler 有关,尽管我无法告诉您原因。

    【讨论】:

    • 我已经用 .aspx 页面尝试过,但它不起作用!有什么想法吗?
    【解决方案4】:

    为了在运行 ASP.NET Web 应用程序的两个不同服务器之间保持相同的会话日期,您必须将会话状态配置为进程外管理。这意味着实际的会话状态数据变量将存储在工作进程之外以及能够使会话数据对其他机器可用的另一个进程中。

    要实现这一点,您可以将应用程序配置为使用 SQL Server 存储会话状态,并使其可用于场中的多个服务器。 TechNet 文章 Configure a SQL Server to Maintain Session State (IIS 7) 提供了有关在 IIS 7 中完成此操作的详细信息。

    如果您使用的是 IIS 6,那么配置步骤会有所不同,如果需要,我可以提供更多详细信息。

    为了使其正常工作,您需要确保两台服务器都在同一个域中运行应用程序,例如myapp.com,否则 ASP.Net 会话 cookie 将不会在两台服务器之间传递。 ASP.Net 使用 cookie 来查找存储在 SQL Server 中的会话状态,因此如果 cookie 未在两个服务器之间的请求上传递,则不会找到任何匹配的会话。

    【讨论】:

      【解决方案5】:

      我认为 IRequiresSessionState 无济于事,因为上下文不同。 一旦我们遇到同样的问题,但就是将 asp 会话变量传递给 .net。你怎么也可以在这里做到。 在这两个网站上创建一个页面 setsession.aspx 现在如果你在页面上说 web1/page5.aspx 并想去 web2/page3.aspx 你重定向到 web1/setsession.aspx?togo1=web2/page3.aspx 在两个 setsession.aspx 逻辑中提取会话数据并将它们放在查询字符串中

      所以 web1/setsession 将重定向到 web2/setsession.aspx?sess1=value1&sess2=value2&togo=page3.aspx

      web2/setsession.aspx 将检查 togo 查询字符串,如果找到,将提取所有查询字符串名称和值,并将它们设置在会话中,然后重定向到 togo 值。

      你需要仔细区分togo1和togo。

      【讨论】:

        【解决方案6】:

        网站之间的会话共享将需要手动编码。您可以破解 asp.net 框架来使其正常工作,但我觉得这不是实现您所设定的目标的干净方式。

        如果您只在网站上进行用户身份验证,是否可以使用替代方法?单点登录机制将为您提供帮助。

        SAMLSSO 这样的东西可以在这种情况下帮助你。

        【讨论】:

          【解决方案7】:

          您有两个托管在不同服务器上的网站,这意味着您有两个不同的进程在不同的机器上运行,因此会话肯定会有所不同。同一会话不能跨进程共享,因为默认情况下 asp.net 支持内存会话。

          在这里,您需要考虑存储可以在两个进程之间共享的会话信息(即进程外)。在数据库中存储会话信息的理想方式。为此,您可以考虑上面的 Stefano Altieri 代码示例。

          【讨论】:

            【解决方案8】:

            我认为您根本不想在两个网站之间共享会话信息。根据我从 cmets 收集到的信息,您真正想做的是让用户在一个网站上进行身份验证(给您一个经过验证的用户名和密码),然后将该“登录”状态转移到另一个网站'不为自己处理身份验证。

            您所描述的是委托身份验证模型。

            在此模型中,您的应用程序将身份验证交给它信任的其他系统来提供有关用户的信息。

            有两个众所周知的协议可以提供这种机制:

            OpenID
            这是为了方便用户使用自己的身份提供商(Google、Facebook、Microsoft 帐户)登录。如果您运行的是面向公众的网站,这是一个非常好的选择,因为大多数用户已经拥有可以登录的帐户。

            WS-Federation
            这是为了方便用户使用由已知可信方(例如合作伙伴组织)管理的身份提供者登录。

            从 4.5 版开始,.NET Framework 通过Windows Identity Foundation 组件内置了对 WS-Federation 的支持(并且还可以单独下载早期版本)。这会自动将您的身份验证委托给身份提供者的任务。

            它还提供组件供您编写自己的身份提供程序,如果您想创建自己的身份提供程序,但您不应该这样做;您可以找到各种现有的实现来为您完成这项工作。


            您要解决的问题是一个非常困难的问题,尤其是要使其足够安全可靠。好消息是,比你或我更聪明的人已经花了数年时间研究出非常聪明的方法来做到这一点。您应该使用他们所做的,而不是试图拼凑一些超出 Session 状态的东西。

            从长远来看,最好让更聪明的人为你工作。

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 1970-01-01
              • 2014-05-29
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2014-03-29
              • 1970-01-01
              • 2011-03-31
              相关资源
              最近更新 更多