# client_old

**Repository Path**: bgIntegration/client_old

## Basic Information

- **Project Name**: client_old
- **Description**: old version of client
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 3
- **Created**: 2026-01-23
- **Last Updated**: 2026-01-29

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# BG Instant Software Platform - Client-side


## 0. Overview

- `CConnection_c`: low-level transport (socket + TLS via OpenSSL), message framing (`AppProtoHeader`), 
  request/response IO.
- `CNetwork_c`: connection lifecycle wrapper around CConnection_c (Connect/Disconnect/SendRequest), 
  tracks `is_connected_`.
- `CClient`: app-layer ��user/client�� logic (login, token handling), depends on `CNetwork_c` via Init.
- `TlsAuthClient`: convenience wrapper around CClient + CNetwork_c that holds login state and forwards 
  requests.

This layering is reasonable, but there are a few consistency and correctness gaps between layers (endpoint 
selection, TLS-only expectations, threading model).


## 1. CMakeLists.txt Issues

### What's done

- Explicit source list (avoids GLOB pitfalls).
- Consistent C++17 settings.
- MSVC /utf-8 is a pragmatic fix for mixed-language sources.
- Links OpenSSL via imported targets (ssl, OpenSSL::Crypto) which is the correct modern approach.
- The message(STATUS "CLIENT_SOURCES: ...") is noisy for CI; consider gating behind an option.
  **FIXED BY**: Modified the CMakeLists.txt, now need enable locally with: 
  ```
  cmake -S . -B build -G "Ninja" -DCLIENT_PRINT_SOURCES=ON
  ```
- Prefer only target_* scoped settings to avoid accidental include leakage into future targets.

### Remain issues

## 2. Protocol Contract

### What's done

- Fixed-size header + static_assert(sizeof(AppProtoHeader) == 64) is solid.
- `kMaxPayloadSize` is correctly centralized in the protocol header (matches our repo rule).
- In `Connection_c.cpp` there��s a `t_connect_start` defined as a namespace-scope const initialized at 
  load time. It��s later used to compute per-connection durations, which will be wrong once the process 
  has been running for a while. This should be a local variable inside `Connect()`. **FIXED BY**: Move 
  `t_connect_start` from namespace scope (process-load time) to a per-call local timestamp inside `CConnection_c::Connect()`, 
  and updated the connect duration log to use it.
- Protocol version is defined in `Connection_c.cpp` as a local constant: `kExpectedProtoVersion = 1`.
	- This is a ��split definition�� risk. The canonical protocol version should live in `AppProtoHeader.h` 
	  (similar to `kMaxPayloadSize`) and be referenced everywhere. **FIXED BY**: Move to `AppProtoHeader.h` 
	  as `kAppProtoVersion`.

### Remain issues

## 3. TLS and Security

### What's done
- TLS-only enforcement in `CConnection_c::Connect()` is good  for preventing accidental plaintext.
- Peer cert verification is enabled: `SSL_CTX_set_verify`(..., `SSL_VERIFY_PEER`, ...).
- Default trust store loading: `SSL_CTX_set_default_verify_paths`(...).
- Logging redaction utilities (`redact_json_like`, `payload_preview`) are a solid start and align with 
  ��don��t print credentials��.
- SNI / hostname verification: current connect uses an IP string and sets the fd, but there��s no `SSL_set_tlsext_host_name(...)` 
  and no explicit hostname verification. If we will connect by DNS name in production scenario, we need 
  proper hostname verification. **FIXED BY**: Implemented SNI + RFC2818 hostname verification for 
  TLS connections by switching `Connect()` to accept a host (DNS name or IP), setting SNI when appropriate, 
  and enabling OpenSSL��s built-in hostname verification via X509_VERIFY_PARAM.
- `CClient::start()` hardcodes a password ("123456"). Even if not logged, it should not be in committed 
  code. Prefer reading from environment variables, config, or interactive input.
- `CClient::ExtractSessionToken()` is a manual string search; it can be fooled by formatting/escaping 
  or nested JSON. For auth flows, this is brittle and can become a security bug (wrong token extracted, 
  injection-like scenarios). Prefer a small JSON parser dependency.

### Remain issues

## 4. Client Behavior

### What's done

- `CClient::Init()` sets `TLS_server_ip_`/`TLS_server_port_`, but `LoginWithPassword()` connects using 
  `server_ip_`/`server_port_`. **FIXED BY**: using config file `client.conf` via `config_client.h`.
	- Currently `server_ip_` defaults to empty and `CNetwork_c::Connect()` substitutes DEFAULT_SERVER_IP/DEFAULT_SERVER_PORT, 
	  so `TLS_server_*` in CClient is effectively unused/confusing.
	- Recommendation: have a single endpoint source of truth (either remove `TLS_server_*` or have `LoginWithPassword()` 
	  use them).
- `CClient::start()` hardcodes `password = "123456"`. Even as a test, this should not be committed; 
  it will spread into logs, crash dumps, etc. **FIXED BY**: using config file `client.conf` via `config_client.h`.
- Token parsing is done with manual find heuristics (ExtractSessionToken, ParseTokenInfo).
	- This is brittle and can mis-parse valid JSON (escaping, whitespace, nested objects). For auth 
	  flows it��s worth using a real JSON parser. **FIXED BY**: using nlohmann_json parser

### Remain issues

## 5. Threading / concurrency assumptions

### What's done

- `CNetwork_c::SendRequest()` is documented as ��single reader�� but not enforced.
- `CClient::start()` spawns a thread running `service_loop()` that currently does nothing and is always 
  joined��pure overhead and invites future lifecycle bugs. This will be automaically fixed when we 
  implement actual service loop logic.
- Define exactly what `service_loop` is responsible for (reconnect, ping, keepalive, etc.) and guard 
  shared state with synchronization. We will later define a map of command handlers to process incoming 
  messages from server or from local UI calling.

### Remain issues

## 6. Supabase Integration

### What's done

- **SupabaseClient**: A new client class (`SupabaseClient.h` / `SupabaseClient.cpp`) has been integrated to provide 
  Supabase REST API functionality. This class uses libcurl for HTTP requests and nlohmann/json for JSON parsing.
  
- **Configuration Support**: The `ConfigClient` now supports reading Supabase configuration from `client.conf`:
  - `SUPABASE_URL`: The base URL of your Supabase project (e.g., `http://8.164.11.126`)
  - `SUPABASE_API_KEY`: The anon/public API key for authentication
  
  These values can be accessed via:
  ```cpp
  std::string url = ConfigClient::instance().getSupabaseUrl();
  std::string apiKey = ConfigClient::instance().getSupabaseApiKey();
  ```

- **Usage Example**:
  ```cpp
  #include "SupabaseClient.h"
  #include "config_client.h"
  
  // Load configuration
  ConfigClient::instance().loadFromPath("client.conf");
  
  // Get Supabase credentials
  std::string url = ConfigClient::instance().getSupabaseUrl();
  std::string apiKey = ConfigClient::instance().getSupabaseApiKey();
  
  // Create client and query
  SupabaseClient client(url, apiKey);
  json result = client.queryFileUrls();  // Query contents table for file_url fields
  ```

- **Dependencies**: 
  - libcurl: Required for HTTP requests to Supabase REST API
  - nlohmann/json: Already included in the project for JSON parsing

- **Configuration File Format** (`client.conf`):
  ```
  SUPABASE_URL=http://8.164.11.126
  SUPABASE_API_KEY=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...
  ```

### Remain issues


## 6. Environment Setup

When build on Windows, CMake may fail due to it could not find `OpenSSL` on your Windows machine. The 
project uses `find_package`(`OpenSSL` REQUIRED) so we must provide `OpenSSL` (and `libcurl`) to CMake.

Run in a Developer PowerShell x64:
```ps
# clone & bootstrap vcpkg (first time only)
git clone https://github.com/microsoft/vcpkg.git
.\vcpkg\bootstrap-vcpkg.bat

# install dependencies for this project (x64)
.\vcpkg\vcpkg.exe install openssl[core]:x64-windows curl[openssl]:x64-windows

# from E:\giteeNodesbit\integration (or repo root)
$toolchain = "E:\giteeNodesbit\integration\vcpkg\scripts\buildsystems\vcpkg.cmake"

# clean stale build
Remove-Item -Recurse -Force .\client\build

# Configure CMake using vcpkg toolchain and x64 triplet
cmake -S client -B client\build -G "Ninja" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=.\vcpkg\scripts\buildsystems\vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows
cmake -S client -B client\build -G "Ninja" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE="$toolchain" -DVCPKG_TARGET_TRIPLET=x64-windows

# Build
cmake --build build
```

```ps
# Optionally, (Administrator) set Android NDK path globally if building for Android
setx ANDROID_NDK "D:\AndroidSDK\ndk\29.0.14206865" /M
```

### 6.1 Force a proper x64 Visual Studio generator

```ps
# set up Visual Studio build environment (Developer PowerShell x64)
& 'D:\Program Files\Microsoft Visual Studio\18\Community\Common7\Tools\VsDevCmd.bat' -arch=amd64

# remove stale build cache
Remove-Item -Recurse -Force client\build

# configure for x64 using vcpkg toolchain (absolute path)
#cmake -S client -B client\build -G "Ninja" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE="E:/giteeNodesbit/integration/vcpkg/scripts/buildsystems/vcpkg.cmake" -DVCPKG_TARGET_TRIPLET=x64-windows
cmake -S client -B client\build -G "Visual Studio 17 2022" -A x64 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE="E:/giteeNodesbit/integration/vcpkg/scripts/buildsystems/vcpkg.cmake" -DVCPKG_TARGET_TRIPLET=x64-windows

# build (Debug config)
cmake --build client\build --config Debug --parallel
```
All steps are passed.

### 6.2 Use Ninja but ensure the environment points to the x64 MSVC tools

```ps
# set up Visual Studio build environment (Developer PowerShell x64)
& 'D:\Program Files\Microsoft Visual Studio\18\Community\Common7\Tools\VsDevCmd.bat' -arch=amd64

where cl

where link

# The where output must show cl/link under a Hostx64 path (or Hostx64\x64). If they still point to Hostx86, the environment is wrong.

# remove stale build cache
Remove-Item -Recurse -Force client\build

# reconfigure with Ninja:
cmake -S client -B client\build -G "Ninja" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE="E:/giteeNodesbit/integration/vcpkg/scripts/buildsystems/vcpkg.cmake" -DVCPKG_TARGET_TRIPLET=x64-windows

# build (Debug config)
cmake --build client\build --config Debug --parallel
```
The last step is not passed yet.