matiasinsaurralde · May 4, 2017 10:18
diff --git a/test.json b/test.json
 [  {
    "title": "Token Session Object Details - Tyk Documentation ",
    "article": "\n      Edit on GitHub\n        \n        Token Session Object Details\n              All tokens that are used to access services via Tyk correspond to a session object that informs Tyk about the context of this particular token.\n\nA session object takes the following form:\n\n    {\n        \"last_check\": 0,\n        \"allowance\": 1000,\n        \"rate\": 1000,\n        \"per\": 1,\n        \"expires\": 1458669677,\n        \"quota_max\": 1000,\n        \"quota_renews\": 1458667309,\n        \"quota_remaining\": 1000,\n        \"quota_renewal_rate\": 3600,\n        \"access_rights\": {\n            \"e1d21f942ec746ed416ab97fe1bf07e8\": {\n                \"api_name\": \"Closed\",\n                \"api_id\": \"e1d21f942ec746ed416ab97fe1bf07e8\",\n                \"versions\": [\"Default\"],\n                \"allowed_urls\": null\n            }\n        },\n        \"org_id\": \"53ac07777cbb8c2d53000002\",\n        \"oauth_client_id\": \"\",\n        \"basic_auth_data\": {\n            \"password\": \"\",\n            \"hash_type\": \"\"\n        },\n        \"jwt_data\": {\n            \"secret\": \"\"\n        },\n        \"hmac_enabled\": false,\n        \"hmac_string\": \"\",\n        \"is_inactive\": false,\n        \"apply_policy_id\": \"\",\n        \"data_expires\": 0,\n        \"monitor\": {\n            \"trigger_limits\": null\n        },\n        \"meta_data\": {\n            \"test\": \"test-data\"\n        },\n        \"tags\": [\"tag1\", \"tag2\"],\n        \"alias\": \"[email protected]\" \n    }\n\n\n\nlast_check (deprecated): No longer used, but this value is related to rate limiting.\n\nallowance (deprecated): No longer directly used, this value, no key creation, should be the same as rate.\n\nrate: The number of requests that are allowed in the specified rate limiting window.\n\nper: The number of seconds that the rate window should encompass.\n\nexpires: An epoch that defines when the key should expire.\n\nquota_max: The maximum number of requests allowed during the quota period.\n\nquota_renews: An epoch that defines when the quota renews.\n\nquota_remaining: The number of requests remaining for this user's quota (unrelated to rate limit).\n\nquota_renewal_rate: The time, in seconds. during which the quota is valid. So for 1000 requests per hour, this value would be 3600 while quota_max and quota_remaining would be 1000.\n\naccess_rights: This section is defined in the Access Control section of this documentation, use this section define what APIs and versions this token has access to.\n\norg_id: The organisation this user belongs to, this can be used in conjunction with the org_id setting in the API Definition object to have tokens "owned" by organisations.\n\noauth_client_id: This is set by Tyk if the token is generated by an OAuth client during an OAuth authorisation flow.\n\nbasic_auth_data: This section defines the basic auth password and hashing method.\n\njwt_data: This section contains a JWT shared secret if the ID matches a JWT ID.\n\nhmac_enabled: If this token belongs to an HMAC user, this will set the token as a valid HMAC provider.\n\nhmac_string: The value of the HMAC shared secret.\n\nis_inactive: Set this value to true to deny access.\n\napply_policy_id: The policy ID that is bound to this token.\n\ndata_expires: An value, in seconds, that defines when data generated by this token expires in the analytics DB (must be using Pro edition and MongoDB).\n\nmonitor: Rate monitor trigger settings, defined elsewhere in the documentation.\n\nmeta_data: Meta data to be included as part of the session, this is a key/value string map that can be used in other middleware such as transforms and header injection to embed user-specific data into a request, or alternatively to query the providence of a key.\n\ntags: Tags are embedded into analytics data when the request completes. If a policy has tags, those tags will supersede the ones carried by the token (they will be overwritten).\n\nalias: As of v2.1, an Alias offers a way to identify a token in a more human-readable manner, add an Alias to a token in order to have the data transferred into Analytics later on so you can track both hashed and un-hashed tokens to a meaningful identifier that doesn't expose the security of the underlying token.\n\n\n          \n          \n            \n            \n          \n    "
  },
  {
    "title": "Upgrading to v2.3 from v2.2 - Tyk Documentation ",
    "article": "\n      Edit on GitHub\n        \n        Upgrading to v2.3 from v2.2\n              \n\nTyk v2.3 is backwards-compatible with v2.2 in terms of the configuration file and the original tyk.conf can be used with the new version. If you would like to keep your v2.2 settings, please remember to backup your tyk.conf file before upgrading as it will be overwritten during the upgrade process.\n\nHowever, there are behavioural differences in a v2.3 cluster when hooked up to a Dashboard that can cause some odd behaviour if the upgrade is not conducted in the right order.\n\nTyk v2.3 Gateways continuously talk to each other sharing load data, they also share information with the Dashboard regarding their current configuration. This chatter, if exposed to a v2.2 Gateway, can cause it go into a reload loop, which isn't ideal. Because of this, the recommended upgrade procedure for a Tyk v2.2 system is:\n\n\nUpgrade all the Tyk Gateways to v2.3\nUpgrade the Dashboard to v1.3\nUpdate the Tyk Pump to v0.4\n\n\nIf upgraded in this order, then the reload loop can be avoided on a production system.\n\nIf the reload loop does occur it is not disastrous, Tyk will just keep proxying traffic even though it is constantly pulling new configurations. It's just not particularly efficient.\n\n\nNote for MDCB: If you are using MDCB and want to upgrade your Gateways to v2.3, you will also need to upgrade your MDCB to v1.2.0.2.\n\n\nRetaining rate limiter functionality\n\nTyk v2.3 introduces a new in-memory leaky-bucket distributed rate limiter, this is much more performant than the older rate limiter which hard-synchronised via Redis, and puts far less strain on a Redis instance or cluster than the old rate limiter. By default, Tyk v2.3 will switch to this rate limiter, however it is possible to retain the old behaviour by enabling it explicitly in the tyk.conf file:\n\n    \"enable_redis_rolling_limiter\": true\n\n\nThis might be useful if you do not wish to switch over immediately and wish to test the new rate limiter first.\n\nPublic and Private keys\n\nTyk v2.3 introduces public/private key message authentication for messages that are sent from the management interface to the Gateways, and for code that is being deployed as a plugin to a Gateway via the bundle downloader.\n\nBy default, Tyk's new config file has this feature disabled, however since it is new, an existing tyk.conf will assume a secure installation as the feature must be explicitly disabled. This means, prior to starting your new Gateways, either disable the security feature, or add a public/private key pair to your tyk.conf and tyk_analytics.conf files:\n\nDisable secure messages\n\nIf you are upgrading from v2.2 then you must either generate a public/private keypair or disable the option to validate inbound payloads against a key. You can do this by setting the following key in your tyk.conf:\n\n    \"allow_insecure_configs\": true\n\n\nAdd a public key and private key pair\n\nFirst, generate the key pair:\n\n    # private key\n    openssl genrsa -out privkey.pem 2048\n    \n    # public key\n    openssl rsa -in privkey.pem -pubout -out pubkey.pem\n\n\ntyk.conf:\n\n    \"public_key_path\": \"/path/to/public/key.pem\"\n\n\ntyk_analytics.conf:\n\n    \"private_key_path\": \"/path/to/private/key.pem\"\n\n\nConclusion\n\nThe above are the key changes in v2.3 that could affect your setup and configuration during an upgrade. All other settings should be backwards compatible and not introduce breaking changes.\n\n          \n          \n            \n            \n          \n    "
  }
 ]
	[ {
	"title": "Token Session Object Details - Tyk Documentation ",
	"article": "\n Edit on GitHub\n \n Token Session Object Details\n All tokens that are used to access services via Tyk correspond to a session object that informs Tyk about the context of this particular token.\n\nA session object takes the following form:\n\n {\n \"last_check\": 0,\n \"allowance\": 1000,\n \"rate\": 1000,\n \"per\": 1,\n \"expires\": 1458669677,\n \"quota_max\": 1000,\n \"quota_renews\": 1458667309,\n \"quota_remaining\": 1000,\n \"quota_renewal_rate\": 3600,\n \"access_rights\": {\n \"e1d21f942ec746ed416ab97fe1bf07e8\": {\n \"api_name\": \"Closed\",\n \"api_id\": \"e1d21f942ec746ed416ab97fe1bf07e8\",\n \"versions\": [\"Default\"],\n \"allowed_urls\": null\n }\n },\n \"org_id\": \"53ac07777cbb8c2d53000002\",\n \"oauth_client_id\": \"\",\n \"basic_auth_data\": {\n \"password\": \"\",\n \"hash_type\": \"\"\n },\n \"jwt_data\": {\n \"secret\": \"\"\n },\n \"hmac_enabled\": false,\n \"hmac_string\": \"\",\n \"is_inactive\": false,\n \"apply_policy_id\": \"\",\n \"data_expires\": 0,\n \"monitor\": {\n \"trigger_limits\": null\n },\n \"meta_data\": {\n \"test\": \"test-data\"\n },\n \"tags\": [\"tag1\", \"tag2\"],\n \"alias\": \"[email protected]\" \n }\n\n\n\nlast_check (deprecated): No longer used, but this value is related to rate limiting.\n\nallowance (deprecated): No longer directly used, this value, no key creation, should be the same as rate.\n\nrate: The number of requests that are allowed in the specified rate limiting window.\n\nper: The number of seconds that the rate window should encompass.\n\nexpires: An epoch that defines when the key should expire.\n\nquota_max: The maximum number of requests allowed during the quota period.\n\nquota_renews: An epoch that defines when the quota renews.\n\nquota_remaining: The number of requests remaining for this user's quota (unrelated to rate limit).\n\nquota_renewal_rate: The time, in seconds. during which the quota is valid. So for 1000 requests per hour, this value would be 3600 while quota_max and quota_remaining would be 1000.\n\naccess_rights: This section is defined in the Access Control section of this documentation, use this section define what APIs and versions this token has access to.\n\norg_id: The organisation this user belongs to, this can be used in conjunction with the org_id setting in the API Definition object to have tokens "owned" by organisations.\n\noauth_client_id: This is set by Tyk if the token is generated by an OAuth client during an OAuth authorisation flow.\n\nbasic_auth_data: This section defines the basic auth password and hashing method.\n\njwt_data: This section contains a JWT shared secret if the ID matches a JWT ID.\n\nhmac_enabled: If this token belongs to an HMAC user, this will set the token as a valid HMAC provider.\n\nhmac_string: The value of the HMAC shared secret.\n\nis_inactive: Set this value to true to deny access.\n\napply_policy_id: The policy ID that is bound to this token.\n\ndata_expires: An value, in seconds, that defines when data generated by this token expires in the analytics DB (must be using Pro edition and MongoDB).\n\nmonitor: Rate monitor trigger settings, defined elsewhere in the documentation.\n\nmeta_data: Meta data to be included as part of the session, this is a key/value string map that can be used in other middleware such as transforms and header injection to embed user-specific data into a request, or alternatively to query the providence of a key.\n\ntags: Tags are embedded into analytics data when the request completes. If a policy has tags, those tags will supersede the ones carried by the token (they will be overwritten).\n\nalias: As of v2.1, an Alias offers a way to identify a token in a more human-readable manner, add an Alias to a token in order to have the data transferred into Analytics later on so you can track both hashed and un-hashed tokens to a meaningful identifier that doesn't expose the security of the underlying token.\n\n\n \n \n \n \n \n "
	},
	{
	"title": "Upgrading to v2.3 from v2.2 - Tyk Documentation ",
	"article": "\n Edit on GitHub\n \n Upgrading to v2.3 from v2.2\n \n\nTyk v2.3 is backwards-compatible with v2.2 in terms of the configuration file and the original tyk.conf can be used with the new version. If you would like to keep your v2.2 settings, please remember to backup your tyk.conf file before upgrading as it will be overwritten during the upgrade process.\n\nHowever, there are behavioural differences in a v2.3 cluster when hooked up to a Dashboard that can cause some odd behaviour if the upgrade is not conducted in the right order.\n\nTyk v2.3 Gateways continuously talk to each other sharing load data, they also share information with the Dashboard regarding their current configuration. This chatter, if exposed to a v2.2 Gateway, can cause it go into a reload loop, which isn't ideal. Because of this, the recommended upgrade procedure for a Tyk v2.2 system is:\n\n\nUpgrade all the Tyk Gateways to v2.3\nUpgrade the Dashboard to v1.3\nUpdate the Tyk Pump to v0.4\n\n\nIf upgraded in this order, then the reload loop can be avoided on a production system.\n\nIf the reload loop does occur it is not disastrous, Tyk will just keep proxying traffic even though it is constantly pulling new configurations. It's just not particularly efficient.\n\n\nNote for MDCB: If you are using MDCB and want to upgrade your Gateways to v2.3, you will also need to upgrade your MDCB to v1.2.0.2.\n\n\nRetaining rate limiter functionality\n\nTyk v2.3 introduces a new in-memory leaky-bucket distributed rate limiter, this is much more performant than the older rate limiter which hard-synchronised via Redis, and puts far less strain on a Redis instance or cluster than the old rate limiter. By default, Tyk v2.3 will switch to this rate limiter, however it is possible to retain the old behaviour by enabling it explicitly in the tyk.conf file:\n\n \"enable_redis_rolling_limiter\": true\n\n\nThis might be useful if you do not wish to switch over immediately and wish to test the new rate limiter first.\n\nPublic and Private keys\n\nTyk v2.3 introduces public/private key message authentication for messages that are sent from the management interface to the Gateways, and for code that is being deployed as a plugin to a Gateway via the bundle downloader.\n\nBy default, Tyk's new config file has this feature disabled, however since it is new, an existing tyk.conf will assume a secure installation as the feature must be explicitly disabled. This means, prior to starting your new Gateways, either disable the security feature, or add a public/private key pair to your tyk.conf and tyk_analytics.conf files:\n\nDisable secure messages\n\nIf you are upgrading from v2.2 then you must either generate a public/private keypair or disable the option to validate inbound payloads against a key. You can do this by setting the following key in your tyk.conf:\n\n \"allow_insecure_configs\": true\n\n\nAdd a public key and private key pair\n\nFirst, generate the key pair:\n\n # private key\n openssl genrsa -out privkey.pem 2048\n \n # public key\n openssl rsa -in privkey.pem -pubout -out pubkey.pem\n\n\ntyk.conf:\n\n \"public_key_path\": \"/path/to/public/key.pem\"\n\n\ntyk_analytics.conf:\n\n \"private_key_path\": \"/path/to/private/key.pem\"\n\n\nConclusion\n\nThe above are the key changes in v2.3 that could affect your setup and configuration during an upgrade. All other settings should be backwards compatible and not introduce breaking changes.\n\n \n \n \n \n \n "
	}
	]