Not able to access api(with key and keyless)

Hi Team,

I am facing 2 issues while testing tyk-oss and not able to test tyk features.

Environment details:
tried in 2 deployments
Deployement1) Kubernates: private 3 node kubernates cluster as given below:
[root@master-node TykPoc]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
master-node Ready control-plane 9d v1.28.2
worker-node1 Ready 9d v1.28.2
worker-node2 Ready 9d v1.28.2

tyk-deployement: installed tyk and redis(using simple-redis)from tyk-helm/tyk-oss chart given in *****ce-helm-chart-new
[root@master-node TykPoc]# kubectl get pods -n=tyk
NAME READY STATUS RESTARTS AGE
gateway-tyk-oss-tyk-gateway-7cf57f9dd4-wbrp4 1/1 Running 0 15m
redis-dcbf66675-8pxkd 1/1 Running 0 3h33m
[root@master-node TykPoc]# kubectl get services -n=tyk
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
gateway-svc-tyk-oss-tyk-gateway NodePort 10.110.11.45 8080:30315/TCP 128m
redis ClusterIP 10.104.86.8 6379/TCP 3h33m

Deployment2) docker install as given below from tyk-gateway-docker git repo
[root@master-node ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c56c6909c855 ************:v5.1.0 “/opt/tyk-gateway/ty…” 20 minutes ago Up 20 minutes 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp tyk-gateway-docker_tyk-gateway_1
a6bb8da0006b redis:6.2.7-alpine “docker-entrypoint.s…” 20 minutes ago Up 20 minutes 0.0.0.0:6379->6379/tcp, :::6379->6379/tcp tyk-gateway-docker_tyk-redis_1

Health of gateway:
[root@master-node Tyk]# curl localhost:8080/hello
{“status”:“pass”,“version”:“5.1.0”,“description”:“Tyk GW”,“details”:{“redis”:{“status”:“pass”,“componentType”:“datastore”,“time”:“2023-10-06T09:49:39Z”}}}

ISSUE-1: Test on internal organizational api(/operation/rests) with username:passsword
**Working Case:**it is working fine when I create api def with keyless in tyk as given below:
API Def:
curl -v -H “x-tyk-authorization: foo”
-s
-H “Content-Type: application/json”
-X POST
-d ‘{
“name”: “internal-api”,
“api_id”: “internal-api”,
“org_id”: “1”,
“use_keyless”: true,
“auth”: {
“auth_header_name”: “Authorization”
},
“definition”: {
“location”: “header”,
“key”: “x-api-version”
},
“version_data”: {
“not_versioned”: true,
“versions”: {
“Default”: {
“name”: “Default”,
“use_extended_paths”: true
}
}
},
“proxy”: {
“listen_path”: “/internal-api/”,
“target_url”: “http://:8181/rests/operations”,
“strip_listen_path”: true
},
“active”: true
}’ *****:8080/tyk/apis | python -mjson.tool
Result:{
“action”: “added”,
“key”: “internal-api”,
“status”: “ok”
}

access of API is fine:
Hot reload:
[root@master-node TykPoc]# curl -H “x-tyk-authorization: foo” -s ****8080/tyk/reload/group | python -mjson.tool
{
“message”: “”,
“status”: “ok”
}

API-Access
[root@master-node TykPoc]# curl localhost:8080/internal-api/ -u admin:admin
{“ietf-restconf:operations”:{“ss-olt:write”:[null],“ss-device-system-info:read”:[null],“h-pon-dataservice:delete”:[null],
“1-run-cli:execute”:[null],“q-inventory:device-delete”:[null],"ietf-netconf:close…

Non Working case:
when I try to create api def with key as given below:
API Def:
curl -v -H “x-tyk-authorization: foo”
-s
-H “Content-Type: application/json”
-X POST
-d ‘{
“name”: “internal-api-secure”,
“api_id”: “internal-api-secure”,
“org_id”: “1”,
“auth”: {
“auth_header_name”: “Authorization”
},
“definition”: {
“location”: “header”,
“key”: “x-api-version”
},
“version_data”: {
“not_versioned”: true,
“versions”: {
“Default”: {
“name”: “Default”,
“use_extended_paths”: true
}
}
},
“proxy”: {
“listen_path”: “/internal-api-secure/”,
“target_url”: “http://:8181/rests/operations”,
“strip_listen_path”: true
},
“active”: true
}’ ***:8080/tyk/apis | python -mjson.tool

Result:
{
“action”: “added”,
“key”: “internal-api-secure”,
“status”: “ok”
}

Hot Reload:
[root@master-node TykPoc]# curl -H “x-tyk-authorization: foo” -s ***8080/tyk/reload/group | python -mjson.tool
{
“message”: “”,
“status”: “ok”
}

API-Key Creation:
curl -X POST -H “x-tyk-authorization: foo”
-s
-H “Content-Type: application/json”
-X POST
-d ‘{
“allowance”: 1000,
“rate”: 1000,
“per”: 1,
“expires”: -1,
“quota_max”: -1,
“org_id”: “1”,
“quota_renews”: 1449051461,
“quota_remaining”: -1,
“quota_renewal_rate”: 60,
“access_rights”: {
“internal-api-secure”: {
“api_id”: “internal-api-secure”,
“api_name”: “internal-api-secure”,
“versions”: [“Default”]
}
},
“meta_data”: {}
}’ ***8080/tyk/keys/create | python -mjson.tool

Key Details:
{
“action”: “added”,
“key”: “1bdc9c05bafd14c8d84966b9d1cc94f03”,
“key_hash”: “9293fc56”,
“status”: “ok”
}

Policy Details:
[root@master-node ~]# curl -H “x-tyk-authorization:foo” localhost:8080/tyk/policies | python -mjson.tool
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 897 100 897 0 0 157k 0 --:–:-- --:–:-- --:–:-- 175k
[
{
“_id”: “”,
“access_rights”: {
“internal-api-secure”: {
“allowance_scope”: “”,
“allowed_types”: null,
“allowed_urls”: null,
“api_id”: “internal-api-secure”,
“api_name”: “internal-api-secure”,
“disable_introspection”: false,
“field_access_rights”: null,
“limit”: {
“max_query_depth”: 0,
“per”: 0,
“quota_max”: 0,
“quota_remaining”: 0,
“quota_renewal_rate”: 0,
“quota_renews”: 0,
“rate”: 0,
“throttle_interval”: 0,
“throttle_retry_limit”: 0
},
“restricted_types”: null,
“versions”: [
“Default”
]
}
},
“active”: true,
“enable_http_signature_validation”: false,
“graphql_access_rights”: null,
“hmac_enabled”: false,
“id”: “”,
“is_inactive”: false,
“key_expires_in”: 0,
“last_updated”: “”,
“max_query_depth”: 0,
“meta_data”: null,
“name”: “”,
“org_id”: “1”,
“partitions”: {
“acl”: false,
“complexity”: false,
“per_api”: false,
“quota”: false,
“rate_limit”: false
},
“per”: 1,
“quota_max”: 100,
“quota_renewal_rate”: 60,
“rate”: 1000,
“tags”: null,
“throttle_interval”: 0,
“throttle_retry_limit”: 0
}
]

Hot-Reload:
[root@master-node ~]# curl -H “x-tyk-authorization: foo” -s ***8080/tyk/reload/group | python -mjson.tool
{
“message”: “”,
“status”: “ok”
}

Error in API access:
[root@master-node ~]# curl localhost:8080/internal-api-secure/ --digest -u admin:admin -H ‘Authorization:1bdc9c05bafd14c8d84966b9d1cc94f03’ -v

  • About to connect() to localhost port 8080 (#0)
  • Trying ::1…
  • Connected to localhost (::1) port 8080 (#0)
  • Server auth using Digest with user ‘admin’

GET /internal-api-secure/ HTTP/1.1
User-Agent: curl/7.29.0
Host: localhost:8080
Accept: /
Authorization:1bdc9c05bafd14c8d84966b9d1cc94f03

< HTTP/1.1 401 Unauthorized
< Content-Length: 0
< Www-Authenticate: BASIC realm=“application”
< X-Ratelimit-Limit: -1
< X-Ratelimit-Remaining: -1
< X-Ratelimit-Reset: 1696589243
< Date: Fri, 06 Oct 2023 10:49:13 GMT
<

  • Connection #0 to host localhost left intact
    [root@master-node ~]#

tyk configuration:
{
“log_level”: “info” ,
“listen_port”: 8080,
“secret”: “352d20ee67be67f6340b4c0605b044b7”,
“template_path”: “/opt/tyk-gateway/templates”,
“tyk_js_path”: “/opt/tyk-gateway/js/tyk.js”,
“middleware_path”: “/opt/tyk-gateway/middleware”,
“use_db_app_configs”: false,
“app_path”: “/opt/tyk-gateway/apps/”,
“storage”: {
“type”: “redis”,
“host”: “tyk-redis”,
“port”: 6379,
“username”: “”,
“password”: “”,
“database”: 0,
“optimisation_max_idle”: 2000,
“optimisation_max_active”: 4000
},
“enable_analytics”: false,
“analytics_config”: {
“type”: “”,
“ignored_ips”:
},
“health_check”: {
“enable_health_checks”: false,
“health_check_value_timeouts”: 60
},
“optimisations_use_async_session_write”: false,
“enable_non_transactional_rate_limiter”: true,
“enable_sentinel_rate_limiter”: false,
“enable_redis_rolling_limiter”: false,
“allow_master_keys”: false,
“policies”: {
“policy_source”: “file”,
“policy_record_name”: “/opt/tyk-gateway/policies/policies.json”
},
“hash_keys”: true,
“close_connections”: false,
“http_server_options”: {
“enable_websockets”: true
},
“allow_insecure_configs”: true,
“coprocess_options”: {
“enable_coprocess”: true,
“coprocess_grpc_server”: “”
},
“enable_bundle_downloader”: true,
“bundle_base_url”: “”,
“global_session_lifetime”: 100,
“force_global_session_lifetime”: false,
“max_idle_connections_per_host”: 500,
“enable_jsvm”: true,
“enable_hashed_keys_listing”: true,
“log_level”: “debug”
}

tyk-debug-logs:

NOTE: We are not able to access API by key.

ISSUE2: I tried API testing with local http server , for that even keyless is not working.

local http server details:
[root@master-node ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-7c5ddbdf54-gf2z4 1/1 Running 0 24h
[root@master-node ~]# cat nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

[root@master-node ~]# cat nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
name: ngnix-service
spec:
selector:
app: nginx
type: NodePort
ports:

  • protocol: TCP
    port: 80
    targetPort: 80
    [root@master-node ~]# kubectl get services
    NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
    kubernetes ClusterIP 10.96.0.1 443/TCP 9d
    ngnix-service NodePort 10.97.252.227 80:32305/TCP 24h
    [root@master-node ~]# kubectl get deployments.apps
    NAME READY UP-TO-DATE AVAILABLE AGE
    nginx 1/1 1 1 24h

Able to access locally:
[root@master-node ~]# curl ngnix-service:32305

Welcome to nginx! html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; }

Welcome to nginx!

If you see this page, the nginx web server is successfully installed and working. Further configuration is required.

For online documentation and support please refer to nginx.org.
Commercial support is available at nginxcom.

Thank you for using nginx.

[root@master-node ~]#

NOTE: when we try to access with tyk gate way it is giving error:

API Creation Details:
[root@master-node ~]# curl -v -H “x-tyk-authorization: foo” \

-s
-H “Content-Type: application/json”
-X POST
-d ‘{
“name”: “http-server3”,
“slug”: “http-server3”,
“api_id”: “http-server3”,
“org_id”: “1”,
“use_keyless”: true,
“auth”: {
“auth_header_name”: “Authorization”
},
“definition”: {
“location”: “header”,
“key”: “x-api-version”
},
“version_data”: {
“not_versioned”: true,
“versions”: {
“Default”: {
“name”: “Default”,
“use_extended_paths”: true
}
}
},
“proxy”: {
“listen_path”: “/http-server3/”,
“target_url”: “***:32305”,
“strip_listen_path”: true
},
“active”: true
}’ localhost:8080/tyk/apis | python -mjson.tool

  • About to connect() to localhost port 8080 (#0)
  • Trying ::1…
  • Connected to localhost (::1) port 8080 (#0)

POST /tyk/apis HTTP/1.1
User-Agent: curl/7.29.0
Host: localhost:8080
Accept: /
x-tyk-authorization: foo
Content-Type: application/json
Content-Length: 621

} [data not shown]

  • upload completely sent off: 621 out of 621 bytes
    < HTTP/1.1 200 OK
    < Content-Type: application/json
    < Date: Fri, 06 Oct 2023 11:03:35 GMT
    < Content-Length: 54
    <
    { [data not shown]
  • Connection #0 to host localhost left intact
    {
    “action”: “added”,
    “key”: “http-server3”,
    “status”: “ok”
    }
    [root@master-node ~]# curl -H “x-tyk-authorization: foo” -s localhost:8080/tyk/reload/group | python -mjson.tool {
    “message”: “”,
    “status”: “ok”
    }

ERROR:
root@master-node ~]# curl localhost:8080/http-server3/ -v

  • About to connect() to localhost port 8080 (#0)
  • Trying ::1…
  • Connected to localhost (::1) port 8080 (#0)

GET /http-server3/ HTTP/1.1
User-Agent: curl/7.29.0
Host: localhost:8080
Accept: /

< HTTP/1.1 500 Internal Server Error
< Content-Type: application/json
< X-Generator: tykio
< Date: Fri, 06 Oct 2023 11:04:46 GMT
< Content-Length: 59
<
{
“error”: “There was a problem proxying the request”

  • Connection #0 to host localhost left intact
    tyk-debug-log: will attach in reply

Kindly looks into the issue as we are evaluating the product for internal usage but are stuck for basic testing.
Thanks in advance!
NOTE: I HAVE REPLACED SOME IP AND URL WITH *** BECAUSE OF LINK LIMITs FOR POSTING THE ISSUE.

Please find the tyk-debug log for case 2

Hello @KAPIL_GUPTA and welcome to the community :partying_face:

The thread was long and I haven’t thoroughly looked at it but I don’t see any issues from Tyk with this screenshot. The outbound URL shows it’s leaving Tyk and heading upstream

There seems to be an issue here with the outbound URL

If you are running from a containerized deployment like docker, then you may want to ensure the upstream endpoint uses host.docker.internal

Hi Olu,

I really appreciate your quick reply.

In first case there is no problem in logs but when I try to access API, I am getting Unauthorized as given below:
[root@master-node ~]# curl localhost:8080/internal-api-secure/ --digest -u admin:admin -H ‘Authorization:1bdc9c05bafd14c8d84966b9d1cc94f03’ -v

  • About to connect() to localhost port 8080 (#0)
  • Trying ::1…
  • Connected to localhost (::1) port 8080 (#0)
  • Server auth using Digest with user ‘admin’

GET /internal-api-secure/ HTTP/1.1
User-Agent: curl/7.29.0
Host: localhost:8080
Accept: /
Authorization:1bdc9c05bafd14c8d84966b9d1cc94f03

< HTTP/1.1 401 Unauthorized
< Content-Length: 0
< Www-Authenticate: BASIC realm=“application”
< X-Ratelimit-Limit: -1
< X-Ratelimit-Remaining: -1
< X-Ratelimit-Reset: 1696589243
< Date: Fri, 06 Oct 2023 10:49:13 GMT
<

  • Connection #0 to host localhost left intact

Seconds case, I am facing issues with public URLs or any local http service even with keyless but ,first case is passing with keyless(where I am using internal org APIs).
I even tried with host.docker.internal entry as well as given below:
root@654779f19b96:/opt/tyk-gateway# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.1 host.docker.internal
172.27.0.3 654779f19b96

docker-compose file changes:
extra_hosts:
- “host.docker.internal:host-gateway”

But issue is same. Kindly help me in resolving it.

Reagrds,
Kapil

Can you try using the new auth_configs instead of auth field

  "auth_configs": {
    "authToken": {
      "auth_header_name": "Authorization"
    }
  }

Also, can you specify the auth type for standard authentication? For more information about authentication properties for API definition please visit auth type flags

{
  "use_standard_auth": true
}

If it doesn’t work can you share the result from the GET API Definition call?

GET /tyk/apis/{{api_id}} HTTP/1.1
Host: {{GATEWAY_ENDPOINT}}
x-tyk-authorization: {{GATEWAY_SECRET}}

For this can you try setting httpbin.org as the target URL? The /anything subpath is a good troubleshooting endpoint

or

Try setting the gateway liveness endpoint (/hello) as the target URL and share the result.

Health of gateway:
[root@master-node Tyk]# curl localhost:8080/hello
{“status”:“pass”,“version”:“5.1.0”,“description”:“Tyk GW”,“details”:{“redis”:{“status”:“pass”,“componentType”:“datastore”,“time”:“2023-10-06T09:49:39Z”}}}

First Case: I tried the suggested config but no luck for me.
Please find the get API output as requested:
[root@master-node ~]# curl localhost:8080/tyk/apis/internal-api-secure-2/ -H ‘x-tyk-authorization: foo’| jq ‘.’
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5759 0 5759 0 0 1021k 0 --:–:-- --:–:-- --:–:-- 1124k
{
“name”: “internal-api-secure-2”,
“slug”: “”,
“listen_port”: 0,
“protocol”: “”,
“enable_proxy_protocol”: false,
“api_id”: “internal-api-secure-2”,
“org_id”: “1”,
“use_keyless”: false,
“use_oauth2”: false,
“external_oauth”: {
“enabled”: false,
“providers”: null
},
“use_openid”: false,
“openid_options”: {
“providers”: null,
“segregate_by_client”: false
},
“oauth_meta”: {
“allowed_access_types”: null,
“allowed_authorize_types”: null,
“auth_login_redirect”: “”
},
“auth”: {
“name”: “”,
“use_param”: false,
“param_name”: “”,
“use_cookie”: false,
“cookie_name”: “”,
“disable_header”: false,
“auth_header_name”: “”,
“use_certificate”: false,
“validate_signature”: false,
“signature”: {
“algorithm”: “”,
“header”: “”,
“use_param”: false,
“param_name”: “”,
“secret”: “”,
“allowed_clock_skew”: 0,
“error_code”: 0,
“error_message”: “”
}
},
“auth_configs”: {
“authToken”: {
“name”: “”,
“use_param”: false,
“param_name”: “”,
“use_cookie”: false,
“cookie_name”: “”,
“disable_header”: false,
“auth_header_name”: “Authorization”,
“use_certificate”: false,
“validate_signature”: false,
“signature”: {
“algorithm”: “”,
“header”: “”,
“use_param”: false,
“param_name”: “”,
“secret”: “”,
“allowed_clock_skew”: 0,
“error_code”: 0,
“error_message”: “”
}
}
},
“use_basic_auth”: false,
“basic_auth”: {
“disable_caching”: false,
“cache_ttl”: 0,
“extract_from_body”: false,
“body_user_regexp”: “”,
“body_password_regexp”: “”
},
“use_mutual_tls_auth”: false,
“client_certificates”: null,
“upstream_certificates”: null,
“pinned_public_keys”: null,
“enable_jwt”: false,
“use_standard_auth”: true,
“use_go_plugin_auth”: false,
“enable_coprocess_auth”: false,
“custom_plugin_auth_enabled”: false,
“jwt_signing_method”: “”,
“jwt_source”: “”,
“jwt_identity_base_field”: “”,
“jwt_client_base_field”: “”,
“jwt_policy_field_name”: “”,
“jwt_default_policies”: null,
“jwt_issued_at_validation_skew”: 0,
“jwt_expires_at_validation_skew”: 0,
“jwt_not_before_validation_skew”: 0,
“jwt_skip_kid”: false,
“scopes”: {
“jwt”: {},
“oidc”: {}
},
“jwt_scope_to_policy_mapping”: null,
“jwt_scope_claim_name”: “”,
“notifications”: {
“shared_secret”: “”,
“oauth_on_keychange_url”: “”
},
“enable_signature_checking”: false,
“hmac_allowed_clock_skew”: 0,
“hmac_allowed_algorithms”: null,
“request_signing”: {
“is_enabled”: false,
“secret”: “”,
“key_id”: “”,
“algorithm”: “”,
“header_list”: null,
“certificate_id”: “”,
“signature_header”: “”
},
“base_identity_provided_by”: “”,
“definition”: {
“enabled”: false,
“name”: “”,
“default”: “”,
“location”: “header”,
“key”: “x-api-version”,
“strip_path”: false,
“strip_versioning_data”: false,
“versions”: null
},
“version_data”: {
“not_versioned”: true,
“default_version”: “”,
“versions”: {
“Default”: {
“name”: “Default”,
“expires”: “”,
“paths”: {
“ignored”: null,
“white_list”: null,
“black_list”: null
},
“use_extended_paths”: true,
“extended_paths”: {
“persist_graphql”: null
},
“global_headers”: null,
“global_headers_remove”: null,
“global_response_headers”: null,
“global_response_headers_remove”: null,
“ignore_endpoint_case”: false,
“global_size_limit”: 0,
“override_target”: “”
}
}
},
“uptime_tests”: {
“check_list”: null,
“config”: {
“expire_utime_after”: 0,
“service_discovery”: {
“use_discovery_service”: false,
“query_endpoint”: “”,
“use_nested_query”: false,
“parent_data_path”: “”,
“data_path”: “”,
“port_data_path”: “”,
“target_path”: “”,
“use_target_list”: false,
“cache_disabled”: false,
“cache_timeout”: 0,
“endpoint_returns_list”: false
},
“recheck_wait”: 0
}
},
“proxy”: {
“preserve_host_header”: false,
“listen_path”: “/internal-api-secure-2/”,
“target_url”: “http://******:8181/rests/operations”,
“disable_strip_slash”: false,
“strip_listen_path”: true,
“enable_load_balancing”: false,
“target_list”: null,
“check_host_against_uptime_tests”: false,
“service_discovery”: {
“use_discovery_service”: false,
“query_endpoint”: “”,
“use_nested_query”: false,
“parent_data_path”: “”,
“data_path”: “”,
“port_data_path”: “”,
“target_path”: “”,
“use_target_list”: false,
“cache_disabled”: false,
“cache_timeout”: 0,
“endpoint_returns_list”: false
},
“transport”: {
“ssl_insecure_skip_verify”: false,
“ssl_ciphers”: null,
“ssl_min_version”: 0,
“ssl_max_version”: 0,
“ssl_force_common_name_check”: false,
“proxy_url”: “”
}
},
“disable_rate_limit”: false,
“disable_quota”: false,
“custom_middleware”: {
“pre”: null,
“post”: null,
“post_key_auth”: null,
“auth_check”: {
“disabled”: false,
“name”: “”,
“path”: “”,
“require_session”: false,
“raw_body_only”: false
},
“response”: null,
“driver”: “”,
“id_extractor”: {
“disabled”: false,
“extract_from”: “”,
“extract_with”: “”,
“extractor_config”: null
}
},
“custom_middleware_bundle”: “”,
“custom_middleware_bundle_disabled”: false,
“cache_options”: {
“cache_timeout”: 0,
“enable_cache”: false,
“cache_all_safe_requests”: false,
“cache_response_codes”: null,
“enable_upstream_cache_control”: false,
“cache_control_ttl_header”: “”,
“cache_by_headers”: null
},
“session_lifetime”: 0,
“active”: true,
“internal”: false,
“auth_provider”: {
“name”: “”,
“storage_engine”: “”,
“meta”: null
},
“session_provider”: {
“name”: “”,
“storage_engine”: “”,
“meta”: null
},
“event_handlers”: {
“events”: null
},
“enable_batch_request_support”: false,
“enable_ip_whitelisting”: false,
“allowed_ips”: null,
“enable_ip_blacklisting”: false,
“blacklisted_ips”: null,
“dont_set_quota_on_create”: false,
“expire_analytics_after”: 0,
“response_processors”: null,
“CORS”: {
“enable”: false,
“allowed_origins”: null,
“allowed_methods”: null,
“allowed_headers”: null,
“exposed_headers”: null,
“allow_credentials”: false,
“max_age”: 0,
“options_passthrough”: false,
“debug”: false
},
“domain”: “”,
“certificates”: null,
“do_not_track”: false,
“enable_context_vars”: false,
“config_data”: null,
“config_data_disabled”: false,
“tag_headers”: null,
“global_rate_limit”: {
“rate”: 0,
“per”: 0
},
“strip_auth_data”: false,
“enable_detailed_recording”: false,
“graphql”: {
“enabled”: false,
“execution_mode”: “”,
“version”: “”,
“schema”: “”,
“type_field_configurations”: null,
“playground”: {
“enabled”: false,
“path”: “”
},
“engine”: {
“field_configs”: null,
“data_sources”: null
},
“proxy”: {
“auth_headers”: null,
“request_headers”: null
},
“subgraph”: {
“sdl”: “”
},
“supergraph”: {
“subgraphs”: null,
“merged_sdl”: “”,
“global_headers”: null,
“disable_query_batching”: false
}
},
“analytics_plugin”: {},
“tags”: null

Second Case: It is passing for /hello as given below and also for /anything on http**.org
[root@master-node ~]# curl localhost:8080/http-server4/
{“status”:“pass”,“version”:“5.1.0”,“description”:“Tyk GW”,“details”:{“redis”:{“status”:“pass”,“componentType”:“datastore”,“time”:“2023-10-10T05:12:02Z”}}}

[root@master-node ~]# curl localhost:8080/http-server5/
{
“args”: {},
“data”: “”,
“files”: {},
“form”: {},
“headers”: {
“Accept”: “/”,
“Accept-Encoding”: “gzip”,
“Host”: “http**.org”,
“User-Agent”: “curl/7.29.0”,
“X-Amzn-Trace-Id”: “Root=1-6524de21-61d22f0f0abb2b8a6c7788b7”
},
“json”: null,
“method”: “GET”,
“origin”: “172.27.0.1, 68.140.239.132”,
“url”: “http**://http**.org/anything”
}

But it is not working for local url as given below:
}[root@master-node ~]# curl localhost:8080/http-server3/ -v

  • About to connect() to localhost port 8080 (#0)
  • Trying ::1…
  • Connected to localhost (::1) port 8080 (#0)

GET /http-server3/ HTTP/1.1
User-Agent: curl/7.29.0
Host: localhost:8080
Accept: /

< HTTP/1.1 500 Internal Server Error
< Content-Type: application/json
< X-Generator: tyk*io
< Date: Tue, 10 Oct 2023 05:17:47 GMT
< Content-Length: 59
<
{
“error”: “There was a problem proxying the request”

  • Connection #0 to host localhost left intact

Debug logs:
time=“Oct 10 05:17:47” level=debug msg=Started api_id=http-server3 api_name=http-server3 mw=VersionCheck org_id=1 origin=172.27.0.1 path=/http-server3/ ts=1696915067818213956
time=“Oct 10 05:17:47” level=debug msg=Finished api_id=http-server3 api_name=http-server3 code=200 mw=VersionCheck ns=39599 org_id=1 origin=172.27.0.1 path=/http-server3/
time=“Oct 10 05:17:47” level=debug msg=Started api_id=http-server3 api_name=http-server3 mw=RateCheckMW org_id=1 origin=172.27.0.1 path=/http-server3/ ts=1696915067818271238
time=“Oct 10 05:17:47” level=debug msg=Finished api_id=http-server3 api_name=http-server3 code=200 mw=RateCheckMW ns=27473 org_id=1 origin=172.27.0.1 path=/http-server3/
time=“Oct 10 05:17:47” level=debug msg=“Started proxy”
time=“Oct 10 05:17:47” level=debug msg=“Stripping proxy listen path: /http-server3/”
time=“Oct 10 05:17:47” level=debug msg=“Upstream path is: /”
time=“Oct 10 05:17:47” level=debug msg=Started api_id=http-server3 api_name=http-server3 mw=ReverseProxy org_id=1 ts=1696915067818325874
time=“Oct 10 05:17:47” level=debug msg=“Upstream request URL: /” api_id=http-server3 api_name=http-server3 mw=ReverseProxy org_id=1
time=“Oct 10 05:17:47” level=debug msg=“Outbound request URL: http://localhost:32305” api_id=http-server3 api_name=http-server3 mw=ReverseProxy org_id=1
time=“Oct 10 05:17:47” level=error msg=“http: proxy error: dial tcp 127.0.0.1:32305: connect: connection refused” api_id=http-server3 api_name=http-server3 mw=ReverseProxy org_id=1 prefix=proxy server_name=“localhost:32305” user_id=-- user_ip=172.27.0.1 user_name=
time=“Oct 10 05:17:47” level=debug msg=Finished api_id=http-server3 api_name=http-server3 mw=ReverseProxy ns=481750 org_id=1
time=“Oct 10 05:17:47” level=debug msg=“Upstream request took (ms): 0.495388”
time=“Oct 10 05:17:47” level=debug msg=“Done proxy”

But direct access for that API is working fine:
[root@master-node ~]# curl localhost:32305

Welcome to nginx!

NOTE: In second case even with key it is working but not sure in other public URLs or local http URL it is not working.

Hi,

This shows that your upstream is not listening on the localhost interface. Localhost inside the docker container is different from localhost outside it. Inside the docker container it’s the loopback interface of that container, outside it’s the loopback interface of the machine running the container. So unless your upstream is running inside the docker container that it running tyk then this cannot work.

Cheers,
Pete

Hi Pete,

But in my case it is working for httpbin.org/anything, not able to get the root cause of local not working.

BR,
Kapil

Hi,

Just so that I can be sure that I understand, you’re saying that when you set the API’s target_url to httpbin.org the API works, but when you set it to localhost it doesn’t?

We can see from the logs that when you use localhost:32305 you get a connection refused, so I think I’ve understood correctly but please correct me if I’m wrong.

Connection refused is happening because localhost is a relative address. It’s like the term ‘next door’. My next door is different to yours even though the words are the same. Localhost on the machine running docker is different from localhost inside a docker container where Tyk is running. There isn’t an easy way for something in the docker container to access localhost on the the machine running the container. But that’s what the localhost interface was designed for, to restrict access to the local host.

The docker container is like a mini virtual machine with it’s own localhost and no access to the enclosing localhost or localhost on any other machine, VM or docker container.

This is not a Tyk restriction but fundamental to how network interfaces work.

On my local system, if I want to publish a service that my docker containers can access I bind that to the real IP address of my machine not to localhost. My machine has an IP address of 10.0.0.24 so if I bind a service to that I can access it via that IP address in my docker containers. But the downside is that anything on my local network can access my IP address so there are security implications. Please be careful.

The core problem is that the API is configured to proxy to an address that’s not listening. Tyk is doing exactly what it’s been asked to do but there’s nothing listening so it gets its connection refused. As soon as that service is made available to Tyk and the API is configured to the right address it will work just as it does with httpbin.

Cheers,
Pete

I have imported your shared API definition and the standard auth works fine You can test this by putting a non-auth upstream and it would work.

I see from your earlier curl that you have a --digest -u admin:admin. I assume this would mean that your upstream is auth-protected with some form of basic auth. I am not familiar with digest auth, so could you try using basic auth instead to test?

As for the second case, Pete has given a very insightful explanation. I hope it was helpful.