我认为你所要求的并不是直接可以实现的,但是你可以接近实现这个目标。我不会在这里提供任何代码,因为这可能会变得复杂,但我希望可以帮助你思考问题。像@jeremy-lakeman所说,这是一个"反功能",也许你可以重新定义问题。
Windows身份验证
当服务器返回401时,Windows将自动通过kerberos进行身份验证。对于用户来说,这是透明的,没有登录页面。在您的情况下,这由IIS处理。使用Windows身份验证时,不应显示登录页面。
Cookie身份验证
基本上,这是在浏览器上存储用于验证用户的cookie。Asp.Net Core 3.1包含此功能,并且可以轻松支持此功能。该cookie在应用程序级别进行验证。此cookie可以有一个过期时间,并且您可以在页面中嵌入登录表单。在创建新项目时,这是“Individual Accounts”选项。
两者的混合
想象一下以下的世界:
您有两个应用程序。您的主要应用程序配置为Cookie身份验证(我们将其称为"Primary"),而辅助应用程序配置为使用Windows身份验证(称为"Secondary")。您还可以使用IIS并为一个特定路径放置Windows身份验证,但将其视为两个独立的应用程序更容易理解。
当您向Primary发出请求时,您的应用程序会验证cookie。如果不存在cookie或其被拒绝(因为超时),则会将您重定向到Secondary(不是401未经授权,而是302找到),它只进行Windows身份验证。它可以重新生成cookie,然后将您发送回Primary。
但是这不会显示登录页面,我认为这是问题的核心。您想在同一个应用程序中同时拥有自动登录和手动登录。如果您拥有自动登录,过期时间有什么用?他们只会刷新并再次获得身份验证。
如果您放弃自动登录(通过Windows身份验证),则可以仅使用一个具有Cookie身份验证的应用程序。
仅限Cookie
在这种情况下,您仅设置了Primary,并且它只进行cookie身份验证。您可以拥有针对Active Directory进行身份验证的标识提供程序。这是Windows身份验证,但在应用程序级别而不是在IIS级别。
你必须选择自动登录或超时之间。在没有合理的世界中,您不能两者兼备。
fetch
)每隔几分钟发送请求,以保持用户的身份验证令牌有效 - 但我承认我不确定这如何与 Kerberos/NTML 协作。 - Dai