Host header manipulation when working with API looping

Support Installation and Deployment
, ,
1

I am trying to implement a use case where I require to do host header manupulation while doing API looping.
I have 3 API definitions, where 2 are internal and 1 is public.
API definition, “entrypoint” in listening on path “/” and forwarding the apirequest to “apidefinition-apikey” if there is an “apikey” in query or to the “apidefinition-jwt” if there is a bearer in authorization.

In the api-definition all I am trying to do is implement authorization based on api key and proxy the traffic to “my-api-1.private.example.com”. Is there a way to manupulate target_url based on the host “my-api-1.public.example.com” to “my-api-1.private.example.com” using regex.

apidefinition-entrypoint

apiVersion: tyk.tyk.io/v1alpha1
kind: ApiDefinition
metadata:
  name: apidefinition-entrypoint
  namespace: tyk
spec:
  name: apidefinition-entrypoint
  protocol: http
  use_keyless: true
  active: true
  domain: my-api-1.public.example.com
  proxy:
    target_url: https://foo/
    listen_path: /
    strip_listen_path: false
    preserve_host_header: true
  version_data:
    default_version: default
    not_versioned: true
    versions:
      Default:
        name: default
        use_extended_paths: true
        extended_paths: 
          url_rewrites:
            - match_pattern: /(.*)
              method: GET
              path: /{id}
              triggers:
                - "on": "all"
                  options:
                    query_val_matches:
                      "apikey":
                        match_rx: "(.*)"
                  rewrite_to_internal: 
                    target:
                      name: apidefinition-apikey
                      namespace: dst
                    path: apikey/$1&check_limits=true
                - "on": "all"
                  options:
                    header_matches:
                      "Authorization":
                        match_rx: "^Bearer"
                  rewrite_to_internal: 
                    target:
                      name: apidefinition-jwt
                      namespace: dst
                    path: bearer/$1

apidefinition-apikey:

apiVersion: tyk.tyk.io/v1alpha1
kind: ApiDefinition
metadata:
  name: apidefinition-apikey
  namespace: dst
spec:
  name: apidefinition-apikey
  protocol: http
  use_keyless: false
  active: true
  proxy:
    target_url: https://bar/
    listen_path: "/apikey"
    strip_listen_path: true
    preserve_host_header: true
  auth:
    auth_header_name: 'Authorization'
  auth_configs:
    authToken:
      auth_header_name: 'Authorization'
      use_param: true
      param_name: apikey
  base_identity_provided_by: auth_token
  use_standard_auth: true
  internal: true
  version_data:
    default_version: default
    not_versioned: true
    versions:
      Default:
        name: default
        use_extended_paths: true
        extended_paths:
          url_rewrites:
            - match_pattern: /(.*)
              method: GET
              path: /{id}
              rewrite_to: '$tyk_context.headers_Host/$1' <this is rewriting the url to https://bar/(.*), what I need is manipulate host header based on original request and regex>
2

Off the top of my head, you might be able to see the host header after context variables have been extracted in the middleware request chain. Meaning they might be available in URL Rewrite and Post Auth.

So an additional header match for advanced URL rewrite or a custom plugin would do the trick.

However, I see preserve_host_header has been enabled in the API definition. so I am unsure what the result could be.

I would have to try this out.

3

Looks like I missed

rewrite_to: '$tyk_context.headers_Host/$1' <this is rewriting the url to https://bar/(.*), what I need is manipulate host header based on original request and regex>

in my initial through process of the question

So I took a second look at your question and noticed you may just be asking if domain regex is possible.

And yes it is, we have a doc that explains it here