Join Log in
Score:0
avatar Server

hosting two applications on same domain using apache, one with basic authentication

jp flag
Alex

I am having troubles setting-up apache.

Applications:

  • application 1 - SPA (frontend), running in docker. Accessible locally by http://localhost:91

  • application 2 - WebAPI (backend service), running in docker. Accessible locally by http://localhost:90

I would like to make both applications available on the same domain via HTTPS using apache:

  • application 1: https://my.domain.com <- should be secured with basic auth.
  • application 2: https://my.domain.com/api

I thought I had this set-up working when I used plain HTTP to access the recourses, but once I switched to HTTPS (self-signed with letsencrypt) - everything seems to have stopped working.

here is the latest configuration

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

The latest and current problem is:

Whenever I try to access the endpoint https://my.domain.com/api/Auth/Login - user is prompted with login page. This should only be valid for non-api urls.

In other words - <Location /api> directive seems to be ignored. I have tried shuffling location directives around as well as dozen of other solutions and none of them work.. I also tried more explicit directive like <LocationMatch /(api).*> that also failed to work.

Is there something wrong with location matching rules?

265
0 + 0
Score:3
avatar Server
in flag
Gerald Schneider

<Location /api> is not ignored, you just haven't configured the authentication for it, so the configuration from the higher level applies.

Disable AuthType for the location:

<Location /api>
    AuthType None
    Require all granted
    ProxyPass        http://localhost:90/
    ProxyPassReverse http://localhost:90/
</Location>
0 + 0
djdomi avatar
za flag
djdomi
true, that is the other way around the way that fix it a other sub Dom would also work ;)
0
Reply
jp flag
Alex
@Gerald Perfect! One follow up question.. When I try to navigate to `https://my.domain.com/manifest.json` the file would be opened as it would have been a webpage (i.e. resource wouldn't be found). On the other hand, if I try to access it directly by local PC IP: `http://192.168.0.110:91/manifest.json` I would hit an actual file hosted in SPA. Same goes for any CSS and JS file. Despite the fact none of the file are accessible from outer network - the webpage is still loaded correctly. Is there a good explanation for this behavior? Is it possible to make all files accessible as is?
0
Reply
in flag
Gerald Schneider
That should be a new question, but a guess would be that the backend server uses different document roots or vhosts if accessed via localhost and 192.168.0.110.
1
Reply
jp flag
Alex
One more thing I have noticed when accessing `http://192.168.0.110:91/` - there is `403` error for `OPTIONS` type of request logged thus making the website unusable (CORS wouldn't work). After setting the `loglevel` and further inspecting the `apache` logs I have found the following line `AH01797: client denied by server configuration: proxy:http://localhost:90/Auth/Login, referer: ..`. I have managed to fix it by adding `Allow from all` soon after `Require all granted`. Not sure if it's the right thing to do but it solved the problem.
0
Reply
jp flag
Alex
And there is still one outstanding problem - when website is accessed by domain name - the "cached version" of the website is loaded. I.e. even if newer version of the SPA was deployed browser does not seems to be so eager to refresh the contents.. I am yet to figure it all out, but the problem seems to also be related to apache config as there is no such problem when website is accessed by local IP address. Regardless, I think I will open new question for this scenario later after studying this problem a bit more..
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.