List Policies returning incorrect policies

Support
,
1

We’re using Tyk 4.1.0 (OSS) with pretty much everything defaulted. When I look in the /opt/tyk-gateway/polices directory I see a single policy that is the ‘default’ policy that I have seen in earlier versions.
When I call the tyk/policies endpoint however I get:

[
    {
        "_id": "",
        "id": "",
        "name": "",
        "org_id": "",
        "rate": 0,
        "per": 0,
        "quota_max": 0,
        "quota_renewal_rate": 0,
        "throttle_interval": 0,
        "throttle_retry_limit": 0,
        "max_query_depth": 0,
        "access_rights": null,
        "hmac_enabled": false,
        "enable_http_signature_validation": false,
        "active": false,
        "is_inactive": false,
        "tags": null,
        "key_expires_in": 0,
        "partitions": {
            "quota": false,
            "rate_limit": false,
            "complexity": false,
            "acl": false,
            "per_api": false
        },
        "last_updated": "",
        "meta_data": null,
        "graphql_access_rights": null
    }
]

which obviously is not named ‘default’ and doesn’t look like whats in policy.json.

I can add a policy using the tyk/policies POST, and it comes back and says its ok (although it doesn’t have a key)

{
    "key": "",
    "status": "ok",
    "action": "added"
}

Has anyone else seen this? Are we doing something wrong?

2

BTW, just to clarify something - once I (what looks like successfully) add a policy, it does not show up in the LIST policies endpoint - its the same result as when I first ran the endpoint after the initial deploy.

3

Hi @Hank_Birkdale,
Welcome to Tyk Community and thank you for posting your question here.

For your first concern wherein the Policy name is empty, it is because the policies.json doesn’t have a "name" attribute set into it thus it is not returning a name. If you edit the policies.json and put "name" : "PolicyName" and then call the /tyk/policies endpoint, it will return the policy with that name.

As for adding a policy using POST tyk/policies endpoint, I can replicate your issue and it seems that this appears to be a known bug and is currently under discussion.

1 Like
4

Thanks Page. Just to give you an update. We had imported the Tyk swagger file into Postman for the calls, and it looks like the POST policy body is missing the “access_rights” wrapper. When I add in the access_rights wrapper, the CREATE successfully adds an api, a file is successfully created in the policies directory, and LIST policies returns successfully.
I still think this is a bug however, since I technically had a malformed body (no “access rights”) I probably should have been told that - not told that I successfully added a policy. Thanks again.

5

Hi @Hank_Birkdale,
Thanks for the response. I got an update regarding this issue where the bug is indeed from the documentation only and not on the functionality of the gateway. It seems that the reason behind why you can’t successfully POST in /tyk/policies is because you might be using an old configuration option in your tyk.conf which is policies.policy_record_name and this seems to be not documented and also not being used by the github repository. Instead of using this you should use the new option ( "policy_path": "./policies") which should look like the following:

"policies": {
        "policy_source": "file",
        "policy_path": "./policies"
    },

Take note that you also need to specify the "id" in the payload when creating the policy as this is use as the filename in the policy path.

As for the access_rights, how are you making the policy request with access_rights? Note that you need to set access_rights when creating a policy in order to attach it to an API. Here’s a working policy payload I have with access_rights to the API I have:

{
  "id":"policy-fromPostman",
  "name": "policy-fromPostman",
  "quota_max": 60,
  "quota_renewal_rate": 60,
  "allowance": 100,
  "rate": 100,
  "per": 5,
  "org_id": "53ac07777cbb8c2d53000002",
  "access_rights": {
   "fromPostman":{
     "api_name": "fromPostman",
     "api_id": "fromPostman",
     "versions": [
        "Default"
     ]
   }
  }
}
1 Like