GGitHubVDP-4556: Block server-side file reads on database import for non-desktop builds (#6307)

f035f4ce创建于 7月29日历史提交

文件	最后提交记录	最后更新时间
api	VDP-4556: Block server-side file reads on database import for non-desktop builds (#6307) * fix(database-import): block server-side file reads on import for non-desktop builds Import fields for SSH keys and TLS certificates accept either inline PEM or a filesystem path, falling back to readFileSync when the value is not PEM. On network-facing builds these endpoints are unauthenticated, so a path turns import into an arbitrary server-side file read that export can then return with withSecrets. Gate the path fallback behind isImportFromFileAllowed(), which is true only for the Electron desktop build. Other builds accept inline PEM only and reject a path with the existing invalid-body error, without touching the filesystem. References: #VDP-4556 * test(database-import): expect rejection for path-based cert import on server The TLS import integration cases fed certificates and keys as filesystem paths, which non-desktop builds no longer resolve. Update the format 1/2/3 cases (standalone, cluster, sentinel, and the ssh variants) to expect a partial import with the invalid-body errors instead of success. Format 0, which passes inline PEM, is unchanged. References: #VDP-4556	3 个月前
helpers	RI-8308: Add ability to choose IPv4/IPv6 when connecting to a database (#6197)	3 个月前
test-runs	Add vector set integration tests (#6295) * test(api): add integration tests for vector set creation * test(api): add integration tests for adding vector set elements * test(api): add integration tests for getting vector set elements * test(api): add integration tests for deleting vector set elements * test(api): add integration tests for vector set similarity search * test(api): run vector-set specs in the Redis 8 (oss-st-8) job	3 个月前
README.md	Migrate package manager from yarn to npm (#6216)	3 个月前

Integration Tests

How to Run

Prerequisites

First Time Running Tests?
If you're running the tests for the first time, please review the Short Explanation and High-Level Overview.
Running a Subset of Tests
You can run a specific subset of tests by modifying the spec glob in /redisinsight/api/test/api/.mocharc.yml. This allows you to execute only the tests you need.

Steps to Run Tests

Run the Desired Environment
It's recommended to use Docker for this, as it provides better control over versioning and switching between environments.
Execute the Tests
From the root directory of the repository, run the following command:
```
npm run test:api:integration
```

Example

Let’s walk through an example where you need to run tests related to string.

Modify the Test Subset
Update /redisinsight/api/test/api/.mocharc.yml to include only the string tests:
```
spec:
  - 'test/**/string/**/*.test.ts'
```
Run the Environment in Docker
For this example, let’s assume you need to run the tests against the OSS-ST-6 environment. To do this:
- Navigate to the environment directory:
```
cd /redisinsight/api/test/test-runs/oss-st-6
```
- Start Docker:
```
docker-compose up
```
Run the Tests
Finally, execute the tests from the root directory:
```
npm run test:api:integration
```

Short Explanation and High-Level Overview

The integration tests follow a basic structure:

Redis Environment: Tests are executed against various Redis environments such as Redis Community Edition (Redis OSS), Redis Cluster, Redis Stack, etc.
Test Suites: A collection of test scenarios are designed to evaluate different Redis features.

Note: Keep in mind that specific Redis environments might require additional test suites. For example, Redis Stack includes RediSearch, which is not available in Redis OSS, meaning tests designed for RediSearch will fail if executed in a Redis OSS environment.

Project Structure

Tests

The /redisinsight/api/test/api directory contains all the test scenarios for the integration tests.

Environments

The /redisinsight/api/test/test-runs directory houses the Redis Test Environments (RTEs). Some of these environments have more complex setups, such as TLS with authentication, and thus include all necessary components (e.g., keys, certificates).

Note: You may encounter some code related to GitHub Actions workflows, as these tests are also automatically run through CI/CD.