【问题标题】:Authentication Logic - Server vs Client身份验证逻辑 - 服务器与客户端
【发布时间】:2016-02-18 09:14:38
【问题描述】:

我试图弄清楚身份验证逻辑应该存在于我的应用程序中的哪个位置,我试图采取的方法是让服务器处理任何身份验证责任,重定向到与主客户端分开的登录页面侧应用程序 - 我认为这是明智的?

我有一个 angularjs 应用程序,它使用 ui-router 并发出通过服务器路由的 api 请求。

我正在使用配置为使用几个目录的 Express 服务器,如下所示:

app.use(express.static('./dist/client'));
app.use(express.static('public'));

然后我有中间件来执行身份验证检查(我也使用 express-session)并在需要时重定向到登录。

//A request to '/login' will serve the login page
app.use('/login', function(req, res){
  res.sendFile(path.join(__dirname+'/public/login.html'))
});

//This will listen for all requests
app.use(function(req, res, next) {
  if (req.url!== '/auth/login' && !req.session.accessToken) {
    res.redirect('/login');
    return;
  }
  next();
});

在初始页面加载时,当不存在会话 cookie 时,express 立即按预期重定向到登录视图。

登录并加载主应用程序后,如果我随后手动删除浏览器中的 cookie 并执行需要 api 请求的状态更改(在状态解析中),服务器将返回登录视图,但这会在内部呈现ui-router 正在使用 ui-view 组件,而不是服务器完全重定向到 /login

另外,如果我导航到一个不执行 api 请求的页面(在删除 cookie 之后),该页面会被返回,我猜它没有被我的执行重定向的 app.use 中间件覆盖。

我觉得我在这里遗漏了一些明显的东西,有人可以帮我吗?

【问题讨论】:

    标签: angularjs express angular-ui-router


    【解决方案1】:

    一种处理方法,还有其他方法:

    如果用户未通过身份验证,则使 API 服务器返回 401(未经授权)错误,而不是将他们重定向到登录页面。

    然后,在运行块中,将$stateChangeError 事件处理程序添加到$rootScope。这样,如果 API 请求来自未经身份验证的用户,它将触发事件处理程序。从那里您可以将用户重定向到您的登录页面:

    angular.module('myApp').run(function($rootScope, $window) {
      $rootScope.$on('$stateChangeError', function() {
        $window.location.href = '/login';
      });
    });
    

    我不确定担心删除 cookie 并导航到不发出任何 API 请求的页面的其他情况是否有意义。这样的用户将获得什么?在这个假设场景中,他们已经在查看您应用中的页面(可能包含或不包含敏感数据)。他们是如何开始的?

    您可以对$stateChangeStart 事件使用类似的事件处理程序,检查cookie 的存在并在丢失时重定向。但是,您不想在客户端中放入验证 cookie 的代码,b/c 然后任何好奇的访问者都可以阅读该代码并学习如何创建 cookie 来欺骗您的服务器。

    【讨论】:

    • 谢谢@Sunil,我已经尝试过了,现在正在从服务器返回 401,我在浏览器控制台中看到了,但是 $stateChangeError 没有为我触发。但是,我可以在 httpResponseInterceptor 中捕获错误。任何想法为什么 401 没有被 $stateChangeError 拾取?
    • 我也在我的路线上使用解析,并且这些解析从我的快速应用程序中抛出 401,所以我会认为这些会导致 stateChangeError 处理程序触发?
    • @mindparse 我使用相同的技术 w/resolves 和 $stateChangeError 处理程序,所以我可以确认它应该工作。我不确定有什么问题。我认为 HTTP 拦截器方法也很好。
    猜你喜欢
    • 2012-08-28
    • 2011-11-04
    • 1970-01-01
    • 1970-01-01
    • 2012-04-15
    • 1970-01-01
    • 2014-01-04
    • 2016-07-25
    • 2013-06-18
    相关资源
    最近更新 更多