Rails CSRF Protection + Angular.js: Mit protected_from_forgery kann ich mich bei POST abmelden

Wenn die protect_from_forgeryOption in application_controller erwähnt wird, kann ich mich anmelden und alle GET-Anforderungen ausführen. Bei der ersten POST-Anforderung setzt Rails jedoch die Sitzung zurück, wodurch ich abgemeldet werde.

Ich habe die protect_from_forgeryOption vorübergehend deaktiviert, möchte sie aber mit Angular.js verwenden. Gibt es eine Möglichkeit, das zu tun?

Ich denke, das Lesen des CSRF-Werts aus DOM ist keine gute Lösung, sondern nur eine Problemumgehung.

Hier ist ein Dokument auf der offiziellen Website von angleJS http://docs.angularjs.org/api/ng.$http :

Da nur JavaScript, das auf Ihrer Domain ausgeführt wird, das Cookie lesen kann, kann Ihr Server sicher sein, dass das XHR von JavaScript stammt, das auf Ihrer Domain ausgeführt wird.

Um dies zu nutzen (CSRF-Schutz), muss Ihr Server bei der ersten HTTP-GET-Anforderung ein Token in einem JavaScript-lesbaren Sitzungscookie namens XSRF-TOKEN setzen. Bei nachfolgenden Nicht-GET-Anforderungen kann der Server überprüfen, ob das Cookie mit dem X-XSRF-TOKEN-HTTP-Header übereinstimmt

Hier ist meine Lösung basierend auf diesen Anweisungen:

Setzen Sie zuerst den Cookie:

# app/controllers/application_controller.rb

# Turn on request forgery protection
protect_from_forgery

after_action :set_csrf_cookie

def set_csrf_cookie
  cookies['XSRF-TOKEN'] = form_authenticity_token if protect_against_forgery?
end

Dann sollten wir das Token bei jeder Nicht-GET-Anforderung überprüfen.
Da Rails bereits mit der ähnlichen Methode erstellt hat, können wir sie einfach überschreiben, um unsere Logik anzuhängen:

# app/controllers/application_controller.rb

protected
  
  # In Rails 4.2 and above
  def verified_request?
    super || valid_authenticity_token?(session, request.headers['X-XSRF-TOKEN'])
  end

  # In Rails 4.1 and below
  def verified_request?
    super || form_authenticity_token == request.headers['X-XSRF-TOKEN']
  end

Wenn Sie den Standard-Rails-CSRF-Schutz ( <%= csrf_meta_tags %>) verwenden, können Sie Ihr Angular-Modul folgendermaßen konfigurieren:

myAngularApp.config ["$httpProvider", ($httpProvider) ->
  $httpProvider.defaults.headers.common['X-CSRF-Token'] = $('meta[name=csrf-token]').attr('content')
]

Oder wenn Sie kein CoffeeScript verwenden (was!?):

myAngularApp.config([
  "$httpProvider", function($httpProvider) {
    $httpProvider.defaults.headers.common['X-CSRF-Token'] = $('meta[name=csrf-token]').attr('content');
  }
]);

Wenn Sie möchten, können Sie den Header nur bei Nicht-GET-Anforderungen mit den folgenden Angaben senden:

myAngularApp.config ["$httpProvider", ($httpProvider) ->
  csrfToken = $('meta[name=csrf-token]').attr('content')
  $httpProvider.defaults.headers.post['X-CSRF-Token'] = csrfToken
  $httpProvider.defaults.headers.put['X-CSRF-Token'] = csrfToken
  $httpProvider.defaults.headers.patch['X-CSRF-Token'] = csrfToken
  $httpProvider.defaults.headers.delete['X-CSRF-Token'] = csrfToken
]

Lesen Sie auch unbedingt die Antwort von HungYuHei , die alle Grundlagen auf dem Server und nicht auf dem Client abdeckt.

Das Juwel angular_rails_csrf fügt allen Ihren Controllern automatisch Unterstützung für das in der Antwort von HungYuHei beschriebene Muster hinzu :

# Gemfile
gem 'angular_rails_csrf'

Die Antwort, die alle vorherigen Antworten zusammenführt und davon abhängt, dass Sie das DeviseAuthentifizierungsjuwel verwenden.

Fügen Sie zunächst den Edelstein hinzu:

gem 'angular_rails_csrf'

Fügen Sie als Nächstes einen rescue_fromBlock in application_controller.rb hinzu:

protect_from_forgery with: :exception

rescue_from ActionController::InvalidAuthenticityToken do |exception|
  cookies['XSRF-TOKEN'] = form_authenticity_token if protect_against_forgery?
  render text: 'Invalid authenticity token', status: :unprocessable_entity
end

Und zum Schluss fügen Sie das Interceptor-Modul zu Ihrer Winkel-App hinzu.

# coffee script
app.factory 'csrfInterceptor', ['$q', '$injector', ($q, $injector) ->
  responseError: (rejection) ->
    if rejection.status == 422 && rejection.data == 'Invalid authenticity token'
        deferred = $q.defer()

        successCallback = (resp) ->
          deferred.resolve(resp)
        errorCallback = (resp) ->
          deferred.reject(resp)

        $http = $http || $injector.get('$http')
        $http(rejection.config).then(successCallback, errorCallback)
        return deferred.promise

    $q.reject(rejection)
]

app.config ($httpProvider) ->
  $httpProvider.interceptors.unshift('csrfInterceptor')

Ich sah die anderen Antworten und fand sie großartig und gut durchdacht. Ich habe meine Rails-App mit einer meiner Meinung nach einfacheren Lösung zum Laufen gebracht, also dachte ich, ich würde sie teilen. Meine Rails-App wurde mit dieser Standardeinstellung geliefert.

class ApplicationController < ActionController::Base
  # Prevent CSRF attacks by raising an exception.
  # For APIs, you may want to use :null_session instead.
  protect_from_forgery with: :exception
end

Ich habe die Kommentare gelesen und es schien so, als ob ich Angular verwenden und den CSRF-Fehler vermeiden möchte. Ich habe es geändert,

class ApplicationController < ActionController::Base
  # Prevent CSRF attacks by raising an exception.
  # For APIs, you may want to use :null_session instead.
  protect_from_forgery with: :null_session
end

Und jetzt funktioniert es! Ich sehe keinen Grund, warum dies nicht funktionieren sollte, aber ich würde gerne Einblicke von anderen Postern erhalten.

Ich habe den Inhalt der Antwort von HungYuHei in meiner Bewerbung verwendet. Ich stellte jedoch fest, dass ich einige zusätzliche Probleme hatte, einige aufgrund der Verwendung von Devise zur Authentifizierung und einige aufgrund der Standardeinstellungen, die ich mit meiner Anwendung erhalten habe:

protect_from_forgery with: :exception

Ich notiere die zugehörige Frage zum Stapelüberlauf und die Antworten dort und habe einen viel ausführlicheren Blog-Beitrag geschrieben , in dem die verschiedenen Überlegungen zusammengefasst sind. Die Teile dieser Lösung, die hier relevant sind, sind im Anwendungscontroller:

  protect_from_forgery with: :exception

  after_filter :set_csrf_cookie_for_ng

  def set_csrf_cookie_for_ng
    cookies['XSRF-TOKEN'] = form_authenticity_token if protect_against_forgery?
  end

  rescue_from ActionController::InvalidAuthenticityToken do |exception|
    cookies['XSRF-TOKEN'] = form_authenticity_token if protect_against_forgery?
    render :error => 'Invalid authenticity token', {:status => :unprocessable_entity} 
  end

protected
  def verified_request?
    super || form_authenticity_token == request.headers['X-XSRF-TOKEN']
  end

Ich habe einen sehr schnellen Hack dazu gefunden. Ich musste nur Folgendes tun:

ein. Meiner Ansicht nach initialisiere ich eine $scopeVariable, die das Token enthält, beispielsweise vor dem Formular, oder noch besser bei der Controller-Initialisierung:

<div ng-controller="MyCtrl" ng-init="authenticity_token = '<%= form_authenticity_token %>'">

b. In meinem AngularJS-Controller füge ich vor dem Speichern meines neuen Eintrags das Token dem Hash hinzu:

$scope.addEntry = ->
    $scope.newEntry.authenticity_token = $scope.authenticity_token 
    entry = Entry.save($scope.newEntry)
    $scope.entries.push(entry)
    $scope.newEntry = {}

Es muss nichts mehr getan werden.

 angular
  .module('corsInterceptor', ['ngCookies'])
  .factory(
    'corsInterceptor',
    function ($cookies) {
      return {
        request: function(config) {
          config.headers["X-XSRF-TOKEN"] = $cookies.get('XSRF-TOKEN');
          return config;
        }
      };
    }
  );

Es funktioniert auf eckiger Seite!