Auth middleware defined on container when it shouldn't be

I've been testing Traefik 2.0.2 as I move things over from my previous 1.7 install and I've ran into a weird issue that I'd like some help with, my docker labels and middleware configs are below for reference:

Middlewares defined in /etc/traefik/file.toml

[http.middlewares]
  [http.middlewares.redirect.redirectScheme]
    scheme = 'https'
    permanent=true

  [http.middlewares.contentSecurity.headers]
    browserXSSFilter = true
    contentTypeNosniff = true

  [http.middlewares.sts.headers]
    forceSTSHeader = true
    STSSeconds = 315360000
    STSIncludeSubdomains = true
    STSPreload = true

[tls.options]
  [tls.options.default]
    minVersion = "VersionTLS12"
  [tls.options.minimalTLS13]
    minVersion = "VersionTLS13"

Traefik container using traefik:v2.0.2
I followed this post to get the dashboard working correctly with a domain.

command:
      - "--log=true"
      - "--log.level=INFO"
      - "--api.dashboard=true"
      - "--serversTransport.insecureSkipVerify=true"
      - "--providers.docker=true"
      - "--providers.docker.watch=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.docker.network=external"
      - "--providers.file=true"
      - "--providers.file.watch=true"
      - "--providers.file.filename=/etc/traefik/file.toml"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.leCloudflareDns.acme.dnschallenge=true"
      - "--certificatesresolvers.leCloudflareDns.acme.dnschallenge.provider=cloudflare"
      - "--certificatesresolvers.leCloudflareDns.acme.dnschallenge.delayBeforeCheck=25"
      - "--certificatesresolvers.leCloudflareDns.acme.email=admin@domain.com"
      - "--certificatesresolvers.leCloudflareDns.acme.storage=/etc/traefik/acme.json"
labels:
      traefik.enable: 'true'
      traefik.http.middlewares.auth.basicauth.users: 'username:encrypted_password'
      traefik.http.middlewares.dashboard-sslheaders.headers.SSLHost: 'proxy.domain.com'
      traefik.http.middlewares.dashboard-sslheaders.headers.SSLRedirect: 'true'
      traefik.http.routers.dashboard.rule: 'Host(`proxy.domain.com`) && PathPrefix(`/dashboard/`) || PathPrefix(`/api`)'
      traefik.http.routers.dashboard.middlewares: 'auth, contentSecurity@file, dashboard-sslheaders, sts@file'
      traefik.http.routers.dashboard.service: 'api@internal'
      traefik.http.routers.dashboard.entrypoints: 'websecure'
      traefik.http.routers.dashboard.tls.certresolver: 'leCloudflareDns'
      traefik.http.routers.dashboard.tls.options: 'minimalTLS13@file'
      traefik.http.routers.api.rule: 'Host(`proxy.domain.com`) && PathPrefix(`/dashboard/`) || PathPrefix(`/api`)'
      traefik.http.routers.api.entrypoints: 'web'
      traefik.http.routers.api.middlewares: 'redirect@file'

Statping container using hunterlong/statping:v0.80.63

labels:
        traefik.enable: 'true'
        traefik.http.middlewares.statping-sslheaders.headers.SSLHost: 'status.domain.com'
        traefik.http.middlewares.statping-sslheaders.headers.SSLRedirect: 'true'
        traefik.http.routers.statping.rule: 'Host(`status.domain.com`)'
        traefik.http.routers.statping.middlewares: 'contentSecurity@file, redirect@file, statping-sslheaders, sts@file'
        traefik.http.routers.statping.entrypoints: 'websecure'
        traefik.http.routers.statping.tls.certresolver: 'leCloudflareDns'
        traefik.http.routers.statping.tls.options: 'minimalTLS13@file'

I have found that when I deploy the two containers like this, going to status.domain.com will result in the same authentication prompt that proxy.domain.com has, even though it doesn't have one set.

For reference, the Statping app that is forwarded to status.domain.com has both a /dashboard and an /api path.

If I remove the '&& PathPrefix(/dashboard/) || PathPrefix(/api)' portion from the host rule for proxy.domain.com status.domain.com no longer has the authentication prompt while proxy.domain.com does.

It seems like the auth middleware is being pushed with status.domain.com somehow.

I am planning on removing the '&& PathPrefix(/dashboard/) || PathPrefix(/api)' portion of the proxy.domain.com host rule anyways as I don't want it but the fact that it pushes the auth middleware onto my other container is curious.

I don't know if this will help but this is from the network console of my browser after I cancel out of the auth prompt on status.domain.com.

Any help would be appreciated.

Solution was posted on Github by dduportal

Hi, what is the result if you apply parenthesis to the rule to ensure the right operator order:

labels:
      traefik.http.routers.proxy-dashboard-https.rule: 'Host(`proxy.domain.com`) && (PathPrefix(`/dashboard/`) || PathPrefix(`/api`))'

=> without the parenthesis, the PathPrefix('/api') rule is applied "alone" because of operators order: it means that any request matching the pattern http://*/api is matched by the router proxy-dashboard-https /