0
votes

ASP.NET CORE API API Les en-têtes non à la place attendue

J'ai une API d'ASP.NET CORE qui ajoute deux en-têtes à sa réponse callback_uri et redirect_uri .

La chose étrange (pour moi) est que dans mon Ajax Appelez au service, les en-têtes font partie des données JSON, en tant que tableau des en-têtes, plutôt que la requête Demander . Je ne peux pas utiliser jQxhr.getresponseheader (...) et doit donc interroger manuellement le tableau des en-têtes manuellement dans les données de réponse.

car le code est également une partie des données Cela signifie que mon rappel de réussite Ajax est toujours appelé, même lorsque je teste une réponse de 400 mauvaises réponses, ce qui rend les tests moins simples.

Contrôleur d'API Web: xxx

code AJAX: xxx

suis-je en train de faire quelque chose de mal sur le serveur -Side?


2 commentaires

Puissiez-vous montrer le code d'appel AJAX?


Je l'ai laissé parce que c'est si trivial, mais je vais l'ajouter.


3 Réponses :


0
votes

ajoutez des en-têtes comme ceci: (OFC change le type si nécessaire ou définissez le vôtre)

intervention.Content.Contenttype = nouveau MediatypeHervalue ("Texte / plaine");


0 commentaires

1
votes

Vous pouvez utiliser une combinaison de RésultatFilters et Servicefilterattribute pour ajouter vos en-têtes personnalisés. Ceci est particulièrement utile car:

  1. ServiceFilter Code> vous permet d'avoir un accès di dans votre résultatFilter. li>
  2. Vous pouvez l'appliquer comme un attribut code> dans les actions que vous souhaitez li>
  3. Vous pouvez le tester. LI> ol>

    Mettre tous ensemble: P>

    1. Créer la classe de filtres de résultat personnalisée li> ol> xxx pré>
      1. Enregistrez-le dans votre startup.configureservices CODE> LI> ol> xxx pré>
        1. Appliquez l'attribut dans l'action que vous souhaitez renvoyer les en-têtes personnalisés li> OL>
          <script>
          
              var settings = { method: "GET" };
          
              $.ajax('http://localhost:61284/api/values/test', settings)
                  .done(function (data, textStatus, xhr) {
                      alert(xhr.getResponseHeader('my-header'));
                  })
                  .fail(function () {
                      alert("error");
                  });
          
          </script>
          


5 commentaires

J'ai délibérément découplé de l'utilisation du pipeline de demande puisqu'il effectue des tests unitaires très difficiles.


Bien sûr, je te comprends. C'était juste un exemple rapide, mais la même chose peut être réalisée en créant un middleware. Quelque chose comme ça peut vous aider à commencer. andrewlock.net/adding-default-security-headers-in -Ap-Net-CO RE ou filtres d'action: docs.microsoft.com/en-us/aspnet/core/mvc/controls/...


@Lee Vous faites probablement une demande de Cors, non? Si tel est le cas, n'oubliez pas que vous devez ajouter le Access-Control-exose-têtes , sinon, vous ne pouvez pas lire vos en-têtes personnalisés à l'aide de xhr.getresponseheer


J'ai l'interface utilisateur et les services tout sous le même site de IIS, alors malheureusement, je ne pense pas que ce soit le problème. Je suppose que c'est juste la façon dont les poignées Web API 2 HTTPRESPONSEMESSAGE


Eh bien .. c'est étrange et il est difficile de dire grand chose sans le voir. Je mette à jour ma réponse avec une meilleure approche et je viens de tester et ça marche comme un charme. Donnez-lui une course et voyez si fonctionne (essayez d'habiliter Cors ..)



0
votes

Ce que vous faites est de créer un objet httpresponsemessage , sérialisant-le à JSON puis de le renvoyer.
C'est pourquoi les en-têtes sont dans le contenu JSON, au lieu de la réponse HTTP.

Qu'est-ce que vous pouvez faire, c'est quelque chose comme ça: xxx


2 commentaires

J'ai fait le choix de ne pas compter sur réponse afin que je puisse tester beaucoup plus facilement. Je sais que c'est être sérialisé comme Json comme je peux le voir dans le réseau de navigateur Sniffer. Je pense que les filtres pourraient être la seule voie à suivre, comme Jpgrassi l'a mentionné.


Si vous avez besoin de cette logique à plusieurs endroits, alors oui, les filtres seraient une bonne approche.