ASP.Net 安全 - 通过第 3 方请求参数对测试用户进行身份验证
我有一个不理想的应用程序，无需深入了解，这就是所需要的。
第三方应用程序需要向将返回数据的页面发出请求。 因为我启用了表单身份验证，所以该请求最终总是被发送到登录页面。 因此，我进行了设置，以便所有用户即使未登录也可以看到此页面。我想要在页面加载或类似操作中执行的操作是检查第 3 方应用程序可以发送的查询字符串参数，并根据 FormsAuthentication 对其进行验证。
当这个第 3 方应用程序发出请求时，用户已经登录，所以我想知道是否可以针对当前登录的用户进行检查，看看它是否与第 3 方请求匹配？
我还需要做的是将登录用户的信息发送到第三方应用程序，以便当它发出请求时它与登录用户匹配。
I have an un-ideal application and without going into the ins and outs this is what is needed.
A 3rd party app needs to make a request to a page which will return data. Because I have Forms Authentication enabled this request always ends up being sent to the login page. I have therefore set it so that all users can see this page even though they are not logged in. What I want to do in the Page Load or similar is to check querystring parameters which the 3rd party app can send and validate it against FormsAuthentication.
When this 3rd party app makes its request a user has already logged on so I was wondering is it possible that I can check something against the currently logged in user to see if it matches the 3rd party request?
What I need to also do is send that information from the logged in user to the 3rd party app so that when it makes its request it matches up with the logged in user.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我可能会对此投反对票，但无论如何我都会回答，因为如果我的一位同事问我这个问题，我会向他们宣读防暴法案。 （我不会向您宣读防暴法案，因为我不对您的系统或数据的安全负责。）
我从您的第一句话中看出，您意识到这可能不是最好的主意，因为它是“不-理想”的应用。
我知道我将要建议的内容会导致重复的代码并增加以后的维护工作，但是当您在这与短路身份验证机制或篡改众所周知且值得信赖的机制以削弱它之间进行权衡时，允许另一个应用程序使用“后门”（这就是您在这里真正谈论的内容 - 为另一个应用程序创建后门，但尝试使用查询字符串参数作为登录机制的一部分），这实际上是较小的有更多的代码和更多的维护有两个弊端。
那么...您是否考虑过，是否有可能为另一个应用程序设置另一种方法来获取数据？ 你说它只是获取数据，那么为什么不建立一个单独的 Web 服务项目或其他合适的项目呢？ 即使是另一个网站应用程序也将是您所提议的更好的解决方案。
即使这些数据不是您所说的“敏感”数据，我仍然认为尝试构建后门是一个坏主意。 对于当前应用程序来说，这可能不是一个关键问题，但不进行安全编码是一种习惯，一旦您在一个区域这样做，您就更有可能在其他地方承担不必要的风险。
I may get down votes for this, but I'm going to answer anyway because if one of my co-workers asked me this question, I would read them the riot act. (I won't read you the riot act because I'm not responsible for your systems or the security of your data.)
I see from your first sentence that you realize this may not be the best idea because it is an "un-ideal" application.
I know that what I'm about to suggest will result in duplicate code and add to maintenance down the road, but when you balance that against short-circuiting the authentication mechanism or tampering with a well-known and trustworthy mechanism to weaken it so as to allow another application to use a "back door" (which is what you're really talking about doing here - creating a back door for this other application but attempting to use querystring parameters as part of the login mechanism) it is really the lesser of two evils to have more code and more to maintain.
So... Have you considered, and is it a possibility for you to set up another method for this other app to get the data? You say that it is just getting data, so why not have a separate web services project or some other project appropriate. Even another web site application would be a better solution to what you're proposing.
Even if this data is not what you would call "Sensitive" I still think trying to build in a back door is a bad idea. It may not be a critical issue on the current application, but not coding for security is a habit, and once you do it in one area, you're more likely to take unnecessary risks elsewhere.