Подтвердить что ты не робот

Node.js: Connect-Auth VS. EveryAuth

Может ли кто-нибудь дать хорошее сравнение между: https://github.com/ciaranj/connect-auth и https://github.com/bnoguchi/everyauth

Кажется, что это единственные варианты express/connect

4b9b3361

ОТВЕТЫ

Ответ 1

Обе библиотеки довольно близки в наборах функций, особенно в отношении поддерживаемых поставщиков. connect-auth предоставляет поддержку из коробки, чтобы сделать ваши собственные провайдеры oAuth, так что это может помочь вам, если вам понадобится такая штука.

Главное, что я заметил между двумя, заключается в том, что я нахожу connect-auth намного более чистым с тем, как он создает и принимает промежуточное ПО; вам нужно только посмотреть, какая предварительная настройка требуется для промежуточного программного обеспечения в everyauth, чтобы увидеть, что он будет запутан.

Еще одна вещь, которая неясно, заключается в том, поддерживает ли everyauth несколько поставщиков одновременно; с connect-auth, это кажется возможным/более простым, хотя Ive еще не попробовать это сам.

Ответ 2

Я автор everyauth.

Я написал everyauth, потому что нашел connect-auth с отсутствием в терминах:

  • Простая и мощная конфигурация

    Чтобы получить конкретную информацию, в одной области, где она отсутствовала с точки зрения конфигурируемости, динамически устанавливались параметры безопасности "scope" в facebook.

  • Хорошая поддержка отладки

    Я обнаружил, что connect-auth не так просто отлаживается с точки зрения точного определения части процесса auth. Это в основном связано с тем, как connect-auth устанавливает свои вложенные обратные вызовы.

С everyauth я попытался создать систему, которая решила проблемы, с которыми я столкнулся, с помощью connect-auth.

  • В конфигурации - каждый модуль autauth auth определяется как последовательность шагов и настраиваемых параметров. В результате у вас есть хирургическая точность по сравнению с параметрами (например, имя хоста, URL-адрес обратного вызова и т.д.) Или шаги (например, getAccessToken, addToSession), которые вы хотите изменить. Если connect-auth, если вы хотите изменить одну вещь, кроме нескольких встроенных настраиваемых параметров, которые предоставляет каждая стратегия auth, вам нужно переписать всю функцию this.authenticate, которая определяет логику для всей этой стратегии. Другими словами, он имеет меньшую точность конфигурации, чем everyauth. В других случаях вы не можете использовать connect-auth, а также, например, добиться возможности динамической "видимости" "facebook", т.е. Запрашивать у пользователей больше прав на facebook, поскольку они попадают в части вашего приложения, для которых требуется больше разрешений.

    В дополнение к настраиваемым шагам и параметрам вы также можете воспользоваться наследованием модуля everyauth auth. Все модули наследуют прототипно от модуля authmodule auth. Все модули на основе OAuth2 наследуются от модуля oauth2. Скажем, вы хотите, чтобы все модули oauth2 вели себя по-другому. Все, что вам нужно сделать, это модифицировать модуль autauto2, и все модули на основе oauth2 наследуют это новое поведение от него.

  • При отладке - everyauth, на мой взгляд, улучшена видимость отладки из-за того факта, что он явно разбивает каждый модуль на этапы его составления. Установив

    everyauth.debug = true;

    вы получаете информацию о том, какие шаги в процессе аутентификации завершены и какие из них не удались. У вас также есть подробный контроль за тем, как долго каждый шаг в каждой стратегии auth до истечения времени.

  • О расширяемости. Я разработал все, чтобы максимизировать повторное использование кода. Как уже упоминалось ранее, все модули наследуют прототипно из модуля authmodule auth. Это означает, что вы можете создавать очень модульные системы и в то же время иметь мелкозернистый контроль с точки зрения превышения определенного шага от модуля предка. Чтобы понять, насколько легко расширять каждый из них с помощью собственного модуля auth, просто взгляните на любой из определенных модулей auth в каждом источнике.

  • По читаемости. Я считаю, что everyauth источник легче читать с точки зрения того, что происходит. С помощью connect-auth я обнаружил, что перескакиваю несколько файлов, чтобы понять, в каких контекстах (т.е. Во время каких шагов в everyauth parlance) выполнялся каждый вложенный обратный вызов, сконфигурированный с помощью стратегии. С everyauth вы точно знаете, какая часть логики связана с каким контекстом (aka step). Например, вот код, описывающий, что происходит, когда поставщик oauth2 перенаправляет обратно на вашу службу:

    .get('callbackPath',                                                                                                                                               
     'the callback path that the 3rd party OAuth provider redirects to after an OAuth authorization result - e.g., "/auth/facebook/callback"')                     
  .step('getCode')
    .description('retrieves a verifier code from the url query')                                                                                                   
    .accepts('req res')  
    .promises('code')                                                       
    .canBreakTo('authCallbackErrorSteps')
  .step('getAccessToken')
    .accepts('code')
    .promises('accessToken extra')                                                                                                                                 
  .step('fetchOAuthUser')
    .accepts('accessToken')                                                                                                                                        
    .promises('oauthUser')
  .step('getSession')
    .accepts('req')
    .promises('session')
  .step('findOrCreateUser')                                                                                                                                        
    .accepts('session accessToken extra oauthUser')                                                                                                                
    .promises('user')
  .step('compile')
    .accepts('accessToken extra oauthUser user')
    .promises('auth')
  .step('addToSession')
    .accepts('session auth')                                                                                                                                       
    .promises(null)
  .step('sendResponse')
    .accepts('res')
    .promises(null)

    Не нужно объяснять, как это работает, довольно просто понять, что делает стратегия oauth2. Хотите знать, что делает getCode? Источник снова очень прост:

    .getCode( function (req, res) {
  var parsedUrl = url.parse(req.url, true);
  if (this._authCallbackDidErr(req)) {
    return this.breakTo('authCallbackErrorSteps', req, res);
  }
  return parsedUrl.query && parsedUrl.query.code;
})

    Сравните это все с connect-auth кодом facebook, который, по крайней мере, для меня занял больше времени, чем я думал, что ему нужно выяснить, что происходит, когда он выполняется. Это происходит главным образом из-за того, как код распространяется по файлам и из-за использования одного метода authenticate и вложенных обратных вызовов для определения логики аутентификации (everyauth использует promises, чтобы разбить логику на легко усваиваемую шаги):

    that.authenticate= function(request, response, callback) {
  //todo: makw the call timeout ....
  var parsedUrl= url.parse(request.url, true);
  var self= this;
  if( parsedUrl.query && parsedUrl.query.code  ) {
    my._oAuth.getOAuthAccessToken(parsedUrl.query && parsedUrl.query.code ,
       {redirect_uri: my._redirectUri}, function( error, access_token, refresh_token ){
         if( error ) callback(error)
         else {
           request.session["access_token"]= access_token;
           if( refresh_token ) request.session["refresh_token"]= refresh_token;
             my._oAuth.getProtectedResource("https://graph.facebook.com/me", request.session["access_token"], function (error, data, response) {
               if( error ) {
                 self.fail(callback);
               }else {
                 self.success(JSON.parse(data), callback)
               }
             })
         }
    });
  }
  else {
     request.session['facebook_redirect_url']= request.url;
     var redirectUrl= my._oAuth.getAuthorizeUrl({redirect_uri : my._redirectUri, scope: my.scope })
     self.redirect(response, redirectUrl, callback);
   }
}

Несколько других различий:

  • everyauth поддерживает традиционную аутентификацию на основе пароля. connect-auth, начиная с этой записи, нет.
  • Поддержка foursquare и google в connect-auth основана на более старой спецификации OAuth1.a. everyauth модули foursquare и google основаны на их реализациях новой спецификации OAuth2.
  • Поддержка OpenId в everyauth.
  • Документация everyauth намного более полная, чем connect-auth.

Наконец, чтобы прокомментировать ответ Nathan, который не знал о поддержке everyauth для нескольких поставщиков одновременно, everyauth поддерживает несколько параллельных провайдеров. Страница README на странице everyauth github содержит инструкции по использованию everyauth для достижения этой цели.

В заключение я считаю, что выбор библиотек зависит от разработчика. Я и другие, нахожу everyauth более мощными с их точки зрения. Как наглядно показывает Натан, другие считают, что connect-auth больше настроены на свои предпочтения. Независимо от вашего выбора, я надеюсь, что эта рецензия о том, почему я написал everyauth, поможет вам в вашем решении.

Ответ 3

Думаю, я бы упомянул, что теперь в городе появился новый игрок под названием PassportJS, который имеет много преимуществ, таких как everyauth, однако провайдеры аутентификации предоставляются модулями npm - так что optin, а не включать все.

Ответ 4

Я провел утро, играя с everyauth и mongoose-auth, чтобы найти примеры, которые были сломаны, и они были мертвыми проектами. Вот история фиксации:

https://github.com/jaredhanson/passport/commits/master - 5 июня (это 18 июня) https://github.com/ciaranj/connect-auth/commits/master - 18 апреля (2 месяца назад) https://github.com/bnoguchi/mongoose-auth/commits/master - февраль 2012

Здесь google Trends of everyauth, connect-auth и passportjs http://www.google.com/trends/explore?q=passportjs%2C+connect-auth%2C+everyauth#q=passportjs%2C%20connect-auth%2C%20everyauth&cmpt=q

Ответ 5

Мой опыт с каждым:

everyauth гораздо более настраивается. Например, я хочу обрабатывать свои собственные сеансы. С everyauth, с его модулярностью и самоанализом, является прямой задачей. С другой стороны, они нашли everyauth, заполненный незначительными ошибками и неполной и/или неправильной документацией. Для меня каждая стратегия аутентификации требует своего понимания и устранения неполадок.

passport может быть хорошей ставкой, если вы все делаете "по книге". Но любое отклонение может сделать жизнь очень трудной очень быстро, сделав ее для меня не стартером.