Điểm:0

lưu trữ hai ứng dụng trên cùng một miền bằng apache, một ứng dụng có xác thực cơ bản

lá cờ jp

Tôi đang gặp sự cố khi thiết lập apache.

Các ứng dụng:

  • ứng dụng 1 - SPA (giao diện người dùng), chạy trong docker. Có thể truy cập cục bộ bởi http://localhost:91

  • ứng dụng 2 - WebAPI (dịch vụ phụ trợ), chạy trong docker. Có thể truy cập cục bộ bởi http://localhost:90

Tôi muốn cung cấp cả hai ứng dụng trên cùng một miền thông qua HTTPS bằng cách sử dụng apache:

  • ứng dụng 1: https://my.domain.com <- phải được bảo mật với auth cơ bản.
  • ứng dụng 2: https://my.domain.com/api

Tôi nghĩ rằng thiết lập này của tôi đã hoạt động khi tôi sử dụng HTTP đơn giản để truy cập các nguồn truy cập, nhưng sau khi tôi chuyển sang HTTPS (tự ký với cho phép mã hóa) - mọi thứ dường như đã ngừng hoạt động.

đây là cấu hình mới nhất

<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>

Vấn đề mới nhất và hiện tại là:

Bất cứ khi nào tôi cố gắng truy cập điểm cuối https://my.domain.com/api/Auth/Login - người dùng được nhắc với trang đăng nhập. Điều này chỉ nên hợp lệ cho các url không phải api.

Nói cách khác - <Location /api> chỉ thị dường như bị bỏ qua.Tôi đã thử xáo trộn các chỉ thị vị trí xung quanh cũng như hàng tá giải pháp khác và không giải pháp nào trong số đó hoạt động.. Tôi cũng đã thử chỉ thị rõ ràng hơn như <LocationMatch /(api).*> điều đó cũng không hoạt động.

Có điều gì sai với quy tắc so khớp vị trí không?

Điểm:3
lá cờ in

<Location /api> không bị bỏ qua, chỉ là bạn chưa định cấu hình xác thực cho nó, vì vậy cấu hình từ cấp cao hơn sẽ được áp dụng.

Vô hiệu hóa AuthType cho vị trí:

<Location /api>
    AuthType None
    Require all granted
    ProxyPass        http://localhost:90/
    ProxyPassReverse http://localhost:90/
</Location>
djdomi avatar
lá cờ za
đúng, đó là cách khác để sửa nó, một Dom phụ khác cũng sẽ hoạt động;)
lá cờ jp
@Gerald Hoàn hảo! Một câu hỏi tiếp theo.. Khi tôi cố gắng điều hướng đến `https://my.domain.com/manifest.json`, tệp sẽ được mở vì nó từng là một trang web (tức là sẽ không tìm thấy tài nguyên). Mặt khác, nếu tôi cố truy cập trực tiếp bằng IP PC cục bộ: `http://192.168.0.110:91/manifest.json` thì tôi sẽ gặp một tệp thực tế được lưu trữ trong SPA. Điều tương tự cũng xảy ra với bất kỳ tệp CSS và JS nào. Mặc dù thực tế là không có tệp nào có thể truy cập được từ mạng bên ngoài - trang web vẫn được tải chính xác. Có một lời giải thích tốt cho hành vi này? Có thể làm cho tất cả các tệp có thể truy cập được không?
lá cờ in
Đó phải là một câu hỏi mới, nhưng có thể đoán rằng máy chủ phụ trợ sử dụng các gốc tài liệu hoặc vhost khác nhau nếu được truy cập qua máy chủ cục bộ và 192.168.0.110.
lá cờ jp
Một điều nữa tôi nhận thấy khi truy cập `http://192.168.0.110:91/` - có lỗi `403` đối với loại yêu cầu `TÙY CHỌN` được ghi lại, do đó khiến trang web không sử dụng được (CORS sẽ không hoạt động). Sau khi đặt `loglevel` và kiểm tra thêm nhật ký `apache`, tôi đã tìm thấy dòng sau `AH01797: máy khách bị từ chối bởi cấu hình máy chủ: proxy:http://localhost:90/Auth/Login, người giới thiệu: ..`. Tôi đã cố gắng khắc phục bằng cách thêm `Cho phép từ tất cả` ngay sau `Yêu cầu tất cả được cấp`. Không chắc đó có phải là điều đúng đắn hay không nhưng nó đã giải quyết được vấn đề.
lá cờ jp
Và vẫn còn một vấn đề nổi cộm - khi website được truy cập bằng tên miền - "phiên bản đã lưu trong bộ nhớ cache" của website được tải. I E. ngay cả khi phiên bản mới hơn của SPA đã được triển khai, trình duyệt dường như không quá háo hức để làm mới nội dung.. Tôi vẫn chưa tìm ra tất cả, nhưng vấn đề dường như cũng liên quan đến cấu hình apache vì không có vấn đề nào như vậy khi trang web được truy cập bằng địa chỉ IP cục bộ. Bất kể, tôi nghĩ rằng tôi sẽ mở câu hỏi mới cho kịch bản này sau khi nghiên cứu vấn đề này nhiều hơn một chút ..

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.