[TT-16189] Dashboard Config for 5.8

[buger]

Triggered by: imogenkraak

Included:

Tyk Gateway: false
Tyk Dashboard: true
Tyk MDCB false
Tyk Pump false

Intended for: 5.8
Changes sourced from: release-5.8.9
Config info generator branch: main

Note: Docs updates for Dashboard v5.8.9 (branch suffix: docs)

JIRA: https://tyktech.atlassian.net/browse/TT-16189

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Clarity The deprecation note for allow_explicit_policy_id is ambiguous. Consider formatting it as a clear deprecation notice (e.g., using a shortcode) and specifying from which version it is deprecated and what to use instead. ### allow_explicit_policy_id ENV: <b>TYK_DB_ALLOWEXPLICITPOLICYID</b><br /> Type: `bool`<br /> Set this value to `true` if you're planning to use Tyk Sync or Tyk Operator Deprecated Logic Check In the deny rule for non-admin password resets, x := sprintf("You do not have permission to reset the password for other users.", [user_id]) passes an argument but the format string has no placeholder; either add %v or remove the arg. # Do not allow users (excluding admin users) to reset the password of another user. deny[x] { request_permission[_] = "ResetPassword" not is_admin user_id := split(input.request.path, "/")[3] user_id != input.user.id x := sprintf("You do not have permission to reset the password for other users.", [user_id]) } Consistency Several descriptions were reworded and date formats changed (DD-MM-YYYY). Verify this matches actual API expectations and existing docs to avoid inconsistency for consumers. type: string - description: Filters audit logs based on the HTTP status code returned by the API in response to the request. This parameter allows you to focus on specific outcomes of API interactions. example: 200 in: query name: status required: false schema: type: integer - description: | This parameter filters audit logs based on partially matching the accessed API endpoint's URL path. It allows searching for actions performed on related resources or sections of the API by matching any portion of the URL. The match is case-sensitive and ignores additional path segments or query parameters beyond the matched portion. For example, if the database contains URLs like `/tib/create`, `/tib/get/1?schema=json`, `/api/schema`, and `/schema1` searching with `url=schema` would return `/api/schema` and `/schema1`. example: /api/apis in: query name: url required: false schema: type: string - description: Specifies the start date for the audit log search. If not provided, the search will include records from the earliest available date. Format DD-MM-YYYY. example: 25-11-1990 in: query name: from_date required: false schema: type: string - description: Specifies the end date for the audit log search. If not provided, the search will include records up to the current date and time. Format DD-MM-YYYY. example: 18-12-2030 in: query name: to_date

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Fix sprintf placeholder mismatch The sprintf format has a single '%v' placeholder but two values are passed, which can cause a runtime error in Rego. Provide both placeholders or pass only one value to match the format. snippets/opa-rules.mdx [128-135] deny[x] { # SKIP the check if it's self-key-reset not is_self_key_reset perm := request_permission[_] not is_admin not intent_match(request_intent, input.user.user_permissions[perm]) - x := sprintf("You do not have permission to carry out '%v' operation.", [request_intent, input.request.path]) + x := sprintf("You do not have permission to carry out '%v' operation on '%v'.", [request_intent, input.request.path]) } Suggestion importance[1-10]: 8 __ Why: The existing Rego uses sprintf with one %v but supplies two arguments, which is a real runtime bug; adding a second placeholder matches the arguments and prevents errors.	Medium
	Use Accept header for GET Using Content-Type as a required header for a GET endpoint is unconventional and often rejected by clients and proxies; typically Accept is used for response content negotiation. Restore Accept to avoid client incompatibilities. swagger/dashboard-swagger.yml [2126-2141] /api/apis/oas/{apiId}/versions: get: parameters: - - name: "Content-Type" + - name: "Accept" in: header required: true - description: "Content type for streams endpoints should be `application/vnd.tyk.streams.oas`" + description: "Accept type for streams endpoints should be `application/vnd.tyk.streams.oas`" schema: type: string enum: ["application/vnd.tyk.streams.oas"] Suggestion importance[1-10]: 7 __ Why: The PR changes a GET endpoint header from Accept to Content-Type, which is unconventional; recommending Accept improves interoperability though it may reflect intentional API behavior.	Medium
General	Align spec version with features Lowering info.version from 5.9.0 to 5.8.9 may misrepresent the API surface if paths/components added in this spec are not available in 5.8.9. Verify that all documented endpoints and schemas exist in 5.8.9 or revert the version to match the documented features. swagger/dashboard-swagger.yml [34-43] info: - ... -- version: 5.8.9 + contact: + email: [email protected] + name: Tyk Technologies + url: https://tyk.io/contact + description: |2 + <img src="https://tyk.io/docs/img/swagger_dashboard_image.png" width="963" height="250"> + + ## <a name="introduction"></a> Introduction + The Tyk Dashboard API offers granular, programmatic access to a centralised database of resources that your Tyk nodes can pull from. This API has a dynamic user administrative structure which means the secret key that is used to communicate with your Tyk nodes can be kept secret and access to the wider management functions can be handled on a user-by-user and organisation-by-organisation basis. + license: + name: Mozilla Public License Version 2.0 + url: https://github.com/TykTechnologies/tyk/blob/master/LICENSE.md + title: Tyk Dashboard API + version: 5.9.0 + Suggestion importance[1-10]: 6 __ Why: Flagging a version downgrade risk is valid and important for accuracy, but it asks to verify/revert without concrete evidence from the diff; impact is moderate.	Low