Skip to content

fix: Portfolio creation accepts arbitrary strings as userAddress — no Stellar address validation #63

Open
#72
Open
fix: Portfolio creation accepts arbitrary strings as userAddress — no Stellar address validation#63
#72
Labels
backendBackend relatedbugSomething isn't workingfrontendFrontend UIhelp wantedExtra attention is needed

Description

@grantfox-oss
grantfox-oss
bot
opened on Aug 22, 2026

Problem

In backend/src/api/validation.ts, createPortfolioSchema validates userAddress only as z.string().min(1). The codebase already has a working stellarAddressSchema (using the Stellar SDK's StrKey.isValidEd25519PublicKey) in the same file, but createPortfolioSchema does not use it.

This means any caller can create portfolios under arbitrary identifiers, which pollutes the database with unlinked records and could cause collisions if two different users happen to use the same string.

Proposed Fix

1. Use existing stellarAddressSchema

Change the userAddress field in createPortfolioSchema from z.string().min(1) to stellarAddressSchema.

2. Handle demo mode

The frontend falls back to "demo-user" when no wallet is connected. Options:

  • Add a separate demoAddress field for demo mode and validate userAddress only when in non-demo mode
  • Or require wallet connection before portfolio creation

3. Add validation tests

Test that invalid addresses are rejected and valid G... addresses are accepted.

Files to modify

  • backend/src/api/validation.ts — update createPortfolioSchema
  • backend/src/api/routes.ts — update POST /portfolio handler if needed
  • frontend/src/components/PortfolioSetup.tsx — send actual publicKey instead of "demo-user"
  • backend/src/api/__tests__/routes.test.ts — add validation tests

Acceptance Criteria

  • userAddress field uses stellarAddressSchema instead of z.string().min(1)
  • Frontend sends actual Stellar address instead of "demo-user" fallback
  • Test: POST /portfolio with userAddress: "not-a-valid-key" returns 400
  • Test: POST /portfolio with valid G... address returns 201
  • API documentation updated to reflect userAddress validation

Affected Area

Backend and Frontend

Activity

  1. grantfox-oss
    added
    bugSomething isn't working
    help wantedExtra attention is needed
    backendBackend related
    frontendFrontend UI
    on Aug 22, 2026

  2. waterWang commented on Aug 23, 2026

    @waterWang
    waterWang
    on Aug 23, 2026

    I would like to work on this issue. Will update createPortfolioSchema to use stellarAddressSchema, handle demo mode, and add validation tests.

  3. waterWang commented on Aug 24, 2026

    @waterWang
    waterWang
    on Aug 24, 2026

    I have submitted PR #72 to address this issue. Changes:

    1. Changed createPortfolioSchema.userAddress from z.string().min(1) to z.union([stellarAddressSchema, z.literal("demo-user")])
    2. Frontend already sends publicKey when wallet is connected, falls back to "demo-user" for demo mode
    3. Added validation tests (valid G... address, demo-user, invalid address rejection)

  4. shobhamerabacha-star commented on Sep 10, 2026

    @shobhamerabacha-star
    shobhamerabacha-star
    on Sep 10, 2026

    Hey team,

    I would like to resolve this issue. Here is my proposed execution plan:

    • Implementation: Trace the regression in grantFoxin/SentientFi causing fix: Portfolio creation accepts arbitrary strings as userAddress — no Stellar address validation and implement a targeted, minimal fix.
    • Testing & Verification: Add a reproduction test case to prevent any future regression.
    • Delivery: Ready to ship a thoroughly tested PR within 12–24 hours with passing CI.

    Happy to pick this up today—please assign to me!

  5. guptakumarranjeet150 commented on Sep 13, 2026

    @guptakumarranjeet150
    guptakumarranjeet150
    on Sep 13, 2026

    Hello! I'd like to work on this issue.

    I would love to take this on. My planned approach:

    • Trace the regression in grantFoxin/SentientFi causing fix: Portfolio creation accepts arbitrary strings as userAddress — no Stellar address validation and implement a targeted, minimal fix.
    • Add a reproduction test case to prevent any future regression.

    Happy to pick this up today—please assign to me!

  6. rupesh-kumar-sah commented on Oct 3, 2026

    @rupesh-kumar-sah
    rupesh-kumar-sah
    on Oct 3, 2026

    Hi,

    I have experience with similar implementations and would like to take this on.

    Solution overview:

    1. Implement resilient asynchronous worker processing with backpressure handling.
    2. Enforce transactional integrity with cursor pagination and idempotency checks.
    3. Add retry logic with exponential backoff for transient failures.
    4. Verify end-to-end throughput under concurrent execution test scenarios.

    Please assign this to me if the plan looks good. Thanks!

  7. ranjeet150 commented on Oct 3, 2026

    @ranjeet150
    ranjeet150
    on Oct 3, 2026

    Greetings,

    I would like to work on this issue.

    Technical outline:

    1. Implement resilient asynchronous worker processing with backpressure handling.
    2. Enforce transactional integrity with cursor pagination and idempotency checks.
    3. Add retry logic with exponential backoff for transient failures.
    4. Verify end-to-end throughput under concurrent execution test scenarios.

    I can deliver a clean, tested PR within 24 hours. Please assign!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    backendBackend relatedbugSomething isn't workingfrontendFrontend UIhelp wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions