Puncte:0

Depanați autentificări terță parte în localhost cu docker și nginx

drapel kr

Avem un site web pe care tocmai am adăugat autentificări de la terți, cum ar fi Google, Twitter. Încerc să testez aceste autentificări în localhost (MacOS).

Rulez un docker pentru a rula nginx, iată docker-compose-dev.xml

versiunea: "3"
Servicii:
  https:
    imagine: bitnami/nginx:latest
    reporniți: dacă nu este oprit
    porturi:
      - 443:443/tcp
    volume:
      - ./conf.d/dev.conf:/opt/bitnami/nginx/conf/server_blocks/default.conf:ro
    extra_hosts:
      - „host.docker.internal:host-gateway”

Și iată conf.d/dev.conf:

distracție în amonte {
   server 178.62.87.72:443;
}
Server {
    asculta 443 ssl;
    nume_server gazdă locală;
    certificat_ssl /certs/server.crt;
    ssl_certificate_key /certs/server.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers activat;
    ssl_session_timeout 1d;
    ssl_capsare off;
    ssl_stapling_verify off;
    add_header Strict-Transport-Security max-age=15768000;
    add_header X-Frame-Options "";
    proxy_ssl_name „www.funfun.io”;
    proxy_ssl_server_name activat;
    locație ~ /socialLoginSuccess {
        rescrie redirecționarea ^ „/#/socialLoginSuccess”;
     }
    locație ~ /auth/(.*) {
        proxy_pass https://funfun/10studio/auth/$1?$query_string;
        proxy_set_header Gazdă localhost;
     }
    Locație / {
        proxy_set_header Gazdă $gazdă;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $schema;
        proxy_set_header Acceptare-Codificare „”;
        proxy_set_header Proxy „”;
        proxy_pass http://host.docker.internal:3000/;
        # Aceste trei linii adăugate conform https://github.com/socketio/socket.io/issues/1942 pentru a elimina eroarea socketio
        proxy_http_versiunea 1.1;
        proxy_set_header Actualizare $http_upgrade;
        proxy_set_header Conexiune „upgrade”;
    }
}

Modul în care lansăm aplicația este sudo PORT=8000 HTTPS=true ./node_modules/.bin/react-scripts start. Atunci https://localhost:8000/#/sign într-un browser deschide pagina în care sunt butoanele de autentificare.

Url-ul butonului care face legătura cu autentificarea Google este https://localhost/10studio/auth/google. Făcând clic pe el, văd primul https://localhost/10studio/auth/google în bara de adrese a browserului, dar pagina pentru a introduce ID-ul și parola Google nu apare, apoi câteva secunde mai târziu, adresa URL devine https://localhost/#/socialLoginSuccess, iar pagina apare 502 Bad Gateway. Văd următoarele jurnale în terminalul care rulează nginx:

$ docker-compose --f docker-compose-dev.yml sus
AVERTISMENT: S-au găsit containere orfane (frontend_10studio_1, frontend_frontend_1) pentru acest proiect. Dacă ați eliminat sau redenumit acest serviciu din fișierul dvs. de scriere, puteți rula această comandă cu indicatorul --remove-orphans pentru a-l curăța.
Pornirea frontend_https_1 ... gata
Se atașează la frontend_https_1
https_1 | nginx 21:24:05.37 
https_1 | nginx 21:24:05.38 Bun venit la containerul Bitnami nginx
https_1 | nginx 21:24:05.38 Abonați-vă la actualizările proiectului urmărind https://github.com/bitnami/bitnami-docker-nginx
https_1 | nginx 21:24:05.39 Trimiteți probleme și solicitări de funcții la https://github.com/bitnami/bitnami-docker-nginx/issues
https_1 | nginx 21:24:05.39 
https_1 | nginx 21:24:05.39 INFO ==> ** Se pornește configurarea NGINX **
https_1 | nginx 21:24:05.42 INFO ==> Validarea setărilor în NGINX_* env vars
https_1 | nginx 21:24:05.43 INFO ==> Se inițializează NGINX
https_1 | realpath: /bitnami/nginx/conf/vhosts: Nu există un astfel de fișier sau director
https_1 | 
https_1 | nginx 21:24:05.45 INFO ==> ** Configurarea NGINX s-a încheiat! **
https_1 | nginx 21:24:05.47 INFO ==> ** Se pornește NGINX **
https_1 | 172.19.0.1 - - [08/Nov/2021:21:25:06 +0000] „GET /10studio/auth/google HTTP/1.1” 302 0 „https://localhost:8000/” „Mozilla/5.0 (Macintosh ; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, ca Gecko) Chrome/95.0.4638.54 Safari/537.36" "-"
https_1 | 172.19.0.1 - - [08/Nov/2021:21:25:07 +0000] „GET /auth/google/callback?code=4%2F0AX4XfWiqleRl2StBpNOgOtzjqZlftvq9-uDmiPVLZqcgo2xprofile%2F0AX4XfWiqleRl2StBpNOgOtzjqZlftvq9-uDmiPVLZqcgo2xprofile%2F0AX4XfWiqleRl2StBpNOgOtzjqZlftvq9-uDmiPVLZqcgo2xprofile%2F0AX4F00000000000 .com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+openid&authuser=0&prompt=none HTTP/1.1" 302 82 "https://localhost:8000/" "Mozilla /5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, ca Gecko) Chrome/95.0.4638.54 Safari/537.36" "-"
https_1 | 172.19.0.1 - - [08/Nov/2021:21:25:07 +0000] „GET /auth/signinSuccess HTTP/1.1” 302 82 „https://localhost:8000/” „Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, ca Gecko) Chrome/95.0.4638.54 Safari/537.36" "-"
https_1 | 172.19.0.1 - - [08/Nov/2021:21:25:07 +0000] „GET /socialLoginSuccess HTTP/1.1” 302 138 „https://localhost:8000/” „Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, ca Gecko) Chrome/95.0.4638.54 Safari/537.36" "-"
https_1 | 2021/11/08 21:25:39 [eroare] 27#27: *2 connect() a eșuat (110: Conexiune a expirat) în timpul conectării la amonte, client: 172.19.0.1, server: localhost, cerere: „GET / HTTP/1.1”, în amonte: „http://192.168.65.1:3000/”, gazdă: „localhost”, referitor: „https://localhost:8000/”
https_1 | 172.19.0.1 - - [08/Nov/2021:21:25:39 +0000] „GET / HTTP/1.1” 502 552 „https://localhost:8000/” „Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, ca Gecko) Chrome/95.0.4638.54 Safari/537.36" "-"

Știe cineva ce este în neregulă aici?

În plus, când depanez nginx, este ca o cutie neagră pentru mine. Îmi doresc foarte mult să pot urmări și să văd ce adresă URL intră în ce bloc de locație și se modifică în ce adresă URL (prin proxy_pass sau rescrie, etc.). Are cineva o modalitate mai bună de a depana sau de a înregistra asta?

drapel ws
Nu sunt familiarizat cu gestionarea certbot de la docker, dar letsencrypt nu va emite un certificat cu un nume de gazdă „localhost”.
drapel kr
@symcbean ai dreptate, acum folosesc o altă imagine docker.
dirkt avatar
drapel in
Abordări generice de depanare (pe care le puteți deja acum): (1) Folosiți fila de rețea din instrumentele de dezvoltare pentru browserul dvs. (Safari sau altfel), vă va arăta în special noua destinație pentru 302s, astfel încât să puteți înțelege mai multe despre ce continuă în flux. (2) Utilizați un proxy man-in-the-middle de înregistrare, de ex. [mitmproxy](https://mitmproxy.org), în modul proxy transparent dacă este necesar. (3) În principiu, puteți pune și un mitproxy între nginx și serviciul dvs.
dirkt avatar
drapel in
Și nu înțeleg cum doriți să capturați redirecționările obișnuite OAuth cu configurarea proxy-ului, așa că nu pot comenta de ce nu funcționează. Pentru OAuth normal, nu trebuie să faceți nimic special.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.