La SCRO contrôle en amont de la demande de retour “403 Forbidden”; la suite de la demande alors d'envoyer uniquement dans Chrome

Après échec à l'aide de pluploader dans cette question, je vais maintenant essayer FineUploader.

Après la lecture sur la SCRO, j'ai mis en place différents en-têtes sur mon serveur IIS6.

Ce qui semble se passer, c'est que mon script feux de la première (preflight) demande d'autorisation, qui échoue, mais Chrome permet à la seconde (standard) demande d'envoyer de toute façon - Firefox ne le fait pas. Je suppose qu'il s'agit en fait d'un bug sur le nom de Chrome, mais au moins ça m'a permis de découvrir que mon script est probablement travail correctement.

Voici la première (preflight) demande comme on le voit dans Chrome et FF:

OPTIONS /frog/LOTS/upload/php.php HTTP/1.1
Host: staff.curriculum.local
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Origin: http://frogserver.curriculum.local
Access-Control-Request-Method: POST
Access-Control-Request-Headers: cache-control,x-requested-with
Pragma: no-cache
Cache-Control: no-cache

La Access-Control... les en-têtes sont ceux que j'ai ajoutés à IIS.

Et voici mes en-têtes de réponse:

HTTP/1.1 403 Forbidden
Content-Length: 1758
Content-Type: text/html
Server: Microsoft-IIS/6.0
x-powered-by: ASP.NET
Access-Control-Allow-Origin: http://frogserver.curriculum.local
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Cache-Control
Access-Control-Allow-Methods: OPTIONS, GET, POST
Access-Control-Expose-Headers: Origin, X-Requested-With
Date: Mon, 22 Apr 2013 15:19:20 GMT

J'ai essayé de comparer les deux côte à côte mais je ne trouve pas de manquants en-têtes qui serait la cause de la preflight demande de retour d'un 403 Forbidden erreur.

La SCRO contrôle en amont de la demande de retour “403 Forbidden”; la suite de la demande alors d'envoyer uniquement dans Chrome

Je n'ai pas compris ma source en PHP que c'est beaucoup de code. Autant dire que ça fonctionne dans Chrome et que le fichier est bien téléchargé, donc le script devrait être correct. La seule chose qui peut être intéressant de mentionner est que j'ai un header("Content-Type: text/plain"); au début de mon script. Changer de text/html ne fait aucune différence pour Chrome ni FireFox.

Le JavaScript est assez simple:

$('#jquery-wrapped-fine-uploader').fineUploader({
    request: {
        endpoint: 'http://staff.curriculum.local/frog/LOTS/upload/php.php'
    },
    cors: {
        expected: true, //all requests are expected to be cross-domain requests
        sendCredentials: true //if you want cookies to be sent along with the request
    }
});

Peut aider quelqu'un? J'ai littéralement passé 8 heures sur ce problème aujourd'hui et je suis >< près de l'extraction mon propre visage éteint....!!

Merci d'avance,

Ce n'est pas vraiment semblent être une Amende Uploader problème pour moi. Vous souhaiterez peut-être modifier l'un de vos balises de IIS. Fine Uploader n'est pas impliqué (beaucoup) d'ici à tous. L'agent utilisateur envoie les OPTIONS (preflight) en fait la demande, Beaux-Uploader. Pour une raison quelconque, votre serveur est en train de rejeter cette demande avec un 403. Vous voudrez peut-être jeter un oeil à votre serveur de logs pour voir pourquoi il est de répondre à 403.
Encore une fois, +1 pour le bien posé la question!
vous avez raison, ce n'est pas un problème, avec de Beaux Uploader, mais je pense que ce serait faux de dire qu'il n'est pas pertinent. N'Fine Uploader déterminer les en-têtes que le contrôle en amont de demande d'envoie?
Non, les Beaux-Uploader n'a aucune implication dans le contrôle en amont de la demande. Il est géré entièrement par l'agent utilisateur.
OK @RayNicholus, merci. Savez-vous, alors, qu'est ce qui détermine les en-têtes pour le contrôle en amont de la demande?

OriginalL'auteur dunc | 2013-04-22

5

Comme mentionné dans mes commentaires, cela semble être un problème avec votre serveur. Pour une raison quelconque, il est de refuser la première demande d'OPTIONS. Vous aurez besoin de regarder vos logs du serveur pour voir pourquoi votre serveur est de répondre à cette demande avec une 403.

L'agent utilisateur envoie cette OPTIONS initiales (avant le vol) demande. Fine Uploader ne pas l'envoyer directement une demande, l'agent de l'utilisateur envoie à être en conformité avec de la SCRO spec. Si vous avez des questions spécifiques au sujet de la SCRO, vous pouvez voir mon blog sur la façon Fine Uploader les poignées de la SCRO, ou/et que vous pouvez lire cet excellent MDN article sur la SCRO.

J'ai lu deux de votre blog et votre article, mais aucun ne me permet de remédier à ce problème. De ce que je peux voir dans les demandes/réponses en fonction de mon navigateur, le contrôle en amont de la demande de travail - l'en-tête et la méthode sont à la fois autorisé par le serveur.
Est votre serveur attend des cookies pour être envoyée avec la demande dans le but d'authentifier la demande? Si oui, c'est votre problème. Le contrôle en amont des demandes ne sera pas inclure des cookies, par la spécification.
... voir w3.org/TR/cors/#cross-origin-request-with-preflight-0 pour plus de détails.
Salut à nouveau Ray. J'ai essayé de réglage sendCredentials à false et en supprimant les informations d'identification de l'en-tête de IIS, mais j'obtiens exactement les mêmes résultats.
il ne sonne pas comme vous l'avez compris mon dernier commentaire. Permettez-moi de reformuler. Ma conjecture est que votre serveur attend des informations d'identification pour être envoyée avec la demande options. Cela n'arrivera jamais, par la spécification. Cela expliquerait peut-être la 403.

OriginalL'auteur Ray Nicholus
2

Il m'a pris une semaine, mais j'ai enfin trouvé le problème.

Par défaut, IIS6 ne prend pas en charge les OPTIONS de verbe .les fichiers php (ou .asp(x)).

En tant que tel, il n'était pas reconnaissant la OPTIONS de contrôle en amont appel à tous.

Pour modifier cette valeur dans IIS6, suivez ces étapes:
1. Dans le Gestionnaire des services IIS, allez à la racine de votre répertoire du site web. Cliquez-droit dessus et sélectionnez "Propriétés"
2. Allez à l'onglet Répertoire de base, puis sélectionnez le bouton "Configuration" en bas
3. À trouver les extension de fichier du script que vous essayez de communiquer avec, comme .php ou .asp et cliquez sur "modifier"
4. Ajouter OPTIONS à la liste des verbes (devrait afficher quelque chose comme REQUEST, GET, POST, OPTIONS)
5. Ajoutez le code ci-dessous pour votre script PHP pour déterminer les réponses à partir de IE
Je ne pouvais pas obtenir d'Internet Explorer de travail sans le code suivant dans mon script PHP:
```
/* Is the request from Internet Explorer? */
if( !isset( $_SERVER['HTTP_X_REQUESTED_WITH'] )
    || ( isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_X_REQUESTED_WITH'] != "XMLHttpRequest" ) ) {

    /* If so, we need to send a UUID and iframe XSS response script... */
    header("Content-Type: text/html");

    /* This needs some extra security, for sure */
    if( $result["success"] == "true" )
        $result["uuid"] = $_POST["qquuid"];

    echo htmlspecialchars(json_encode($result), ENT_NOQUOTES);
    echo "<script src='iframe.xss.response-3.4.1.js'></script>";
} else {
    /* Otherwise, we can just echo the json'd result */
    echo htmlspecialchars(json_encode($result), ENT_NOQUOTES);
}
```
J'ai donné Ray Nicholus les 50 points prime comme bien que je n'ai pas trouvé sa manière particulièrement utiles, il a été la bonne. Toutefois, pour les fins d'autrui, de la visualisation de ce post avec un problème similaire, je vais marquer ma réponse comme correcte.

- Vous, mais cette question est un doublon, comme je l'ai lié avant: stackoverflow.com/questions/6656354/... Seulement MSIE 10+ prise en charge de la SCRO, c'est pourquoi il ne fonctionne pas sous IE... ci-Dessous, la version qui vous avez seulement inutile XDomainRequest avec très peu de fonctions...
Vous avez posté votre lien, apparemment, comme je l'écrivais ma réponse.. 🙂 je suis sûr que vous avez raison, mais le téléchargement de fichiers inter-domaine travaille aujourd'hui dans tous les navigateurs avec FineUploader, donc je suis heureux.
Cette question n'est pas similaire à la question. Fine Uploader n'utilise pas xhr ou xdomain demande de transfert de fichier dans ie9 ou plus. Au lieu de cela, un formulaire à l'intérieur d'une iframe masqué est soumis. La transmission de Message est utilisé pour obtenir autour de la croix de domaine en question lors de la tentative d'analyser la réponse du côté client. Cela signifie que la scro demandes pour que les téléchargements ne sont pas pris en charge dans ie7 et plus si.

OriginalL'auteur dunc

Vous devez vous connecter pour publier un commentaire.