Reverse proxy Nginx - relais de base authenication

J'essaye de configurer nginx inverse rpoxy serveur en face de plusieurs serveurs web IIS qui sont l'authentification à l'aide de l'authentification de Base.

(note - ce n'est pas le même que nginx fournir l'authentification à l'aide d'un fichier de mot de passe - il faut juste être marshelling everythnig entre le navigateur/serveur)

Sa nature hors - mais avoir invité à plusieurs reprises auth par chaque ressource (image/css etc) sur une page.

upstream my_iis_server {
      server 192.168.1.10;
}

server {
    listen       1.1.1.1:80;
    server_name  www.example.com;  

    ## send request back to my iis server ##
    location /{
     proxy_pass  http://my_iis_server;
     proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
     proxy_http_version      1.1;
     proxy_set_header        Connection "";
     proxy_pass_header       Authorization;     
     proxy_redirect off;
     proxy_buffering off;
     proxy_set_header        Host            $host;
     proxy_set_header        X-Real-IP       $remote_addr;
     proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
   }
}

OriginalL'auteur Ryan | 2013-02-12

  1. 5

    Cette situation m'a pris une éternité à comprendre, mais OSS est comme ça, je suppose. Ce post est d'un an peut-être que l'affiche originale pensé à elle, ou donné?

    De toute façon, le problème pour moi, au moins, a été causé par plusieurs choses:

    1. IIS attend le domaine de la chaîne à être le même que ce qu'il a envoyés à Nginx, mais si votre Nginx server_name est à l'écoute sur une adresse différente de celle de l'amont puis le côté serveur WWW-Authenticate ne va pas être ce qu'IIS m'attendais et l'ignorer.
    2. La builtin en-tête de module n'est pas évident de l'autre WWW-Authenticate en-têtes, en particulier la problématique WWW-Authenticate: Négocier. En utilisant les en-têtes-plus le module permet d'effacer les anciennes têtes, et ajoute de ce que vous lui dites.

    Après cela, j'ai pu enfin pousser Sharepoint 2010 via Nginx.

    Grâce stackoverflow.

    server {
    listen 80;
    server_name your.site.com;

    location /{
            proxy_http_version      1.1;
            proxy_pass_request_headers on;
            proxy_set_header        Host            $host;
            proxy_set_header        X-Real-IP       $remote_addr;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

            #proxy_pass_header      Authorization; //This didnt work for me
            more_set_input_headers  'Authorization: $http_authorization';

            proxy_set_header  Accept-Encoding  "";

            proxy_pass              https://sharepoint/;
            proxy_redirect          default;
            #This is what worked for me, but you need the headers-more mod
            more_set_headers        -s 401 'WWW-Authenticate: Basic realm="intranet.example.com"';
    }
}
    L'affiche originale a en effet d'abandonner et plutôt essayé Microsoft IIS Demande d'Application de Routage (ARR), qui n'a gérer et NTML auth sans aucun problème, mais a provoqué de très étranges des problèmes avec certains de SharePoint 2013 est Minime Stratégie Téléchargement (MDS) que je n'ai jamais le fond au large.
    Peut-être que cela pourrait être utile: serverfault.com/questions/230749/...
    Salut j'ai besoin de passer qqch comme nom d'utilisateur:mot de passe au lieu de realm="etc" sera-ce encore du travail?
    more_set_input_headers more_set_headers ce sont ceux-là?

    OriginalL'auteur Matt

  2. 0

    J'ai eu ces symptômes avec nginx/1.10.3. J'ai un service garanti en vertu de l'authentification de base, et nginx en tant que reverse proxy entre le client et le serveur. L'exigence était que nginx serait passthrough l'autorisation.

    Première demande au serveur de ne passer à travers l'en-tête d'Autorisation. Deuxième demande simplement bloqué cet en-tête, ce qui signifiait que le client a été en mesure de faire une demande par session.

    C'était en quelque sorte lié à des cookies. Si j'ai effacé les cookies du navigateur, puis le cycle est répété. Le client a été en mesure de s'authentifier, mais seulement pour la première demande. La fermeture du navigateur a eu le même effet.

    La solution pour moi a été de changer le serveur en amont de https, http, en utilisant:

    proxy_pass http://$upstream;

    au lieu de:

    proxy_pass https://$upstream;

    OriginalL'auteur Leonardo Fernandes