J'exécute une application angulaire sur un hôte virtuel local ( http://foo.app:8000 ). Il adresse une demande à un autre hôte virtuel local ( http://bar.app:8000 ) à l'aide de $http.post
.
$http.post('http://bar.app:8000/mobile/reply', reply, {withCredentials: true});
Dans l'onglet Réseau de Chrome Developer Tools I, consultez bien sûr la requête OPTIONS. La réponse comprend l'en-tête:
Access-Control-Allow-Origin: http://foo.app:8000
Cependant, la demande POST est annulée avec l'erreur suivante:
Aucun en-tête 'Access-Control-Allow-Origin' n'est présent sur la ressource demandée. Origin ' http://foo.app:8000 ' n'est donc pas autorisé à accéder.
Quelqu'un at-il vécu cela? L'en-tête Access-Control-Allow-Origin
est très clairement inclus dans la réponse de la demande OPTIONS. Je ne peux donc pas comprendre pourquoi le POST agit comme si l'en-tête manquait.
Access-Control-Allow-Credentials
est également défini sur true
.
C'est un bug en chrome pour les développeurs locaux. Essayez un autre navigateur. Alors ça va marcher.
Il existe une solution de contournement pour ceux qui souhaitent utiliser Chrome. Cette extension vous permet de demander n'importe quel site avec AJAX à partir de n'importe quelle source, puisqu'il ajoute l'en-tête 'Access-Control-Allow-Origin: *'
à la réponse.
Vous pouvez également ajouter cet argument à votre lanceur Chrome: --disable-web-security
. Notez que je l’utiliserais uniquement à des fins de développement, pas pour la "navigation sur le Web" normale. Pour référence, voir Exécuter Chromium with Flags .
Pour finir, en installant l’extension mentionnée au premier paragraphe, vous pouvez facilement activer/désactiver CORS.
J'envoyais des demandes d'angularjs en utilisant le service $ http à bottle en utilisant http://localhost:8090/
et je devais appliquer CORS sinon, j'ai des erreurs de demande du type "No 'en-tête" présent sur la ressource demandée "
from bottle import hook, route, run, request, abort, response
#https://github.com/defnull/bottle/blob/master/docs/recipes.rst#using-the-hooks-plugin
@hook('after_request')
def enable_cors():
response.headers['Access-Control-Allow-Origin'] = '*'
response.headers['Access-Control-Allow-Methods'] = 'POST, GET, OPTIONS, PUT'
response.headers['Access-Control-Allow-Headers'] = 'Origin, X-Requested-With, Content-Type, Accept'
CROS doit être résolu à partir du serveur.
Créer des filtres selon les exigences pour autoriser l'accès et ajouter des filtres dans web.xml
Exemple utilisant le ressort:
Classe de filtre:
@Component
public class SimpleFilter implements Filter {
@Override
public void init(FilterConfig arg0) throws ServletException {}
@Override
public void doFilter(ServletRequest req, ServletResponse resp,
FilterChain chain) throws IOException, ServletException {
HttpServletResponse response=(HttpServletResponse) resp;
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");
response.setHeader("Access-Control-Max-Age", "3600");
response.setHeader("Access-Control-Allow-Headers", "x-requested-with");
chain.doFilter(req, resp);
}
@Override
public void destroy() {}
}
Web.xml:
<filter>
<filter-name>simpleCORSFilter</filter-name>
<filter-class>
com.abc.web.controller.general.SimpleFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>simpleCORSFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
J'ai vécu exactement le même problème. Pour moi, la requête OPTIONS serait acceptée, mais la requête POST indiquerait "abandonné". Cela m'a amené à penser que le navigateur ne faisait jamais la demande POST. Chrome indiquait quelque chose du type "Attention, les en-têtes provisoires sont affichés" dans les en-têtes de requête, mais aucun en-tête de réponse n'a été affiché. Finalement, je me suis tourné vers le débogage sous Firefox, ce qui m'a amené à découvrir que mon serveur répondait par une erreur et qu'aucun en-tête CORS n'était présent dans la réponse. En réalité, Google Chrome recevait la réponse, mais ne permettait pas l'affichage de la réponse dans la vue du réseau.
Au lieu d'utiliser$ http.get('abc/xyz/getSomething'), essayez d'utiliser $ http.jsonp ('abc/xyz/getSomething')
return{
getList:function(){
return $http.jsonp('http://localhost:8080/getNames');
}
}
Cela peut également arriver lorsque vos paramètres sont incorrects dans la requête. Dans mon cas, je travaillais avec une API qui m'a envoyé le message
"Aucun en-tête 'Access-Control-Allow-Origin' n'est présent sur la ressource demandée. Origin 'null' n'est donc pas un accès autorisé. La réponse avait le code d'état HTTP 401."
lorsque j’envoie un mauvais nom d’utilisateur ou mot de passe avec la demande de connexion POST.
Je viens de rencontrer ce problème aujourd'hui. Il s'est avéré qu'un bogue sur le serveur (exception de pointeur null) entraînait son échec lors de la création d'une réponse, mais il générait toujours un code d'état HTTP de 200. En raison du code d'état 200, Chrome attendait une réponse valide. La première chose que Chrome a faite a été de rechercher l'en-tête "Access-Control-Allow-Origin", qu'il n'a pas trouvé. Chrome a ensuite annulé la demande et Angular m'a renvoyé une erreur. Le bogue lors du traitement de la demande POST est la raison pour laquelle les OPTIONS ont réussi, mais le POST a échoué.
En bref, si vous voyez cette erreur, il se peut que votre serveur n’ait renvoyé aucun en-tête en réponse à la demande POST.
Si vous rencontrez ce problème dans sails.js, configurez simplement cors.js pour inclure l'autorisation en tant qu'en-tête autorisé
/***************************************************************************
* *
* Which headers should be allowed for CORS requests? This is only used in *
* response to preflight requests. *
* *
***************************************************************************/
headers: 'Authorization' // this line here