Rails, REST Architecture et HTML 5: Demandes interdomaines avec requêtes pré-vol

Question

Tout en travaillant sur un projet visant à rendre notre site HTML 5 convivial, nous étions impatients d'adopter la nouvelle méthode pour les requêtes inter-domaines (plus de publication via hidden iframes !!!). En utilisant la spécification Access Control, nous commençons à mettre en place des tests pour vérifier le comportement de différents navigateurs. L'architecture actuelle de Rails repose sur les quatre verbes HTTP: GET, POST, PUT, DELETE. Cependant, dans la spécification de contrôle d'accès, il impose que les méthodes non simples (PUT, DELETE) requièrent une demande de pré-vol en utilisant le verbe HTTP OPTIONS. En outre, lors des tests, nous avons découvert que Firefox 3.5.8 pré-vol POST demande également.

Ma question est la suivante. Est-ce que quelqu'un est au courant de tout projet pour le cadre de Rails travaillant pour résoudre le problème? Sinon, des avis sur la meilleure stratégie pour supporter la méthode OPTIONS, puisqu'elle doit supporter les routes pour toutes les méthodes POST, PUT, DELETE?

Answer 1

Je publié un petit bijou quelques jours il y a implémentant support CORS via un Middleware Rack:

http://github.com/cyu/rack-cors

En ce qui concerne les demandes de contrôle en amont CORS, je ne pouvais pas recevoir des demandes de contrôle en amont travaillant dans Chrome (par CORS simples les demandes fonctionnent bien). Une recherche autour des Internets suggère qu'il pourrait ne pas être supporté. J'ai posé des questions sur le forum Chrome à ce sujet, mais je n'ai pas encore reçu de réponse.

Answer 2

J'ai piraté les rails pour supporter la méthode des options. Je l'ai posté sur la liste des rails, mais il n'a jamais dépassé la liste.

GitHub Contenu essentiel: Rails XHR2/CORS/OPTIONS support

ctrl + f pour trouver les lignes qui ont #options - ce sont les seuls que je changé.

Et voici an example implementation | and another

Answer 3

Ceci est de la documentation de la colonne vertébrale

Cors d'intégration Rails

Créons une méthode cor, qui ajoutera à la réponse de la demande certains des en-têtes de contrôle d'accès à la demande.

Ajouter ce qui suit à l'application/application_controller.rb:

before_filter :cor 

def cor 
    headers["Access-Control-Allow-Origin"] = "js-app-origin.com" 
    headers["Access-Control-Allow-Methods"] = %w{GET POST PUT DELETE}.join(",") 
    headers["Access-Control-Allow-Headers"] = %w{Origin Accept Content-Type X-Requested-With X-CSRF-Token}.join(",") 
    head(:ok) if request.request_method == "OPTIONS" 
end 

Bien-allow-access-Control Origin prend un caractère générique, je recommande fortement de ne pas utiliser comme il ouvre votre application à toutes sortes de CSRF attaques. L'utilisation d'une liste blanche est bien meilleure et plus sûre.

La section Access-Control-Allow-Headers est importante, en particulier l'en-tête X-Requested-With. Rails ne l'aime pas si vous lui envoyez des requêtes Ajax sans cet en-tête, et ignore l'en-tête Accept de la requête, renvoyant du code HTML alors qu'il devrait renvoyer JSON.

Il est à noter que jQuery n'ajoute pas cet en-tête aux demandes de domaine croisées par défaut. C'est un problème que Spine résout en interne, mais si vous utilisez jQuery simple pour les COR, vous devrez spécifier l'en-tête manuellement.

jQuery.ajaxSetup({ 
    headers: {"X-Requested-With": "XMLHttpRequest"} 
}); 

Certains navigateurs envoient d'abord une requête d'options au serveur pour s'assurer que les en-têtes d'accès corrects sont définis. Vous devrez l'attraper dans Rails, en retournant un statut 200 avec les en-têtes corrects. Pour ce faire, ajoutez ce qui suit à config/routes.rb de votre application:

match '*all' => 'application#cor', :constraints => {:method => 'OPTIONS'} 

C'est, vous êtes tous mis en place pour les demandes Cross Origin avec la colonne vertébrale!