AdminPage's local validateWebsiteUrl accepts bogus schemes like "httpx://" due to a loose startsWith('http') check

[Jagadeeshftw]

Description

src/features/admin/pages/AdminPage.tsx defines its own website-URL validator instead of using the already-correct shared one:

const validateWebsiteUrl = (url: string) => {
  if (!url.trim()) return null
  try {
    new URL(url)
    if (!url.startsWith('http')) return 'URL must start with http:// or https://'
    return null
  } catch {
    return 'Please enter a valid URL (e.g., https://example.com)'
  }
}

url.startsWith('http') is not the same check as validating the URL's protocol. Any scheme that happens to start with the four characters http — e.g. httpx://evil.example, httpfoo://x — passes both new URL(url) (a valid, if unusual, custom scheme) and startsWith('http'), and is accepted as a valid ecosystem website URL. Meanwhile the shared, already-tested helper in src/shared/utils/validation.ts does this correctly:

export function validateUrl(value: string): string | true {
  ...
  try {
    const url = new URL(trimmed)
    if (url.protocol !== 'http:' && url.protocol !== 'https:') {
      return 'URL must start with http:// or https://'
    }
    ...

validateUrl checks url.protocol exactly against 'http:'/'https:', correctly rejecting httpx:// and any other non-http(s) scheme. AdminPage.tsx duplicates this validation logic locally instead of importing the shared, correct implementation, and its copy is subtly broken as a result — a malformed/unexpected-scheme "website URL" can be saved against an ecosystem and later rendered as a clickable link (AdminPage.tsx itself renders ecosystem.website_url in an <a href={...} target="_blank">).

Requirements

• Replace AdminPage.tsx's local validateWebsiteUrl with the shared validateUrl from src/shared/utils/validation.ts (adapting its string | true return shape to this file's string | null convention, or updating the call sites).
• No other change to the ecosystem create/edit form behavior for genuinely valid http(s):// URLs.

Suggested execution

1. Fork the repo and create a branch: git checkout -b fix/adminpage-website-url-validation
2. Remove the local validateWebsiteUrl function from AdminPage.tsx.
3. Import validateUrl from shared/utils/validation.ts and adapt its return value at the two call sites (handleSubmit, handleEditSubmit).
4. Add a test asserting httpx://evil.example (and similar bogus schemes) are now rejected by the ecosystem create/edit form.

Example commit message

fix: use the shared validateUrl helper instead of AdminPage's loose startsWith('http') check

Acceptance criteria

• AdminPage.tsx no longer defines its own validateWebsiteUrl.
• Non-http(s) schemes like httpx://... are rejected by the ecosystem create/edit form.
• A test covers the rejection of a scheme that merely starts with "http" but isn't http:/https:.

Security notes

A malformed scheme accepted as a "website URL" and later rendered as a clickable target="_blank" link is a low-severity but real input-validation gap; using the shared, protocol-exact validateUrl closes it and removes the duplicate-logic drift risk entirely.

Guidelines

• Minimum 95% test coverage
• Timeframe: 96 hours

[1nonlypiece]

Hi Maintainers 👋,

I’d like to apply for this issue.

I have hands-on experience with Next.js frontend development as well as Stellar smart contracts using Rust (Soroban). I’m comfortable working with Figma designs, integrating APIs/wallets on the frontend, and implementing, testing, and optimizing smart contracts on Stellar.

I can follow the project guidelines, communicate progress clearly, and deliver clean, well-tested code within the expected timeline.

Looking forward to contributing to the project 🚀
Thanks!

[Jagadeeshftw]

Assigned @1nonlypiece! Go ahead and open a PR referencing this issue (Closes #890) when ready. t.me/+vTbe0hOUKrFhNTJl