在 onEnter 路由上使用 auth 函数与使用高阶函数，这两种方法真的安全吗？

Posted 2023-03-07

【中文标题】在 onEnter 路由上使用 auth 函数与使用高阶函数，这两种方法真的安全吗？

【英文标题】：Using an auth function on an onEnter route vs using a high order function and are both methods really secure?

【发布时间】：2017-01-27 05:56:42

【问题描述】：

让我们假设一个系统，其中 jwt 令牌在登录时保存到本地存储，现在我们检查令牌是否存在以允许用户访问受保护的路由。

我们正在使用 react-router-redux 并将所有内容与 webpack 捆绑在一起，我们的代码位于 client/src 文件夹中，与服务器文件夹相对。

因此，经过身份验证检查的受保护路由如下所示（假设我们仅按需发送路由）：

import  push  from 'react-router-redux'

    function requireAuth(store) 
        const check = localStorage.jwt
        check ? store.dispatch(push('/dashboard')) : store.dispatch(push('/'))
    

    export default (store) => (
      path: 'dashboard',
      onEnter: requireAuth(store),
      getComponent (nextState, cb) 
        require.ensure([], (require) => 
          const Dashboard = require('./containers/DashboardContainer').default
          cb(null, Dashboard)
        , 'dashboard')
      
    ) 

为了完成我们的索引路由文件：

    import Login from './login'
    import Dashboard from './Dashboard'
    import Logout from './Logout'

    export const createRoutes = (store) => (
      path: '/',
      indexRoute: Login,
      childRoutes: [
        Dashboard(store), //Our protected route
        Logout(store)
      ]
    )

    export default createRoutes

将辅助人员置于中间攻击和 javascript 加密方法本质的固有问题如下所述： SPA best practices for authentication and session management

我想重点关注上面说明的放置在 onEnter 上以允许访问的函数的方法：

如果我理解正确，上面的示例被捆绑并发送到客户端，现在我可能错了，路由定义实际上并没有在捆绑中发送。 所以我想问题是：默认情况下用户是否可以访问或可以看到我们上面的路由定义 - 如果是，我们如何防止它？

关于我们在示例中的身份验证检查，我已经看到使用它，如果本地存储中不存在令牌，它会简单地重定向，这真的足够预防吗？

将上述示例与使用高阶函数包装我们的受保护组件进行比较，因此我们可以在生命周期方法 WillMount 和 WillRecieveProps 中执行身份验证检查，如您所见 here for example。

我认为这两种方法都会因暴露给客户而受到影响。我说的对吗？

关于每种方法，我还缺少哪些其他注意事项？

【参考方案1】：

在我看来，您不应该将 JWT 令牌存储在 localStorage 中，而应该将其作为带有 h​​ttpOnly 和安全标志的 cookie 保存为 true。这样您的客户端脚本就无法获取您的 JWT 令牌。由于您仅在 https 上发送 cookie，因此中间人攻击也是不可能的。

你可以有一个 api 端点来检查客户端是否有 JWT 以及它是否有效。这样您就可以在任何需要的地方对 onEnter 函数进行重定向。

编辑

如果我理解正确，上面的示例将被捆绑并发送到 客户，现在我可能错了，路线定义实际上不是 在捆绑中发送。所以我想问题是：用户有 默认情况下访问或可以看到我们上面的路由定义 - 如果是这样如何 我们会阻止它吗？

是的，您的整个应用程序正在与您的所有客户端代码一起发送给客户端，因此任何人都可以看到您编写的内容，如果他们愿意的话。

关于我们在示例中的身份验证检查，我已经看到使用过 如果本地存储中不存在令牌，则简单地重定向， 这真的足够预防吗？

不是真的，如果你有一个无效的令牌，你将你的用户重定向到页面，如果这个页面从服务器进行了一些获取，你会得到 401 错误，你必须检查 401 错误，以便你可以重定向用户登录.这似乎并不有效或不清楚。

将上面的示例与使用高阶函数来包装我们的 受保护的组件，所以我们可以在生活中进行身份验证检查 循环方法 WillMount 和 WillRecieveProps 你可以在这里看到 例子。

除了 httpOnly 标志 true cookie 之外，所有这些都暴露给客户端。

希望对你有帮助。

【讨论】：

我认为大多数文章都支持使用 cookie 比 localstorage 更安全的想法，但是在使用 localstorage 的情况下（我现在正在一个非常小的应用程序中处理这样的用例）我想了解我说明的两种方法。

我正在对照数据库检查实际的令牌服务器端，但在客户端我还没有找到一个好的解决方案来解决用户在本地存储中有错误令牌或假令牌的情况，他们现在尝试访问受保护的 api 路由并进行服务器调用。这很令人沮丧，因为不能总是使用 cookie。