xmlHttp.getResponseHeader + Pas de travail pour la SCRO

J'ai un asp.NET WCF sur .NET 4. Ce service est utilisé pour authentifier les utilisateurs. Nous soumettez un nom d'utilisateur et mot de passe, puis un en-Tête HTTP doit être retourné avec le cookie d'authentification inclus. À l'aide d'un hébergés localement page de test cela fonctionne correctement. Je suis en train d'essayer d'accéder à l'information d'en-tête de la croix de domaine. J'ai installé ma page de test sur une autre machine et configuré pour appeler l'ensemble de la WCF. L'appel est de travail et les données de réponse à l'appel est correct. Cependant, je suis incapable d'accéder à l'information d'en-tête avec l'une des opérations suivantes: 

alert(xmlHttp.getAllResponseHeaders());

ou

alert(xmlHttp.getResponseHeader("Set-Cookie"));

En utilisant le débogueur dans IE et le Live " en-Tête HTTP plugin pour Firefox, je peux voir les informations d'en-tête doit être retourné.

Dans mon global ajax page que je suis en train de la réponse à la poignée de la SCRO.

private void EnableCrossDomainAjaxCall()
{
    HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "*");


    if (HttpContext.Current.Request.HttpMethod == "OPTIONS")
    {

        HttpContext.Current.Response.AddHeader("Cache-Control", "no-cache");
        HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
        HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "Content-Type, Accept");

        HttpContext.Current.Response.AddHeader("Access-Control-Max-Age", "1728000");
        HttpContext.Current.Response.End();
    }

}

C'est de l'AJAX j'utilise pour appeler le service:

$("#btnLogin").click(function(e) {
    var geturl;
    geturl = $.ajax({
        //type: "POST",
        type: "GET",
        contentType: "application/json; charset=utf-8",
        url: 'http://10.0.4.66/AuthenticationService.svc/Login?Name=test&password=pwsd',
        //url: '../SecurityServer/AuthenticationService.svc/Login?Name=test&password=pwsd',
        dataType: "jsonp",
        error: function(request, status, error) {
            alert('Error Occured');
        },
        crossdomain: true,
        success: function(data, textStatus, xmlHttp) {
            //alert(xmlHttp.getResponseHeader("Content-Type"));
            document.write(xmlHttp.getResponseHeader("Content-Type") + "<br/>");
            alert(xmlHttp.getAllResponseHeaders());
            alert(xmlHttp.getResponseHeader("Set-Cookie"));
            var headers = '';
            var headerPair = xmlHttp.getAllResponseHeaders('wcfCookie').split("\r\n");
            var output = '';
            $.each(headerPair, function(key, line) {
                var parts = line.split(':');

                if (parts[0] == 'wcfCookie') {
                  ChocChip = parts[1]
                  return false
                }

            });
        }
    });

Ci-dessous mon en-tête informations saisies à partir de "Live HTTP headers'

Date: Mon, 04 Feb 2013 12:12:40 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Access-Control-Allow-Origin: *
Set-Cookie: wcfCookie=8D38D5D6A0F138FEB595DD016F7694EDDF3E6757C82ED3D419F5047A5294974C1885487465CEC0A0BCC2B3802C7B03FF9F5370A05D4CCBDDDABCB1558C3816044BF4F78209BF38C6B1A7CAD34CD3C85C40B8515CFB1C2B2694BC78803D8DACB4
Content-Length: 65
Cache-Control: application/json; charset=utf-8
Content-Type: application/x-javascript
InformationsquelleAutor user2039547 | 2013-02-04
  1. 63

    Tout d'abord, un petit retour en arrière:

    Vous utilisez Access-Control-Allow-Headers, qui spécifie les demande en-têtes, le client est autorisé à envoyer, mais vous ne spécifiez pas ce qui réponse en-têtes, le client est autorisé à lire. Afin de permettre au client de lire non simple en-têtes de réponse, vous devez utiliser Access-Control-Expose-Headers. À partir de la HTML5 Rocks de la SCRO page:

    Au cours d'une SCRO demande, le getResponseHeader() méthode ne peut accéder simple en-têtes de réponse. Simple en-têtes de réponse sont définis comme suit:

    • Cache-Control
    • Content-Language
    • Content-Type
    • Expire
    • Last-Modified
    • Pragma

    Si vous voulez que les clients d'être en mesure d'accéder à d'autres en-têtes, vous devez utiliser le Access-Control-Expose-Headers en-tête. La valeur de cet en-tête est une liste séparée par des virgules des en-têtes de réponse vous souhaitez exposer au client.

    Donc, étant donné que de nouveaux renseignements, vous pourriez faire:

    HttpContext.Current.Response.AddHeader("Access-Control-Expose-Headers", "Set-Cookie");

    ...mais il ya plus à lui que cela.

    Maintenant, la réponse réelle:

    Il y a un problème plus grave: la XHR spécification explictily n'autorise pas la lecture de Set-Cookie. C'est parce que c'est fonctionnellement un de la croix-domaine de voler les cookies attaque.

    Supposons que le domaine a fait Une croix-demande de domaine à domaine B. Lorsque le domaine B des ensembles de cookies, c'est le réglage spécifiques à un domaine cookies pour le domaine B seulement. Toute tentative par Un domaine à lire le domaine B de cookies est une violation de la même origine politique pour cookie accès.

    Je ne sais pas WCF, donc je ne suis pas sûr de la meilleure façon de fait faire ce que vous voulez, mais je pense que la solution pourrait être de passer un jeton d'authentification non pas par le biais des cookies (par exemple, un X-WCF-Auth - tête?) ce domaine Un lit et définit son propre témoin.

    InformationsquelleAutor apsillers
  2. 1

    Le navigateur les politiques de sécurité peuvent bloquer votre réponse parce que vous n'avez pas défini:

    HttpContext.Current.Response.AddHeader("Access-Control-Allow-Credentials","true");

    Si cela ne fonctionne pas, essayez d'ajouter 

    xhrFields: { withCredentials: true }

    à votre ajax options peuvent aussi être vaut la peine d'essayer.

    InformationsquelleAutor marty