是否存在 WsFederationAuthenticationOptions WReply 和 CallbackPath 值可能不匹配的情况？
Is there a situation when WsFederationAuthenticationOptions WReply and CallbackPath values may not match?
当使用 ASP.Net OWIN/Katana 使用 WSFederation 设置单点登录时，存在 WReply 和 CallbackPath 属性。
在示例项目中，这些值在 Startup.Auth 中配置时看起来非常相似，例如：
new WsFederationAuthenticationOptions() {
CallbackPath = "/WsFed-Foo",
Wreply = "https://example.com/WsFed-Foo"
查看文档，我看到了这个：
CallbackPath must be set to match or cleared so it can be generated
dynamically. This field is optional. If not set then it will be
generated from the current request and the CallbackPath.
我明白 CallbackPath 是可选的，但如果它需要匹配 WReply，那么为什么 Katana 会在自动计算时具有它（如果省略）？有没有和WReply不一样的情况？
也许 Tratcher 在 Github (https://github.com/aspnet/Security/issues/1645) 中发布的内容回答了您的问题？
以防万一，他对“WsFed Wreply 和 CallbackPath #1645 之间的混淆”问题的回复是：
When WsFed was ported from Katana it was translation with modest
updates, most of the original design and options were preserved.
Justin noticed in testing that the modified relationship between
CallbackPath and Wreply is confusing and may cause infinite login
loops for our customers. Wreply sets the address the identity
provider returns to. CallbackPath sets the path the middleware listens
on for the reply.
In Katana users could opt to set Wreply and CallbackPath would be
derived from that. Neither had a default and if it wasn't set then the
middleware would read all form-post requests.
In Core CallbackPath defaults to /signin-wsfed like our other handlers
and Wreply has no value. Challenges generate a wreply from the
CallbackPath. The confusion comes if someone sets wreply without
updating or clearing CallbackPath. The server will reply to a path
that the handler isn't listening on, likely resulting in an infinite
auth loop or 404.
The motivation for making wreply a public option on WsFed rather than generating the redirect like other providers was that WsFed
identity servers were known to be extremely strict on matching the
value, to the point of requiring exact casing, etc.. Generating the
url from user input may not be sufficient for this check. It's
unclear how many customers have run into this mismatch vs those that
set wreply because they saw it in a sample.
Not sure what the best path forward here is. We'll see how many users
run into it.
我在我认为可以回答您的第一个问题的内容中添加了重点。关于你的第二个问题，似乎没有 Wreply 和 CallbackPath 不兼容的情况。 （从技术上讲，它们总是不同的，因为 CallbackPath - 不像 Wreply - 不是完整的 URL。）
当使用 ASP.Net OWIN/Katana 使用 WSFederation 设置单点登录时，存在 WReply 和 CallbackPath 属性。
在示例项目中，这些值在 Startup.Auth 中配置时看起来非常相似，例如：
new WsFederationAuthenticationOptions() {
CallbackPath = "/WsFed-Foo",
Wreply = "https://example.com/WsFed-Foo"
查看文档，我看到了这个：
CallbackPath must be set to match or cleared so it can be generated dynamically. This field is optional. If not set then it will be generated from the current request and the CallbackPath.
我明白 CallbackPath 是可选的，但如果它需要匹配 WReply，那么为什么 Katana 会在自动计算时具有它（如果省略）？有没有和WReply不一样的情况？
也许 Tratcher 在 Github (https://github.com/aspnet/Security/issues/1645) 中发布的内容回答了您的问题？
以防万一，他对“WsFed Wreply 和 CallbackPath #1645 之间的混淆”问题的回复是：
When WsFed was ported from Katana it was translation with modest updates, most of the original design and options were preserved. Justin noticed in testing that the modified relationship between CallbackPath and Wreply is confusing and may cause infinite login loops for our customers. Wreply sets the address the identity provider returns to. CallbackPath sets the path the middleware listens on for the reply.
In Katana users could opt to set Wreply and CallbackPath would be derived from that. Neither had a default and if it wasn't set then the middleware would read all form-post requests.
In Core CallbackPath defaults to /signin-wsfed like our other handlers and Wreply has no value. Challenges generate a wreply from the CallbackPath. The confusion comes if someone sets wreply without updating or clearing CallbackPath. The server will reply to a path that the handler isn't listening on, likely resulting in an infinite auth loop or 404.
The motivation for making wreply a public option on WsFed rather than generating the redirect like other providers was that WsFed identity servers were known to be extremely strict on matching the value, to the point of requiring exact casing, etc.. Generating the url from user input may not be sufficient for this check. It's unclear how many customers have run into this mismatch vs those that set wreply because they saw it in a sample.
Not sure what the best path forward here is. We'll see how many users run into it.
我在我认为可以回答您的第一个问题的内容中添加了重点。关于你的第二个问题，似乎没有 Wreply 和 CallbackPath 不兼容的情况。 （从技术上讲，它们总是不同的，因为 CallbackPath - 不像 Wreply - 不是完整的 URL。）