Skip to content

FEATURE REQUEST: Update Supabase key system from legacy #153

@TaeBbong

Description

@TaeBbong

Is your feature request related to a problem?

  • Yes, it is related to a problem

Describe the feature you'd like

This issue was fully identified and analyzed by myself. Claude was only used to assist with writing in English.

🌟 Feature Description

Currently, NeuroTrack uses Supabase's legacy JWT-based API keys (anon key and service_role key) for all client-server communication. Supabase announced in September 2024 a migration to a new key system — publishable keys (sb_publishable_...) and secret keys (sb_secret_...). As of November 1, 2025, new and restored Supabase projects no longer include legacy keys, and legacy keys are scheduled for permanent deletion in late 2026. This issue tracks the work needed to migrate NeuroTrack to the new key system.

🔍 Problem Statement

The legacy JWT-based keys have several known shortcomings that the new system addresses:

  • No independent key rotation without downtime — rotating legacy keys required service interruption
  • Mobile app deployment lag — forced key rotation could cause days-to-weeks of downtime for users on older app versions
  • Insecure defaults — legacy JWTs had 10-year expiry, were large, hard to parse, and prone to insecure logging
  • No granular revocation — compromised keys couldn't be individually revoked

Beyond the general migration, NeuroTrack has a code-level breaking change that goes beyond simple renaming:

  1. patient/lib/repository/supabase_assessments_repository.dart — The anon key is manually passed as Authorization: Bearer $jwtToken when invoking the Edge Function. New publishable keys are not JWTs, so this pattern will fail. The fix is to remove the manual header and rely on the SDK's automatic auth token injection.

  2. supabase/functions/evaluate-assessments/index.ts — The Edge Function reads SUPABASE_ANON_KEY from auto-injected environment variables. After migration, this env var may not auto-update, and JWT verification at the Edge Function level needs to be reviewed (new keys cannot pass JWT verification).

  3. Environment variables and documentation.env.example files in patient/, therapist/, and supabase/scripts/, as well as README.md, all reference legacy key names.

🎯 Expected Outcome

  • Replace all SUPABASE_ANON_KEY references with SUPABASE_PUBLISHABLE_KEY (or equivalent) across Flutter apps, Edge Functions, and environment configs
  • Replace SUPABASE_KEY (service role) references with SUPABASE_SECRET_KEY in backend scripts
  • Refactor supabase_assessments_repository.dart to stop manually injecting the API key as a Bearer token — instead, let the Supabase SDK handle auth headers automatically
  • Review Edge Function JWT verification strategy and update deployment config if needed (--no-verify-jwt or user-JWT-based auth)
  • Update README.md setup instructions to reflect the new key names

📷 Screenshots and Design Ideas

Affected files:

File Change Type
patient/.env.example Rename variable
therapist/.env.example Rename variable
patient/lib/main.dart Update env var name
therapist/lib/main.dart Update env var name
patient/lib/repository/supabase_assessments_repository.dart Code refactor — remove manual Bearer token
supabase/functions/evaluate-assessments/index.ts Update env var + review JWT verification
supabase/scripts/.env.example Rename variable
supabase/scripts/seed_assessments.js Update env var name
README.md Update documentation

📋 Additional Context

There is an ongoing discussion in the community channel about removing cloud dependencies from the project. The AOSSIE group is moving toward a direction where sensitive data should not reside on external servers, with discussions leaning toward a local database approach. If the decision is made to drop Supabase Cloud in favor of a local database solution, this migration may become unnecessary — the project could continue using the legacy keys until the cloud dependency is removed entirely. This issue should be considered in the context of that broader architectural decision.

References:

Record

  • I agree to follow this project's Code of Conduct
  • I want to work on implementing this feature

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions