Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[8.x] [FTR] allow to call roleScopedSupertest service with Cookie hea…
…der (#192727) (#193679) # Backport This will backport the following commits from `main` to `8.x`: - [[FTR] allow to call roleScopedSupertest service with Cookie header (#192727)](#192727) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Dzmitry Lemechko","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-09-19T23:10:18Z","message":"[FTR] allow to call roleScopedSupertest service with Cookie header (#192727)\n\n## Summary\r\n\r\nDuring the sync with kibana-security team we agreed on how Kibana APIs\r\nshould be tested:\r\n\r\n### API Authentication in Kibana: Public vs. Internal APIs\r\n\r\nKibana provides both public and internal APIs, each requiring\r\nauthentication with the correct privileges. However, the method of\r\ntesting these APIs varies, depending on how they are untilized by end\r\nusers.\r\n\r\n- **Public APIs**: When testing HTTP requests to public APIs, **API\r\nkey-based authentication** should be used. It reflect how end user call\r\nthese APIs. Due to existing restrictions, we utilize `Admin` user\r\ncredentials to generate API keys for various roles. While the API key\r\npermissions are correctly scoped according to the assigned role, the\r\nuser will internally be recognized as `Admin` during authentication.\r\n\r\n- **Internal APIs**: Direct HTTP requests to internal APIs are generally\r\nnot expected. However, for testing purposes, authentication should be\r\nperformed **using the Cookie header**. This approach simulates\r\nclient-side behavior during browser interactions, mirroring how internal\r\nAPIs are indirectly invoked.\r\n\r\nTo simplify the process of creating/updating the tests, this PR makes\r\nfew changes to `roleScopedSupertest` service\r\n\r\n1) testing public APIs (nothing changed)\r\n\r\n```ts\r\n const supertestAdminWithApiKey = await roleScopedSupertest.getSupertestWithRoleScope('admin', {\r\n withCustomHeaders: { 'accept-encoding': 'gzip' },\r\n });\r\n const response = await supertestAdminWithApiKey.get('/app/kibana');\r\n```\r\n\r\n2) testing internal APIs\r\n```ts\r\n const supertestAdminWithCookieCredentials = await roleScopedSupertest.getSupertestWithRoleScope(\r\n 'admin',\r\n {\r\n useCookieHeader: true, // will use Cookie header instead of API key\r\n withInternalHeaders: true,\r\n }\r\n );\r\n await supertestAdminWithCookieCredentials\r\n .post(`/internal/kibana/settings/${TEST_SETTING}`)\r\n .send({ value: 100 })\r\n .expect(200);\r\n```\r\n\r\nI updated some of the existing tests according to the new approach.\r\n\r\nDocs for serverless and deployment-agnostic api integration tests were\r\nupdated accordingly","sha":"d9148f1d83e31f9f6a226c0c867e39d4aeb8d48f","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","v8.16.0","backport:version"],"title":"[FTR] allow to call roleScopedSupertest service with Cookie header","number":192727,"url":"https://github.com/elastic/kibana/pull/192727","mergeCommit":{"message":"[FTR] allow to call roleScopedSupertest service with Cookie header (#192727)\n\n## Summary\r\n\r\nDuring the sync with kibana-security team we agreed on how Kibana APIs\r\nshould be tested:\r\n\r\n### API Authentication in Kibana: Public vs. Internal APIs\r\n\r\nKibana provides both public and internal APIs, each requiring\r\nauthentication with the correct privileges. However, the method of\r\ntesting these APIs varies, depending on how they are untilized by end\r\nusers.\r\n\r\n- **Public APIs**: When testing HTTP requests to public APIs, **API\r\nkey-based authentication** should be used. It reflect how end user call\r\nthese APIs. Due to existing restrictions, we utilize `Admin` user\r\ncredentials to generate API keys for various roles. While the API key\r\npermissions are correctly scoped according to the assigned role, the\r\nuser will internally be recognized as `Admin` during authentication.\r\n\r\n- **Internal APIs**: Direct HTTP requests to internal APIs are generally\r\nnot expected. However, for testing purposes, authentication should be\r\nperformed **using the Cookie header**. This approach simulates\r\nclient-side behavior during browser interactions, mirroring how internal\r\nAPIs are indirectly invoked.\r\n\r\nTo simplify the process of creating/updating the tests, this PR makes\r\nfew changes to `roleScopedSupertest` service\r\n\r\n1) testing public APIs (nothing changed)\r\n\r\n```ts\r\n const supertestAdminWithApiKey = await roleScopedSupertest.getSupertestWithRoleScope('admin', {\r\n withCustomHeaders: { 'accept-encoding': 'gzip' },\r\n });\r\n const response = await supertestAdminWithApiKey.get('/app/kibana');\r\n```\r\n\r\n2) testing internal APIs\r\n```ts\r\n const supertestAdminWithCookieCredentials = await roleScopedSupertest.getSupertestWithRoleScope(\r\n 'admin',\r\n {\r\n useCookieHeader: true, // will use Cookie header instead of API key\r\n withInternalHeaders: true,\r\n }\r\n );\r\n await supertestAdminWithCookieCredentials\r\n .post(`/internal/kibana/settings/${TEST_SETTING}`)\r\n .send({ value: 100 })\r\n .expect(200);\r\n```\r\n\r\nI updated some of the existing tests according to the new approach.\r\n\r\nDocs for serverless and deployment-agnostic api integration tests were\r\nupdated accordingly","sha":"d9148f1d83e31f9f6a226c0c867e39d4aeb8d48f"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/192727","number":192727,"mergeCommit":{"message":"[FTR] allow to call roleScopedSupertest service with Cookie header (#192727)\n\n## Summary\r\n\r\nDuring the sync with kibana-security team we agreed on how Kibana APIs\r\nshould be tested:\r\n\r\n### API Authentication in Kibana: Public vs. Internal APIs\r\n\r\nKibana provides both public and internal APIs, each requiring\r\nauthentication with the correct privileges. However, the method of\r\ntesting these APIs varies, depending on how they are untilized by end\r\nusers.\r\n\r\n- **Public APIs**: When testing HTTP requests to public APIs, **API\r\nkey-based authentication** should be used. It reflect how end user call\r\nthese APIs. Due to existing restrictions, we utilize `Admin` user\r\ncredentials to generate API keys for various roles. While the API key\r\npermissions are correctly scoped according to the assigned role, the\r\nuser will internally be recognized as `Admin` during authentication.\r\n\r\n- **Internal APIs**: Direct HTTP requests to internal APIs are generally\r\nnot expected. However, for testing purposes, authentication should be\r\nperformed **using the Cookie header**. This approach simulates\r\nclient-side behavior during browser interactions, mirroring how internal\r\nAPIs are indirectly invoked.\r\n\r\nTo simplify the process of creating/updating the tests, this PR makes\r\nfew changes to `roleScopedSupertest` service\r\n\r\n1) testing public APIs (nothing changed)\r\n\r\n```ts\r\n const supertestAdminWithApiKey = await roleScopedSupertest.getSupertestWithRoleScope('admin', {\r\n withCustomHeaders: { 'accept-encoding': 'gzip' },\r\n });\r\n const response = await supertestAdminWithApiKey.get('/app/kibana');\r\n```\r\n\r\n2) testing internal APIs\r\n```ts\r\n const supertestAdminWithCookieCredentials = await roleScopedSupertest.getSupertestWithRoleScope(\r\n 'admin',\r\n {\r\n useCookieHeader: true, // will use Cookie header instead of API key\r\n withInternalHeaders: true,\r\n }\r\n );\r\n await supertestAdminWithCookieCredentials\r\n .post(`/internal/kibana/settings/${TEST_SETTING}`)\r\n .send({ value: 100 })\r\n .expect(200);\r\n```\r\n\r\nI updated some of the existing tests according to the new approach.\r\n\r\nDocs for serverless and deployment-agnostic api integration tests were\r\nupdated accordingly","sha":"d9148f1d83e31f9f6a226c0c867e39d4aeb8d48f"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Dzmitry Lemechko <[email protected]>
- Loading branch information