Puncte:0

găzduiește două aplicații pe același domeniu folosind apache, una cu autentificare de bază

drapel jp

Am probleme la configurare apache.

Aplicatii:

  • aplicația 1 - SPA (frontend), care rulează în docker. Accesibil local de către http://localhost:91

  • aplicația 2 - WebAPI (serviciu backend), care rulează în docker. Accesibil local de către http://localhost:90

Aș dori să fac ambele aplicații disponibile pe același domeniu prin HTTPS folosind apache:

  • aplicație 1: https://my.domain.com <- ar trebui să fie securizat cu autentificare de bază.
  • aplicația 2: https://my.domain.com/api

Am crezut că această configurare funcționează când am folosit HTTP simplu pentru a accesa recursurile, dar odată ce am trecut la HTTPS (autosemnat cu letsencrypt) - totul pare să fi încetat să funcționeze.

aici este cea mai recentă configurație

<VirtualHost *:80>
    ServerName my.domain.com
    ServerAlias www.my.domain.com
    
    TraceEnable off

    RewriteEngine on
    RewriteCond %{SERVER_NAME} =www.my.domain.com [OR]
    RewriteCond %{SERVER_NAME} =my.domain.com
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
    
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName my.domain.com
    ServerAlias www.my.domain.com

    TraceEnable off
    ProxyRequests Off
    ProxyPreserveHost On
    
    <Proxy *>
        Order deny,allow
        #Allow from all
        Allow from 127.0.0.1
    </Proxy>
    
    Timeout 2400
    ProxyTimeout 2400
    ProxyBadHeader Ignore 

    <Location />
        AuthType Basic
        AuthName "Restricted Content"
        AuthUserFile /etc/apache2/.htpasswd
        Require valid-user
        
        ProxyPass        http://localhost:91/ Keepalive=On
        ProxyPassReverse http://localhost:91/
    </Location>
    
    <Location /api>
        ProxyPass        http://localhost:90/
        ProxyPassReverse http://localhost:90/
    </Location>
    
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/my.domain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/my.domain.com/privkey.pem
</VirtualHost>
</IfModule>

Cea mai recentă și actuală problemă este:

Ori de câte ori încerc să accesez punctul final https://my.domain.com/api/Auth/Login - utilizatorului i se solicită pagina de autentificare. Acest lucru ar trebui să fie valabil numai pentru adresele URL care nu sunt API.

Cu alte cuvinte - <Location /api> directiva pare a fi ignorată.Am încercat să amestec directivele de locație, precum și alte zeci de soluții și niciuna dintre ele nu funcționează.. Am încercat și directive mai explicite, cum ar fi <LocationMatch /(api).*> și asta nu a funcționat.

Este ceva în neregulă cu regulile de potrivire a locației?

Puncte:3
drapel in

<Location /api> nu este ignorată, pur și simplu nu ați configurat autentificarea pentru acesta, deci se aplică configurația de la nivelul superior.

Dezactivați AuthType pentru locatie:

<Location /api>
    AuthType None
    Require all granted
    ProxyPass        http://localhost:90/
    ProxyPassReverse http://localhost:90/
</Location>
djdomi avatar
drapel za
Adevărat, asta este invers modul în care ar funcționa și un alt sub Dom ;)
drapel jp
@Gerald Perfect! O întrebare ulterioară.. Când încerc să navighez la `https://my.domain.com/manifest.json`, fișierul va fi deschis deoarece ar fi fost o pagină web (adică resursa nu ar fi găsită). Pe de altă parte, dacă încerc să-l accesez direct prin IP-ul PC local: `http://192.168.0.110:91/manifest.json`, aș lovi un fișier real găzduit în SPA. Același lucru este valabil pentru orice fișier CSS și JS. În ciuda faptului că niciun fișier nu este accesibil din rețeaua exterioară - pagina web este încă încărcată corect. Există o explicație bună pentru acest comportament? Este posibil ca toate fișierele să fie accesibile așa cum sunt?
drapel in
Aceasta ar trebui să fie o întrebare nouă, dar o presupunere ar fi că serverul backend utilizează diferite rădăcini de documente sau vhost-uri dacă este accesat prin localhost și 192.168.0.110.
drapel jp
Încă un lucru pe care l-am observat când accesez `http://192.168.0.110:91/` - există o eroare `403` pentru tipul de solicitare `OPTIONS` înregistrată, făcând astfel site-ul inutilizabil (CORS nu ar funcționa). După setarea `loglevel` și inspectarea în continuare a jurnalelor `apache` am găsit următoarea linie `AH01797: client refuzat de configurația serverului: proxy:http://localhost:90/Auth/Login, referer: ..`. Am reușit să o repar adăugând „Permite de la toate” imediat după „Solicită toate acordate”. Nu sunt sigur dacă este ceea ce trebuie făcut, dar a rezolvat problema.
drapel jp
Și există încă o problemă restante - atunci când site-ul este accesat prin numele de domeniu - se încarcă „versiunea în cache” a site-ului. i.e. chiar dacă versiunea mai nouă a SPA a fost implementată, browserul nu pare să fie atât de dornic să reîmprospăteze conținutul.. Încă nu am descoperit totul, dar problema pare să fie legată și de configurația Apache, deoarece nu există o astfel de problemă atunci când site-ul web este accesat prin adresa IP locală. Indiferent, cred că voi deschide o nouă întrebare pentru acest scenariu mai târziu, după ce am studiat mai mult această problemă..

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.