external-auth-server: undefined in redirect URL

Trying to make eas work with istio, almost got it working (I will share docs later), but getting undefined appended to redirect URI for some reason, any idea what that may be?

Logs from eas (notice bookinfo.dev.k8s.hal24k.nlundefined):

{"service":"external-auth-server","level":"verbose","message":"parsed state redirect uri: {\"scheme\":\"http\",\"host\":\"bookinfo.dev.k8s.hal24k.nlundefined\",\"path\":\"\",\"reference\":\"absolute\"}"}
{"service":"external-auth-server","level":"verbose","message":"parsed request uri: {\"path\":\"/oauth/callback\",\"query\":\"__eas_oauth_handler__=authorization_callback&code=b06e7a405446796a4ea28f2ab24bf306391745767af1a809215a1017eed9da57&scope=openid%20email%20profile&state=05ee47f92a8f54c2bbdacefeab9691d14b5b2c1b80d2e8ddeeac5f0267f9ad62e4551aa461587aeaf85b295d0d585170745e083ab90d4e39e53bf5e93a456feb204a9af6bb0cea606164fdcab94bc54&session_state=5iumlRGmL2bNBJjetsd9lSLjPHrjZeT5Uwor_TfkGaM.6b769f0d8d051e6b9c81221e413f82a1\",\"reference\":\"relative\"}"}
{"service":"external-auth-server","level":"verbose","message":"parsed redirect uri: {\"scheme\":\"http\",\"host\":\"bookinfo.dev.k8s.hal24k.nlundefined\",\"path\":\"\",\"query\":\"__eas_oauth_handler__=authorization_callback&code=b06e7a405446796a4ea28f2ab24bf306391745767af1a809215a1017eed9da57&scope=openid%20email%20profile&state=05ee47f92a8f54c2bbdacefeab9691d14b5b2c1b80d2e8ddeeac5f0267f9ad62e4551aa461587aeaf85b295cd8cd6b63e8af7e76060fb34f00f21efc08d5dd4995635828e53bf5e93a456feb204a9af6bb0cea606164fdcab94bc54&session_state=5iumlRGmL2bNBJjetsd9lSLjPHrjZeT5Uwor_TfkGaM.6b769f0d8d051e6b9c81221e413f82a1\",\"reference\":\"absolute\"}"}
{"service":"external-auth-server","level":"info","message":"redirecting browser to: \"http://bookinfo.dev.k8s.hal24k.nlundefined/?__eas_oauth_handler__=authorization_callback&

Somewhere here, but not sure exactly what is the problem https://github.com/travisghansen/external-auth-server/blob/8d97265b972ed4f663452368adaf59cd276b5888/src/plugin/oauth/index.js#L140

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 66 (66 by maintainers)

Most upvoted comments

Ok then yeah setting the token on a per tenant filter sounds like the perfect solution. I’ll snap a release and you can try it all out!

LOL I’ve been there! Yeah so I’ll commit my code with the header configuration and then you can use the syntax I mentioned above.

Alternatively, are you using a single oidc provider/instance with the same client_id etc for all tenants? Meaning, is there only ever 1 userN across all tenants? If so, we could get pretty creative with the assertions and have 1 token cover everything.

I’ve confirmed this behavior works FYI:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: auth-filter
#  namespace: istio-ingress
spec:
  filters:
  - filterConfig:
      failure_mode_allow: false
      httpService:
        authorizationRequest:
          allowedHeaders:
            patterns:
            - exact: cookie
            - exact: X-Forwarded-Host
            - exact: X-Forwarded-Method
            - exact: X-Forwarded-Proto
            - exact: X-Forwarded-Uri
          headers_to_add:
            - key: "x-eas-verify-params"
              value: '{"config_token_store_id":"dep_a","config_token_id":"verysecure"}'
#        pathPrefix: /envoy/verify-params-url/%7B%22config_token_store_id%22%3A%22dep_a%22%2C%22config_token_id%22%3A%22verysecure%22%7D
        pathPrefix: /envoy/verify-params-header
        serverUri:
          cluster: outbound|80||eas.default.svc.cluster.local
          timeout: 10s
          uri: http://eas.default.svc.cluster.local
      statusOnError:
        code: Forbidden
      withRequestBody:
        allowPartialMessage: true
        maxRequestBytes: 4096
    filterName: envoy.ext_authz
    filterType: HTTP
    insertPosition:
      index: FIRST
    listenerMatch:
      listenerProtocol: HTTP
      listenerType: GATEWAY
      portNumber: 80
  workloadLabels:
    istio: ingressgateway

This example happens to be using a server-side token, but when using a full config_token with envoy it would be much more readable and also not adding to the potentially giant URL strings making it less likely to hit URL length limits.

Ok thanks for the background info. I’ll see what I can figure out!