永远不会有单独的登录路线
永远不会有单独的登录路线
在 Web 应用程序中，保护屏幕以进行身份验证时有两种选择：
- 如果用户未通过身份验证，则重定向到
/登入路线：
2. 如果用户未通过身份验证，请在尝试页面的 URL 处显示登录表单，而不进行重定向，并且没有单独的路由：
前一种方法在早期的 Web 中使用，因为当时页面是不可变的，并且仅仅因为它有一个表单而不是其他内容，就有一个单独的页面 URL 感觉很自然。
要设置此类重定向，您需要在没有身份验证检查的情况下创建页面，并将该检查提取到在路由阶段调用的某种保护。他们确保仅在用户通过身份验证时才显示目标页面。
/sign-in 路由的问题
1.没有语义的页面
一个经验法则是，如果人们想要添加书签、重新访问和共享某个页面，那么就拥有一个带有 URL 的页面。谁愿意分享 /登入 网址？
2.需要重定向回来
用户通过身份验证后，必须将他们重定向到他们想要的页面。这意味着此类 URL 必须以以下形式传递到登录页面 ?back=/个人资料
这增加了许多错误或缺少返回 URL 的管理和特殊情况。
它在地址栏中看起来很乱。
3. 浏览器历史记录中的一个条目
如果用户点击了 /轮廓 链接，被重定向到 /登入？… 然后回到 /轮廓 ，这是浏览器历史记录中的三个条目。
如果他们点击“返回”，他们希望进入他们点击个人资料链接的页面。相反，他们回到 /登入？… 将它们再次重定向到 /轮廓 只是因为它们经过身份验证。
2000 年代初期的用户被训练双击“返回”按钮来逃避那些恶意的登录重定向，但这并不是我们希望人们养成的有用习惯。
4. 仍然是匿名查看路线的案例
在现代 Web 应用程序中，您在内存中的前端有一堆页面。您可能有以下堆栈：
/ → /轮廓 → /个人资料/编辑
现在想象用户在 /个人资料/编辑 通过超时。
您可以将它们重定向到 /登入 ，但你仍然有 /轮廓 在堆栈中。该页面处于非活动状态并且不会重建，但它仍然有一些状态，可能有延迟代码执行，并且会在前台页面弹出时显示。无论如何，必须设计小部件，以便可以随时任意频繁地进行重建。
您可以设置弹出所有需要身份验证的页面的警卫，但这会损害用户体验。如果他们再次登录，他们的页面堆栈将丢失。
因此，即使您设置了一些访问保护来提取一些身份验证检查，您也无法让您的页面完全摆脱这些检查。
设置就地登录表单
因此，您不应该有专用的登录 URL。相反，您会在任何需要身份验证的 URL 上显示登录表单。
您设置它的方式取决于您的框架。
对于后端应用程序，通常有某种服务器重定向不会导致实际的 HTTP 重定向，而只会在内部将请求路由到另一个处理程序。
对于 Flutter 应用程序，我通常会执行以下操作：
- 设置一个块或任何其他业务逻辑对象，作为应用程序中身份验证状态的真实来源。
- 做一些
AuthenticatedOrNotWidget有两个构建器：一个用于经过身份验证的案例，一个用于未经过身份验证的案例。此小部件侦听身份验证块并在身份验证数据更改时重建。如果用户退出，则堆栈中每个屏幕的未经身份验证的构建器将接管。如果用户重新登录，将再次回调经过身份验证的构建器。作为奖励，如果用户配置文件中的某些内容发生了变化，这个小部件会自动重建。 - 如果屏幕由块或更改通知器支持，则让它们继承一些知道身份验证的超类，并且只有在身份验证正常时才调用它们的业务方法。此架构是特定于应用程序的。
这是我的一个项目中的小部件：
这是第一个之上的一个更方便的小部件，只有目标页面的构建器：
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
