保护 MediaWiki 免受公共访问 在 Linux PHP 上验证 Windows ASP 服务器

发布于 2024-11-08 20:50:11 字数 498 浏览 0 评论 0原文

我们有一个在 IIS6 ASP.Net 服务器上运行的 Web 应用程序。您必须登录才能使用该软件。基本上,当您登录时,会生成一个 cookie,然后当您访问后续页面时,它们会检查该 cookie;如果不存在,那么您将被重定向到登录。

我们希望使用 Linux/PHP (LAMP) 实现 MediaWiki 服务器,为我们的用户提供“wiki”格式的帮助部分。但是,我们希望只允许登录该软件的人员进行访问。

因此,我们有 software.company.com(Windows/IIS6/ASP.NET 服务器),您可以登录并导航到我们的帮助,该帮助会将您重定向到 kb.company.com(Linux/Apache/PHP 服务器)。

我的想法是在 Linux 服务器上使用相同类型的“cookie”检查,但我不确定如何让 Windows IIS 框将令牌或其他内容传递给 Linux 服务器,说“嘿,这个用户已登录,所以为他们生成一个cookie”。

有人做这样的事吗?我可能完全错过了我的想法......

We have a web application that runs on a IIS6 ASP.Net server. You must be logged in to use the software. Basically when you login a cookie is generated then when you visit subsequent pages they check for that cookie; if it is not there then you are redirected to login.

We want to implement a MediaWiki server using Linux/PHP (LAMP) to provide a "wiki" formatted help section for our users. However, we want to only allow access from people that are logged in to the software.

So we have software.company.com (Windows/IIS6/ASP.NET server) that you login and navigate to our help which redirects you to kb.company.com (Linux/Apache/PHP server).

My thoughts are to use the same sort of "cookie" checking on the linux server, but I'm not sure how to get the Windows IIS box to pass a token or something to the Linux server saying "hey this user is logged in so generate a cookie for them".

Anyone do anything like this? I may be completely missing the boat in my thinking...

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

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

发布评论

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

评论(1

演多会厌 2024-11-15 20:50:11

这里的问题是如何告诉 kb.company.com 站点入站用户经过真正的身份验证并登录到 support.company.com

我们有一个非常相似的设置。我们有一个经销商门户,我们有一个私人知识库维基站点。

为了将用户转移到 wiki 站点,我们有一个特殊的链接,该链接请求 support.company.com 上的一个页面,该页面生成一个数据块和一个会话密钥(例如一个或两个 guid),持久化到两个站点都可以访问的“会话传输”数据库表。

然后,我们使用此密钥 Response.Redirect() 将用户引导至 wiki 站点,例如:

http://kb.company.com/DoLogin.aspx?session=E97DDE8D-1C57-4450-ABE4-72E2054A1C82

在 wiki 中(我们稍微修改了 ScrewTurn wiki),我们打开了表单身份验证并拒绝匿名用户的访问。 DoLogin.aspx 从查询字符串中获取session 值,然后查找存储在“会话传输”表中的记录。如果匹配,则我们对用户进行身份验证并删除会话传输记录。

会话传输记录还带有日期和时间戳记,并且生命周期为 90 秒,之后清理任务将删除该记录。

您可以通过 cookie 来传递会话密钥值,其中 cookie 域设置为company.com:

HttpCookie cookie = new HttpCookie("session", "<guid>");
cookie.Domain = "company.com";

进一步的修饰是对 cookie 值进行加密,进行一些哈希处理并检查是否存在篡改传输的另一侧。然而,我们 wiki 中的内容并不是非常有价值(最终用户都无法编辑这些内容),我们只是想阻止偶然路过的人,这对我们来说效果很好。

The problem here is about how to tell the kb.company.com site that the inbound user is genuinely authenticated and logged into support.company.com.

We have a very similar setup. We have a reseller portal and we have a private knowledgebase wiki site.

To transfer users over to the wiki site we have a special link that requests a page on support.company.com which generates a blob of data and a session key (for example a guid or two) that is persisted to a "session transfer" database table that's accessible to both sites.

We then Response.Redirect() the user to the wikisite with this key, for example:

http://kb.company.com/DoLogin.aspx?session=E97DDE8D-1C57-4450-ABE4-72E2054A1C82

In the wiki (we modified ScrewTurn wiki slightly) we have Forms Authentication turned on and deny access to anonymous users. The DoLogin.aspx grabs the session value from the query string and then looks for the record stored in the "session transfer" table. If there's a match then we authenticate the user and delete the session transfer record.

The session transfer record is also date and time stamped and is allowed a lifetime of 90 seconds after which a cleanup task will delete the record.

Rather than pass the session key value via the querystring you could pass this via a cookie where the cookie domain is set to company.com:

HttpCookie cookie = new HttpCookie("session", "<guid>");
cookie.Domain = "company.com";

Further embellishments would be to encrypt the cookie value do some hashing and check for tampering on the other side of the transfer. However the content in our wiki isn't terribly valuable (none of it is editable by the end user), we just wanted to keep out casual passer's by, and this works just fine for us.

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