added dependent docker compose file - #2295
Conversation
|
Warning Review limit reached
Next review available in: 53 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
WalkthroughThe change adds a local Docker Compose stack for PostgreSQL, Redis, mock identity, mock relying-party, and UI services. It also adds database schema and seed data, plus Nginx proxy and SPA routing. ChangesMock eSignet deployment
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Browser
participant Nginx
participant MockRelyingParty
participant MockIdentitySystem
Browser->>Nginx: request UI or relying-party endpoint
Nginx->>MockRelyingParty: proxy relying-party request
MockRelyingParty->>MockIdentitySystem: use mock identity authentication
MockIdentitySystem-->>MockRelyingParty: return identity data
MockRelyingParty-->>Nginx: return response
Nginx-->>Browser: return response or SPA index.html
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop-go #2295 +/- ##
=============================================
Coverage ? 81.94%
=============================================
Files ? 60
Lines ? 4441
Branches ? 0
=============================================
Hits ? 3639
Misses ? 608
Partials ? 194
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Signed-off-by: Sachin Rana <sacrana324@gmail.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docker-compose/dependent-docker-compose.yaml`:
- Around line 7-8: Replace the hardcoded PostgreSQL passwords and embedded
private-key values in the compose configuration, including POSTGRES_PASSWORD,
SPRING_DATASOURCE_PASSWORD, CLIENT_PRIVATE_KEY, and JWE_USERINFO_PRIVATE_KEY,
with environment-variable or Docker-secret references. Ensure the referenced
secrets are supplied through an untracked .env file or secret store and no
credential or key material remains committed in the compose file.
- Line 41: Update the ESIGNET_PAR_ENDPOINT value to use
http://localhost:8088/oauth2/par, matching the scheme used by the other esignet
URL configuration values in this compose block.
- Line 3: Update the Postgres image reference in the compose configuration from
the moving bookworm tag to a specific versioned tag, such as
postgres:16-bookworm, while leaving the surrounding service configuration
unchanged.
- Line 29: Update the eSignet host configuration in the dependent Docker Compose
setup so server-side OIDC URLs used by mock-relying-party-service resolve
outside its container instead of pointing to localhost:8088; apply the same
valid host and port consistently to ESIGNET_SERVICE_URL, ESIGNET_AUD_URL,
ESIGNET_PAR_ENDPOINT, and ESIGNET_PAR_AUD_URL, and validate MOSIP_ESIGNET_HOST
for mock-identity-system against its service version and integration scope.
In `@docker-compose/mock-id-init.sql`:
- Around line 67-74: Update the kyc_auth and verified_claim table definitions to
add a primary key for kyc_auth and indexes on kyc_auth.individual_id,
kyc_auth.transaction_id, kyc_auth.kyc_token, and verified_claim.individual_id,
using the existing schema naming conventions and preserving all current columns.
- Around line 131-132: Update the mock_identity seed INSERT for individual_id
1774231323 by replacing the personal email with an obviously synthetic
example.com or example.org address, and add a SQL comment documenting that the
plaintext pin is intentional test data for the mock stack and not a real
credential.
In `@docker-compose/rp-nginx.conf`:
- Around line 50-53: Remove the unused commented-out alias directive from the
location / block, leaving the active try_files configuration unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 1ad2a14a-30b3-4072-9170-84c1c083a359
📒 Files selected for processing (3)
docker-compose/dependent-docker-compose.yamldocker-compose/mock-id-init.sqldocker-compose/rp-nginx.conf
| @@ -0,0 +1,81 @@ | |||
| services: | |||
| database: | |||
| image: 'postgres:bookworm' | |||
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
Does the official postgres Docker image on Docker Hub have a standalone "bookworm" tag (without a version number)?
💡 Result:
Yes, the official Postgres Docker image on Docker Hub includes a standalone "bookworm" tag [1][2]. As of August 3, 2026, the image documentation lists "bookworm" as a valid tag, which typically points to the most recent supported PostgreSQL version on the Debian Bookworm distribution [1][3]. For example, current tags include "18.4-bookworm", "18-bookworm", and the standalone "bookworm" [1][2]. It is important to note that the maintainers of the Docker Official Images have periodically discussed or implemented the deprecation of such generic, version-agnostic tags (e.g., "latest", "bookworm", "alpine") to encourage users to pin specific versions for better stability [4]. While the "bookworm" tag is currently listed, it is recommended to use version-specific tags (such as "18-bookworm") to avoid unexpected upgrades when the underlying PostgreSQL version updates [3].
Citations:
- 1: https://hub.docker.com/_/postgres
- 2: https://hub.docker.com/_/postgres?tab=tags&
- 3: https://github.com/docker-library/docs/tree/master/postgres
- 4: Remove "latest" and friends docker-library/postgres#1294
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Repository file context:"
if [ -f docker-compose/dependent-docker-compose.yaml ]; then
sed -n '1,40p' docker-compose/dependent-docker-compose.yaml
else
echo "docker-compose/dependent-docker-compose.yaml not found"
fi
echo
echo "Local Docker image references:"
rg -n "postgres:" . || trueRepository: mosip/esignet
Length of output: 2731
Pin the Postgres Docker image to a version tag.
postgres:bookworm is supported, but version-agnostic Docker tags move over time. For reproducible and GDPR/MOSIP-compliant builds, use a specific tag such as postgres:16-bookworm in docker-compose/dependent-docker-compose.yaml.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/dependent-docker-compose.yaml` at line 3, Update the Postgres
image reference in the compose configuration from the moving bookworm tag to a
specific versioned tag, such as postgres:16-bookworm, while leaving the
surrounding service configuration unchanged.
| - POSTGRES_USER=postgres | ||
| - POSTGRES_PASSWORD=postgres |
There was a problem hiding this comment.
🔒 Security & Privacy | 🔴 Critical | ⚡ Quick win
Hardcoded credentials and private keys committed to the compose file.
POSTGRES_PASSWORD/SPRING_DATASOURCE_PASSWORD use the default value postgres, and CLIENT_PRIVATE_KEY/JWE_USERINFO_PRIVATE_KEY embed full base64-encoded RSA private keys directly in the file. Static analysis flags line 43 as a "Generic API Key" leak.
JWE_USERINFO_PRIVATE_KEY decrypts the userinfo JWE response, which carries claims such as phone_number and verified_claims (PII). Anyone with read access to this key can decrypt captured userinfo traffic, which is a GDPR Article 32 (security of processing) concern. The upstream mosip/esignet-mock-services project's own Kubernetes install steps direct operators to "Create empty secret for client-private-key and jwe-userinfo-key for mock relying party service." Follow the same pattern here: reference environment variables backed by an untracked .env file or Docker secret, instead of committing key material and passwords to version control.
🔒 Proposed fix using environment variable references
environment:
- POSTGRES_USER=postgres
- - POSTGRES_PASSWORD=postgres
+ - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
...
- SPRING_DATASOURCE_USERNAME=postgres
- - SPRING_DATASOURCE_PASSWORD=postgres
+ - SPRING_DATASOURCE_PASSWORD=${POSTGRES_PASSWORD}
...
- - CLIENT_PRIVATE_KEY=eyJrdHkiOiJSU0Ei...
+ - CLIENT_PRIVATE_KEY=${MOCK_RP_CLIENT_PRIVATE_KEY}
- - JWE_USERINFO_PRIVATE_KEY=ewogICAgInAiOi...
+ - JWE_USERINFO_PRIVATE_KEY=${MOCK_RP_JWE_USERINFO_PRIVATE_KEY}As per path instructions, "Flag any hardcoded values for: passwords, private keys, database credentials, API keys, or internal service IPs in non-dev configs. Must reference environment variables (e.g., ${DB_PASSWORD})."
Also applies to: 27-28, 43-44
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/dependent-docker-compose.yaml` around lines 7 - 8, Replace the
hardcoded PostgreSQL passwords and embedded private-key values in the compose
configuration, including POSTGRES_PASSWORD, SPRING_DATASOURCE_PASSWORD,
CLIENT_PRIVATE_KEY, and JWE_USERINFO_PRIVATE_KEY, with environment-variable or
Docker-secret references. Ensure the referenced secrets are supplied through an
untracked .env file or secret store and no credential or key material remains
committed in the compose file.
Source: Path instructions
| - SPRING_DATASOURCE_URL=jdbc:postgresql://database:5432/mosip_mockidentitysystem?currentSchema=mockidentitysystem | ||
| - SPRING_DATASOURCE_USERNAME=postgres | ||
| - SPRING_DATASOURCE_PASSWORD=postgres | ||
| - MOSIP_ESIGNET_HOST=localhost:8088 |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check for an existing esignet compose stack or networking config in this folder,
# and confirm no shared network/host-networking is declared for cross-stack resolution of "localhost".
fd . docker-compose --type f
rg -n 'network_mode|extra_hosts|networks:' docker-composeRepository: mosip/esignet
Length of output: 284
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== files =="
git ls-files docker-compose
echo
echo "== dependent YAML =="
cat -n docker-compose/dependent-docker-compose.yaml | sed -n '1,120p'
echo
echo "== main compose =="
cat -n docker-compose/docker-compose.yaml | sed -n '1,220p'
echo
echo "== local searches for environment variable usages =="
rg -n 'MOSIP_ESIGNET_HOST|ESIGNET_SERVICE_URL|ESIGNET_AUD_URL|ESIGNET_PAR_ENDPOINT|ESIGNET_PAR_AUD_URL|ESIGNET_UI_BASE_URL|login|redirect|callback|issuer|client_id|client_secret|authorize|token|userinfo|introspect|jwks|userinfo.*url|service.*url|aud.*url|par' docker-compose -S || trueRepository: mosip/esignet
Length of output: 14936
🌐 Web query:
mosipdev/mock-relying-party-service ESIGNET_SERVICE_URL ESIGNET_AUD_URL usage
💡 Result:
In the mosipdev/mock-relying-party-service, the environment variables ESIGNET_SERVICE_URL and ESIGNET_AUD_URL are used to configure the connection and authentication between the mock relying party and the MOSIP eSignet service [1]. ESIGNET_SERVICE_URL defines the base URL for the MOSIP eSignet API [1]. It is typically formatted as https://<ESIGNET_DOMAIN>/v1/esignet [1]. ESIGNET_AUD_URL defines the audience (aud) claim used for client assertions when calling the token endpoint [1]. This value must match the token endpoint URL configured in the eSignet service to avoid authentication errors, such as invalid_assertion [1][2]. A common format is https://<ESIGNET_DOMAIN>/v1/esignet/oauth/v2/token [1][3]. These variables are essential for the mock relying party service to correctly authenticate and request tokens from the eSignet environment [1][4][5]. They can be configured via environment variables in Docker or directly in the application configuration files [1][5][2].
Citations:
- 1: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-service/README.md
- 2: https://community.mosip.io/t/facing-issue-in-generating-token-in-esignet/1648
- 3: https://github.com/mosip/infra/blob/master/docs/esignet_README.md
- 4: https://github.com/mosip/esignet-mock-services/blob/master/docker-compose/README.md
- 5: https://community.mosip.io/t/oidc-ui-redirect-in-to-relying-party-ui-health-portal-problem/1489
🌐 Web query:
mosipdev/mock-identity-system MOSIP_ESIGNET_HOST configuration usage
💡 Result:
The environment variable MOSIP_ESIGNET_HOST is used in the MOSIP mock-identity-system and related eSignet deployments to specify the domain or hostname of the eSignet service [1][2]. In the context of the mock-identity-system, this configuration informs the system about the location of the eSignet instance it is interacting with, which is essential for proper integration during local development and testing [3][2]. Usage details include: - Docker Compose: It is typically defined within the docker-compose.yml file under the environment section for the mock-identity-system service [2]. For example, it might be set to a value like localhost:8088 to point to a local eSignet container [2]. - Infrastructure/Helm Deployments: In Kubernetes or more complex infrastructure deployments, MOSIP_ESIGNET_HOST is often managed via ConfigMaps or environment variables passed to the containers to reflect the specific domain name of the eSignet service being used in that environment [1][4][5]. - Purpose: It ensures that components within the MOSIP/eSignet ecosystem can correctly route requests and identify the appropriate host for OIDC-related operations, such as token validation and client assertions [1][4]. When setting up or troubleshooting, ensure this value matches the accessible host and port where the eSignet service is running [4][5]. It should not be hardcoded in application property files but rather passed as an environment variable to allow for flexible environment-specific configuration [6].
Citations:
- 1: mosip/infra@8fdfe45
- 2: https://github.com/mosip/esignet/blob/master/docker-compose/docker-compose.yml
- 3: https://docs.esignet.io/build-and-deploy/local-deployment/mock-id-system
- 4: https://community.mosip.io/t/deploying-esignet-containers/1982
- 5: https://github.com/mosip/esignet/blob/master/deploy/README.md
- 6: https://github.com/mosip/esignet/blob/v1.4.2/docker-compose/config/mock-identity-system-default.properties
🌐 Web query:
github mosip/esignet-mock-services docker-compose mock-relying-party-service ESIGNET_PAR_ENDPOINT token
💡 Result:
In the MOSIP eSignet mock services repository, ESIGNET_PAR_ENDPOINT is an environment variable used to configure the Pushed Authorization Request (PAR) endpoint when setting up a PAR-enabled mock relying party service [1][2]. When configuring the mock-relying-party-service for a PAR-enabled setup, you must provide the following PAR-related environment variables [1][2]: - ESIGNET_PAR_ENDPOINT: The URL of the PAR endpoint on the eSignet server (e.g., https://<ESIGNET_DOMAIN>/v1/esignet/oauth/par) [2]. - ESIGNET_PAR_AUD_URL: The audience value for the PAR endpoint client assertions [2]. These variables are typically set within your docker-compose file or passed directly when running the Docker container [1][2]. Additionally, for the mock-relying-party-ui to interact correctly with this setup, you must set the PAR_CALLBACK_NAME environment variable (typically to get_requestUri) to enable the PAR feature flag [1][3]. For detailed configuration, refer to the official documentation provided in the mock-relying-party-service and mock-relying-party-ui README files within the mosip/esignet-mock-services repository [1][2][3].
Citations:
- 1: https://github.com/mosip/esignet-mock-services/blob/master/docker-compose/README.md
- 2: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-service/README.md
- 3: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-ui/README.md
🌐 Web query:
github mosip/esignet-mock-services docker-compose mock-relying-party-service README
💡 Result:
The mock-relying-party-service within the MOSIP esignet-mock-services repository is a backend component designed to handle OIDC flows, specifically interacting with the eSignet identity provider to fetch user profiles using authorization code flows with private key JWT authentication [1]. Technical documentation for running this service, including Docker-based deployment, can be found in the service's own README [2] and the centralized docker-compose README [3]. Key Configuration and Usage: 1. Basic Docker Execution: The service requires several environment variables, including ESIGNET_SERVICE_URL, ESIGNET_AUD_URL, CLIENT_PRIVATE_KEY, and REDIRECT_URI [2]. 2. PAR-Enabled Setup: For setups requiring Pushed Authorization Requests (PAR), additional environment variables such as ESIGNET_PAR_ENDPOINT and ESIGNET_PAR_AUD_URL must be provided [2][3]. 3. Orchestration: The repository provides docker-compose files to orchestrate the service alongside the mock relying party UI [3]. You can start these services using commands such as: docker compose --file mock-relying-party-portal-docker-compose.yml up [3]. 4. Development: For local development, the service supports running with npm via npm run devstart [2]. The mock relying party ecosystem consists of two primary parts: the mock-relying-party-ui (a ReactJS frontend) and the mock-relying-party-service (the backend that handles token exchange and user info retrieval) [1]. Configuration details for the UI are maintained in its own separate README [4]. For production-like or Kubernetes-based environments, the repository also includes Helm charts and installation scripts [5]. Note: These mock services are intended for non-production use only [3][5].
Citations:
- 1: https://docs.esignet.io/build-and-deploy/local-deployment/mock-client-application
- 2: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-service/README.md
- 3: https://github.com/mosip/esignet-mock-services/blob/master/docker-compose/README.md
- 4: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-ui/README.md
- 5: https://github.com/mosip/esignet-mock-services
🌐 Web query:
github mosip/esignet-mock-services mock-relying-party-ui docker-compose EsignetUIUrl /oauth2/par
💡 Result:
The mosip/esignet-mock-services repository provides tools to test OIDC flows, including support for Pushed Authorization Requests (PAR) [1]. Regarding your query: 1. Docker Compose Configuration: To run the mock relying party portal with PAR enabled, you should use the mock-relying-party-portal-fapi2-docker-compose.yml file rather than the standard configuration [1]. This setup includes the necessary services and environment variable configurations for PAR-enabled flows [1]. 2. Configuration Parameters: - ESIGNET_PAR_ENDPOINT: This variable defines the PAR endpoint (typically configured as /v1/esignet/oauth/par) [2]. - ESIGNET_PAR_AUD_URL: This variable is used to set the PAR audience URL [1][2]. - PAR_CALLBACK_NAME: In the mock-relying-party-ui, this is set to get_requestUri to handle the PAR request URI callback [1]. 3. OAuth2/PAR Endpoint: The /oauth2/par endpoint is a standard OAuth 2.0 component defined in RFC 9126 [3][4]. It is used to push authorization payloads directly to the authorization server to obtain a request_uri, which is then used in the subsequent authorization request [5][6]. For detailed implementation, consult the README files within the mock-relying-party-ui and mock-relying-party-service directories of the repository, which outline the required environment variables such as ESIGNET_PAR_ENDPOINT and ESIGNET_PAR_AUD_URL [1][2]. Ensure your docker-compose file includes these definitions to correctly point to your eSignet PAR endpoint [1].
Citations:
- 1: https://github.com/mosip/esignet-mock-services/blob/master/docker-compose/README.md
- 2: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-service/README.md
- 3: https://docs.pingidentity.com/pingam/8.1/am-oauth2/oauth2-par-endpoint.html
- 4: https://developer.pingidentity.com/pingoneaic-api/am-oauth2/oauth2-par-endpoint.html
- 5: https://is.docs.wso2.com/en/next/guides/authentication/oidc/implement-login-with-par/
- 6: https://is.docs.wso2.com/en/7.1.0/guides/authentication/oidc/implement-login-with-par/
🌐 Web query:
github mosip/esignet-mock-services mock-identity-system MOSIP_ESIGNET_HOST token introspect
💡 Result:
The mosip/esignet-mock-services repository provides a mock implementation of the Identity Authentication (IDA) system for eSignet development and testing [1][2][3]. Regarding your specific query components: 1. Mock Identity System: This component facilitates local development of eSignet by simulating essential IDA functions [3]. It supports endpoints for creating and getting individual identities, authentication (via PIN, OTP, Biometric, Password, or WLA factors), and KYC exchange [1][3]. 2. MOSIP_ESIGNET_HOST: This environment variable is used within the MOSIP/eSignet ecosystem to define the base domain for eSignet services [4][5][6]. It is typically configured via Kubernetes ConfigMaps (often named esignet-global) [5][6]. Services use this variable to construct full URLs for various integration points, such as discovery endpoints and domain URIs [4][7][8]. 3. Token Introspect: The eSignet mock services repository itself focuses on the identity/authentication lifecycle (IDA) [1][2]. Standard OAuth2/OIDC token introspection is typically handled by the eSignet service or the underlying OIDC provider (e.g., Keycloak), rather than the mock-identity-system. Developers configuring eSignet environments often manage token and OIDC client configurations through the esignet-service properties and deployment scripts [9][5][7]. For technical implementation details, you can refer to the Swagger UI generally available on port 8082 of the running mock identity system [10]. Additional configuration properties and their mappings can be found in the eSignet configuration documentation [4][7][8].
Citations:
- 1: https://github.com/mosip/esignet-mock-services/tree/master/mock-identity-system
- 2: https://github.com/mosip/esignet-mock-services
- 3: https://docs.esignet.io/build-and-deploy/local-deployment/mock-id-system
- 4: https://github.com/mosip/mosip-config/blob/v1.3.0-ES/esignet-default.properties
- 5: https://community.mosip.io/t/deploying-esignet-containers/1982
- 6: https://github.com/mosip/esignet/blob/v1.6.1/deploy/README.md
- 7: https://github.com/mosip/documentation/blob/1.2.0/docs/integrations/esignet/configuring-esignet.md
- 8: https://docs.mosip.io/1.2.0/interoperability/integrations/e-signet/configuring-esignet
- 9: https://github.com/mosip/esignet-plugins/blob/f01f75ba/mock-plugin/README.md
- 10: https://github.com/mosip/esignet-mock-services/blob/master/docker-compose/README.md
🌐 Web query:
site:github.com/mosip/esignet-mock-services "MOSIP_ESIGNET_HOST"
💡 Result:
There is no environment variable officially named MOSIP_ESIGNET_HOST in the MOSIP eSignet documentation or the esignet-mock-services repository [1][2][3]. The MOSIP eSignet configuration typically relies on different environment variables to define service and UI locations. Specifically, the following variables are commonly used in the eSignet mock services suite: - ESIGNET_SERVICE_URL: Used to define the base URL for the MOSIP eSignet API (e.g., https://<ESIGNET_DOMAIN>/v1/esignet) [2][3]. - ESIGNET_UI_BASE_URL: Used to define the base URL for the eSignet UI [1][3]. - ESIGNET_AUD_URL: Used for the audience value in token endpoint client assertions [2]. If you are attempting to configure an eSignet deployment or a relying party mock, you should use ESIGNET_SERVICE_URL or ESIGNET_UI_BASE_URL depending on whether you are configuring the API backend or the frontend interface [2][3]. Always refer to the specific README files within the MOSIP GitHub repositories for the most accurate configuration parameters for your version [1][2][3].
Citations:
- 1: https://github.com/mosip/esignet-mock-services/blob/master/docker-compose/README.md
- 2: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-service/README.md
- 3: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-ui/README.md
🌐 Web query:
site:github.com/mosip/esignet-mock-services "ESIGNET_SERVICE_URL" "fetchUserInfo"
💡 Result:
In the context of the MOSIP eSignet project, ESIGNET_SERVICE_URL and the /fetchUserInfo endpoint are components used within the mock relying party service implementation for testing and integration [1][2]. ESIGNET_SERVICE_URL is an environment variable used to define the base URL for the MOSIP eSignet API [1]. It typically follows the format: https://<ESIGNET_DOMAIN>/v1/esignet [1]. The /fetchUserInfo endpoint is a POST service provided by the mock relying party service [1]. Its purpose is to exchange an authorization code (received after a user successfully authenticates and provides consent) for an access token and subsequently retrieve the user's information from the MOSIP eSignet services [1][2]. The request body for /fetchUserInfo requires the following parameters [1]: - code: The authorization code received from the authentication flow [1]. - client_id: The identifier for the relying party client [1]. - redirect_uri: The redirect URI used during the initial request [1]. - grant_type: Typically set to authorization_code [1]. - state: The state parameter for security verification [1]. This service facilitates testing OIDC flows in non-production environments by automating the interaction between a mock relying party and the eSignet authentication service [1][3].
Citations:
- 1: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-service/README.md
- 2: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-ui/README.md
- 3: https://github.com/mosip/esignet-mock-services
🌐 Web query:
"mock-relying-party-service" "ESIGNET_SERVICE_URL" "fetchUserInfo" "/v1/esignet"
💡 Result:
The mock-relying-party-service is a component in the MOSIP eSignet ecosystem used to simulate an OpenID Connect (OIDC) relying party during local development [1][2]. The ESIGNET_SERVICE_URL is a critical configuration variable for this service, typically set to the base URL of the eSignet identity provider [1]. It generally follows the format https://<ESIGNET_DOMAIN>/v1/esignet [1][3]. The /fetchUserInfo endpoint is a backend API exposed by the mock-relying-party-service [1][4][2]. Its function is to facilitate the completion of the OIDC authorization code flow [2]: 1. The frontend UI, after receiving an authorization code from eSignet, invokes the /fetchUserInfo endpoint on the mock-relying-party-service backend [4][2]. 2. The mock-relying-party-service then uses this code to call the eSignet token endpoint (often configured via ESIGNET_AUD_URL) to exchange it for an access token and an ID token [1][2]. 3. Finally, the service uses the obtained access token to call the eSignet UserInfo endpoint (e.g., /v1/esignet/oidc/userinfo) to retrieve the user's profile information, which it then returns to the UI [2][5]. If you encounter issues where this endpoint fails, verify that the ESIGNET_SERVICE_URL and other related environment variables (like CLIENT_PRIVATE_KEY) are correctly configured in your deployment [3][6]. If you are seeing 400 or 404 errors, double-check that the eSignet service is running and that the endpoint paths match your specific eSignet version's requirements [3].
Citations:
- 1: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-service/README.md
- 2: https://docs.esignet.io/build-and-deploy/local-deployment/mock-client-application
- 3: https://community.mosip.io/t/oidc-ui-redirect-in-to-relying-party-ui-health-portal-problem/1489
- 4: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-ui/README.md
- 5: https://docs.esignet.io/esignet-authentication/develop/configuration/.well-known/openid-configuration
- 6: https://community.mosip.io/t/esignet-on-local-deployment-relying-party-ui-health-portal/1133
🌐 Web query:
"mock-relying-party-service" "ESIGNET_PAR_ENDPOINT" "/oauth2/par"
💡 Result:
In the context of the eSignet mock-relying-party-service, ESIGNET_PAR_ENDPOINT is an environment variable used to configure the URL of the eSignet Authorization Server's Pushed Authorization Request (PAR) endpoint [1][2]. This configuration is essential for enabling the PAR flow, which is used to securely push authorization request parameters to the server [1][3]. Typically, this endpoint is configured with a path similar to https://<ESIGNET_DOMAIN>/v1/esignet/oauth/par [1][4]. When deploying or configuring the mock-relying-party-service, the following points are relevant: 1. Function: The ESIGNET_PAR_ENDPOINT variable tells the relying party where to send POST requests containing authorization parameters [1][5]. Upon successful verification, the server responds with a request_uri, which is then used in the subsequent authorization flow [5][6]. 2. Related Configuration: Often used alongside ESIGNET_PAR_ENDPOINT is ESIGNET_PAR_AUD_URL, which specifies the audience value for client assertions sent to the PAR endpoint [1][2]. 3. Discovery: The actual PAR endpoint URL for an eSignet environment is also exposed via the server's.well-known/oauth-configuration (or OpenID configuration) metadata as pushed_authorization_request_endpoint [4]. For developers, these variables are typically set in the environment or within docker-compose files to override default behavior and point the mock service to the appropriate eSignet instance [1][2].
Citations:
- 1: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-service/README.md
- 2: https://github.com/mosip/esignet-mock-services/blob/master/docker-compose/README.md
- 3: https://docs.esignet.io/roadmap-and-releases/versions/v1.7.0.md
- 4: https://docs.esignet.io/esignet-authentication/develop/configuration/.well-known/oauth-configuration
- 5: https://docs.esignet.io/esignet-authentication/develop/integration/relying-party/development-and-integration-with-esignet
- 6: https://github.com/mosip/esignet-mock-services/blob/master/mock-relying-party-ui/README.md
🌐 Web query:
"mock-identity-system" "MOSIP_ESIGNET_HOST" "identity authentication"
💡 Result:
The mock-identity-system is a lightweight, mock implementation of the MOSIP Identity Authentication (IDA) system, designed specifically for local development, testing, and proof-of-concept (POC) purposes [1][2][3]. It allows developers to simulate core identity authentication workflows within the eSignet framework without requiring a full, production-grade MOSIP deployment [1][4]. Key technical aspects include: 1. Supported Functionality: The system provides API endpoints to create identities, retrieve identity data, perform KYC authentication (kyc-auth), share KYC tokens (kyc-exchange), and send OTPs [5][1][6]. It supports multiple authentication factors, including PIN, OTP, Biometric (BIO), Password (PWD), and WLA [5][1][6]. 2. Role in eSignet Integration: eSignet integrates with identity systems via an Authenticator plugin [7]. For development, developers can use the mock-plugin to interface with the mock-identity-system, whereas a production environment uses the MOSIP identity plugin to communicate with the actual MOSIP IDA service [8][7][4]. 3. Configuration and Host Identification: In eSignet configurations (such as esignet-default.properties), the identity system host is often referenced using placeholders like ${mosip.esignet.host} [9][10]. When using the mock-identity-system, the host URL is pointed to the local mock instance, whereas in production, it is configured to point to the internal MOSIP API host [9][10]. 4. Identity Schema: The mock-identity-system uses a JSON schema to validate identity data, ensuring that create and update operations adhere to defined structures [5][6]. Developers can configure this via properties like mosip.mock.ida.identity.schema.url [5][6]. This mock system is not intended to replace production IDA services but provides a controlled, self-contained environment to evaluate and debug eSignet integration flows [1][2].
Citations:
- 1: https://docs.esignet.io/build-and-deploy/local-deployment/mock-id-system
- 2: https://github.com/mosip/documentation/blob/1.2.0/docs/id-lifecycle-management/supporting-services/mock-services.md
- 3: https://docs.esignet.io/esignet-authentication/develop/integration/relying-party/integration-options-and-discovery-endpoints.md
- 4: https://community.mosip.io/t/how-to-set-up-e-signet-in-development-purpose/606
- 5: https://github.com/mosip/esignet-mock-services/blob/master/mock-identity-system/README.md
- 6: https://github.com/mosip/esignet-mock-services/tree/master/mock-identity-system
- 7: https://docs.esignet.io/esignet-authentication/develop/integration/authenticator
- 8: https://github.com/mosip/esignet-plugins/tree/master/mosip-identity-plugin
- 9: https://github.com/mosip/documentation/blob/1.2.0/docs/integrations/esignet/configuring-esignet.md
- 10: https://docs.mosip.io/1.2.0/interoperability/integrations/e-signet/configuring-esignet
Use host-resolvable eSignet URLs for server-side OIDC calls.
mock-relying-party-service uses the eSignet API settings, including ESIGNET_SERVICE_URL, ESIGNET_AUD_URL, ESIGNET_PAR_ENDPOINT, and ESIGNET_PAR_AUD_URL, for backend OAuth2/OIDC operations such as token exchange, PAR, and userinfo retrieval. With bridge networking, localhost:8088 inside that container resolves to the container itself, so these paths can fail. Replace these with the eSignet host used by external clients, or explicitly configure Docker networking such as extra_hosts: [host.docker.internal:host-gateway] alongside matching production HTTPS ports/routes if mock-relying-party-ui also resolves eSignet from the browser. The MOSIP_ESIGNET_HOST value for mock-identity-system depends on its service version and integration scope and needs the same host-validity check before merge.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/dependent-docker-compose.yaml` at line 29, Update the eSignet
host configuration in the dependent Docker Compose setup so server-side OIDC
URLs used by mock-relying-party-service resolve outside its container instead of
pointing to localhost:8088; apply the same valid host and port consistently to
ESIGNET_SERVICE_URL, ESIGNET_AUD_URL, ESIGNET_PAR_ENDPOINT, and
ESIGNET_PAR_AUD_URL, and validate MOSIP_ESIGNET_HOST for mock-identity-system
against its service version and integration scope.
| environment: | ||
| - ESIGNET_SERVICE_URL=http://localhost:8088 | ||
| - ESIGNET_AUD_URL=http://localhost:8088/oauth2/token | ||
| - ESIGNET_PAR_ENDPOINT=https://localhost:8088/oauth2/par |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Scheme mismatch on ESIGNET_PAR_ENDPOINT.
ESIGNET_PAR_ENDPOINT uses https://localhost:8088/oauth2/par, but every other esignet URL in this block (ESIGNET_SERVICE_URL, ESIGNET_AUD_URL, ESIGNET_PAR_AUD_URL, and ESIGNET_UI_BASE_URL at line 60) uses http://localhost:8088. Nothing in this stack terminates TLS on port 8088. The PAR request likely fails a TLS handshake against a plain-HTTP listener.
🐛 Proposed fix
- - ESIGNET_PAR_ENDPOINT=https://localhost:8088/oauth2/par
+ - ESIGNET_PAR_ENDPOINT=http://localhost:8088/oauth2/par📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - ESIGNET_PAR_ENDPOINT=https://localhost:8088/oauth2/par | |
| - ESIGNET_PAR_ENDPOINT=http://localhost:8088/oauth2/par |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/dependent-docker-compose.yaml` at line 41, Update the
ESIGNET_PAR_ENDPOINT value to use http://localhost:8088/oauth2/par, matching the
scheme used by the other esignet URL configuration values in this compose block.
| CREATE TABLE mockidentitysystem.kyc_auth( | ||
| kyc_token VARCHAR(255), | ||
| individual_id VARCHAR(255), | ||
| partner_specific_user_token VARCHAR(255), | ||
| response_time TIMESTAMP, | ||
| transaction_id VARCHAR(255), | ||
| validity INTEGER | ||
| ); |
There was a problem hiding this comment.
🚀 Performance & Scalability | 🟠 Major | ⚡ Quick win
Missing indexes and primary key on frequently-queried transaction/identity columns.
kyc_auth (lines 67-74) has no primary key and no index on individual_id, transaction_id, or kyc_token, even though KYC-auth records are looked up by these columns. verified_claim (lines 82-94) has an index-free individual_id column that is used to join back to mock_identity. As transaction volume grows, lookups and joins on these columns force sequential scans.
⚡ Proposed fix
CREATE TABLE mockidentitysystem.kyc_auth(
kyc_token VARCHAR(255),
individual_id VARCHAR(255),
partner_specific_user_token VARCHAR(255),
response_time TIMESTAMP,
transaction_id VARCHAR(255),
validity INTEGER
);
+CREATE INDEX idx_kyc_auth_individual_id ON mockidentitysystem.kyc_auth(individual_id);
+CREATE INDEX idx_kyc_auth_transaction_id ON mockidentitysystem.kyc_auth(transaction_id); CREATE TABLE mockidentitysystem.verified_claim(
...
CONSTRAINT pk_verified_claim_id PRIMARY KEY (id)
);
+CREATE INDEX idx_verified_claim_individual_id ON mockidentitysystem.verified_claim(individual_id);As per path instructions, "Flag missing indexes on columns used in JOIN or WHERE clauses on large transaction/identity tables."
Also applies to: 82-94
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/mock-id-init.sql` around lines 67 - 74, Update the kyc_auth
and verified_claim table definitions to add a primary key for kyc_auth and
indexes on kyc_auth.individual_id, kyc_auth.transaction_id, kyc_auth.kyc_token,
and verified_claim.individual_id, using the existing schema naming conventions
and preserving all current columns.
Source: Path instructions
| INSERT INTO mockidentitysystem.mock_identity (individual_id,identity_json) VALUES | ||
| ('1774231323','{"individualId":"1774231323","pin":"545411","email":"siddhartha.km@gmail.com","phone":"+919427357934","fullName":[{"language":"fra","value":"Siddharth K Mansour"},{"language":"ara","value":"تتگلدكنسَزقهِقِفل دسييسيكدكنوڤو"},{"language":"eng","value":"Siddharth K Mansour"}],"nickName":[{"language":"fra","value":"Siddharth K Mansour"},{"language":"ara","value":"تتگلدكنسَزقهِقِفل دسييسيكدكنوڤو"},{"language":"eng","value":"Siddharth K Mansour"}],"preferredUsername":[{"language":"fra","value":"Siddharth K Mansour"},{"language":"ara","value":"تتگلدكنسَزقهِقِفل دسييسيكدكنوڤو"},{"language":"eng","value":"Siddharth K Mansour"}],"givenName":[{"language":"fra","value":"Siddharth K Mansour"},{"language":"ara","value":"تتگلدكنسَزقهِقِفل دسييسيكدكنوڤو"},{"language":"eng","value":"Siddharth K Mansour"}],"middleName":[{"language":"fra","value":"Siddharth K Mansour"},{"language":"ara","value":"تتگلدكنسَزقهِقِفل دسييسيكدكنوڤو"},{"language":"eng","value":"Siddharth K Mansour"}],"familyName":[{"language":"fra","value":"Mansour"},{"language":"ara","value":"تتگلدكنسَزقهِقِفل"},{"language":"eng","value":"Mansour"}],"gender":[{"language":"eng","value":"Male"},{"language":"fra","value":"Mâle"},{"language":"ara","value":"ذكر"}],"dateOfBirth":"1987/11/25","streetAddress":[{"language":"eng","value":"Slung"}],"locality":[{"language":"eng","value":"yuanwee"}],"password":"A4BA98331ACD26F1E8598F4EDE21582D92872F34941ACF307864242D285BF626","preferredLang":"eng","locale":"en","region":[{"language":"eng","value":"yuanwee"}],"zoneInfo":"test zone","postalCode":"45009","country":[{"language":"fra","value":"CMâttye"},{"language":"ara","value":"دسييسيكدك"},{"language":"eng","value":"Cmattey"}],"encodedPhoto":"data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAAQABAAD/wAARCAMABAADAREAAhE"}'); |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Plaintext identity identifier and PIN, plus a real-looking personal email, in seed data.
The seed row stores individual_id (a UIN-like identifier) and "pin":"545411" in plaintext inside identity_json, with no encryption note. This matches the SQL review rule for UIN/VID/OTP handling. Separately, "email":"siddhartha.km@gmail.com" looks like a genuine personal email address rather than an obviously synthetic one (for example test.user@example.com). Committing a real email address to a public repository is a privacy exposure independent of whether the rest of the record is mock data.
Replace the email with a clearly synthetic domain (example.com/example.org), and add a comment documenting that pin is intentionally plaintext test data for the mock stack (not a real credential).
As per path instructions, "Flag any INSERT/UPDATE of UIN, VID, or OTP values in plaintext without encryption notes."
🧰 Tools
🪛 Betterleaks (1.7.0)
[high] 132-132: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/mock-id-init.sql` around lines 131 - 132, Update the
mock_identity seed INSERT for individual_id 1774231323 by replacing the personal
email with an obviously synthetic example.com or example.org address, and add a
SQL comment documenting that the plaintext pin is intentional test data for the
mock stack and not a real credential.
Source: Path instructions
| location / { | ||
| # alias /usr/share/nginx/html; | ||
| try_files $uri $uri/ /index.html; | ||
| } |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value
Remove the dead commented-out alias directive.
Line 51 (# alias /usr/share/nginx/html;) is leftover commented-out code from an earlier configuration attempt. It adds no value now that root is set at line 14.
🧹 Proposed cleanup
location / {
- # alias /usr/share/nginx/html;
try_files $uri $uri/ /index.html;
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| location / { | |
| # alias /usr/share/nginx/html; | |
| try_files $uri $uri/ /index.html; | |
| } | |
| location / { | |
| try_files $uri $uri/ /index.html; | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/rp-nginx.conf` around lines 50 - 53, Remove the unused
commented-out alias directive from the location / block, leaving the active
try_files configuration unchanged.
3 participants
Summary by CodeRabbit