Upgraded to 2.x build - and getting HTTP 421: Misdirected Request

[ned-kelly]

Describe the bug After updating to the latest build in docker, i'm getting a HTTP: 421 code - with the text Misdirected Request...

I've gone and set all the variables (i think)? that's listed here: https://github.com/buzzfeed/sso/releases/tag/v2.0.0

Does anyone else have any pointers to fix, or are familiar with this problem?

Here's a censored clip of my docker-compose file - any comments on anything obvious would be greatly appreciated

version: '3.4'

services:
  # ===========================================================================
  # sso services
  #
  # Here we provide a minimal sso installation that allows company google accounts 
  # to log in. email restrictions to access to upstream services based on Google Group
  # membership should be added to this system as we add more 'secure' applications in the future.
  #
  # The sso-proxy service is handing requests to any domain under
  # *.xxx.co and the sso-auth service is available at sso-auth.xxx.co.
  # ===========================================================================

  sso-proxy:
    image: docker-registry.xxx.co/sso-service:staging
    restart: always

    entrypoint: /bin/sso-proxy
    container_name: sso-proxy
    environment:
      # Allow any google account to log in for demo purposes
      - EMAIL_DOMAIN=xxx.com,xxx.com

      - UPSTREAM_CONFIGS=/sso/upstream_configs.yml
      - PROVIDER_URL_EXTERNAL=https://xxx.xxx.co
      - PROVIDER_URL_INTERNAL=http://sso-auth:4180

      # Set a higher default timeout - to help with those slow GM api responses...
      - SERVER_TIMEOUT_REQUEST=300s

      # 5 minutes - so we can include requests to our 'render' api/service (serverless)
      - DEFAULT_UPSTREAM_TIMEOUT=300s
      - TCP_WRITE_TIMEOUT=330s
      - TCP_READ_TIMEOUT=330s

      # CLIENT_ID and CLIENT_SECRET must match sso-auth's PROXY_CLIENT_ID and
      # PROXY_CLIENT_SECRET configuration
      - CLIENT_ID=xxxxxxxx
      - CLIENT_SECRET=xxxxxxxx

      # Use 'openssl rand -base64 32' when running for the first time
      - AUTH_CODE_SECRET=xxxxxxxx
      - SESSION_COOKIE_SECRET=xxxxxxxx

      # Disable https for demo purposes
      - COOKIE_SECURE=false

      # TODO: these config values should probably have defaults
      - UPSTREAM_CLUSTER=dev
      - STATSD_HOST=127.0.0.1
      - STATSD_PORT=8125

      # Tells nginx-proxy service how to route requests to this service
      - VIRTUAL_HOST=*.xxx.xxx.co
    volumes:
      - ./config/upstream_configs.stage.yml:/sso/upstream_configs.yml:ro
    expose:
      - 4180

    healthcheck:
      test: ps aux | grep -i sso-proxy | grep -v grep
      interval: 30s
      timeout: 10s
      retries: 3

    # Other services we proxy to need to be in the same network for internal communications
    networks:
      - portal-net

  sso-auth:
    image: docker-registry.xxx.co/sso-service:staging

    restart: always

    entrypoint: /bin/sso-auth
    container_name: sso-auth
    environment:
      # Allow any google account to log in for demo purposes
      - AUTHORIZE_EMAIL_DOMAINS=*

      - SERVER_HOST=sso-auth.xxx.co
      - REDIRECT_URL=https://sso-auth.xxx.co
      - AUTHORIZE_PROXY_DOMAINS=xxx.co

      # These values must match sso-proxy's CLIENT_ID and CLIENT_SECRET values
      - PROVIDER_GOOGLE_TYPE=google
      - PROVIDER_GOOGLE_SLUG=google
      - PROVIDER_GOOGLE_CLIENT_ID=xxxxxxxxxxxx
      - PROVIDER_GOOGLE_CLIENT_SECRET=xxxxxxxxxxxx

      - CLIENT_PROXY_ID=xxxxxxxxxxxx
      - CLIENT_PROXY_SECRET=xxxxxxxxxxxx

      # Use same secrets as above
      - SESSION_KEY=xxxxxxxxxxxx
      - SESSION_COOKIE_SECRET=xxxxxxxxxxxx

      # Disable https for demo purposes
      - SESSION_COOKIE_SECURE=false

      # TODO: these config values should probably have defaults
      - CLUSTER=dev
      - STATSD_HOST=127.0.0.1
      - STATSD_PORT=8125

      # Allows passing through the role's "groups" associated with the account -- https://github.com/buzzfeed/sso/blob/master/docs/google_provider_setup.md
      - PROVIDER_GOOGLE_GOOGLE_IMPERSONATE=admin-email@xxx.com
      - PROVIDER_GOOGLE_GOOGLE_CREDENTIALS=/sso/xxx.json

      # Tells nginx-proxy service how to route requests to this service
      - VIRTUAL_HOST=sso-auth.xxx.co,sso-auth:4180
    expose:
      - 4180

    volumes:
      - ./config/xxx.json:/sso/xxx.json:ro

    healthcheck:
      test: ps aux | grep -i sso-auth | grep -v grep
      interval: 30s
      timeout: 10s
      retries: 3

    networks:
      - portal-net

  # ===========================================================================
  # nginx-proxy handles routing of requests to the sso-proxy and sso-auth
  # containers.  See its docs for more info:
  # https://github.com/jwilder/nginx-proxy
  # ===========================================================================

  nginx-proxy:
    restart: always
    container_name: nginx-proxy
    image: jwilder/nginx-proxy:0.8.0
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - ./config/nginx-proxy-config/custom_proxy_settings.conf:/etc/nginx/conf.d/custom_proxy_settings.conf

    networks:
      - portal-net

  # Caddy webserver is used to auto-enable letsencrypt in front of the service so we don't need to always renew the SSL certificate....
  # It talks to the nginx proxy which contains all the main config for SSO proxying...

  caddy-proxy:
    image: bushrangers/alpine-caddy:latest
    container_name: caddy-proxy
    restart: always
    privileged: true

    networks:
      - portal-net

    ports:
      - "80:80"
      - "443:443"

    volumes:
      - ./config/Caddyfile.stage:/etc/Caddyfile
      - ./.caddy:/root/.caddy

    healthcheck:
      test: 'netstat -an | grep 80 > /dev/null; if [ 0 != $$? ]; then exit 1; fi;'
      interval: 30s
      start_period: 2m
      timeout: 5s
      retries: 3

networks:
  portal-net:
    external: true

[benjsto]

Hey @ned-kelly, thanks for submitting this. Is it possible for you to give a little more context around what requests are resulting in 421 responses?

[ned-kelly]

Hi @benjsto - so every request is getting this unfortunately - a HTTP Get for / will do the trick - I'm not even getting the SSO login page which is odd to say the least ... I've updated all the sso-auth variables to match the new 2.X environment variables so I'm a bit lost as to what else it could be .... there's nothing in the logs for either process.

[wyldsteed]

@ned-kelly what was your resolution I am seeing similar results after updating the provider_url environment setting to provider_url_external