KrikoriosandClaude Opus 5
8807ff41c5
Driver onboarding now photographs the licence, ID card and vehicle
registration and reads the credential fields off them, plus a camera-only
profile selfie riders check the arriving driver against. Adds in-app chat
and WebRTC calls, push-backed ride offers, ratings, cancellation and
payment sheets, settlement, and the owner dashboard endpoints behind them.
Camera permission on Android:
- Declare CAMERA and READ_MEDIA_IMAGES in the manifest. expo-image-picker's
own plugin never declares CAMERA, and Android denies a request for an
undeclared permission instantly and silently — no dialog is ever shown,
which is indistinguishable from the app not asking at all.
- Handle canAskAgain: once Android stops showing the dialog, repeating why
we need it is a dead end, so offer Open Settings instead (lib/capture-
permission.ts), matching what the location flow already did.
Session: a 401 on a request that carried a token now ends the session
instead of being reinterpreted per-screen — driver-home had been reading it
as "this user has no driver profile" and showing an onboarding form to an
already-onboarded driver. Requests without a token are exempt so a failed
sign-in doesn't sign you out, and the notification is latched per token so
concurrent polls tear the session down once. (root) gains the auth guard
that turns that into the sign-in screen; app/index.tsx only guarded the way
in, leaving a session that ended mid-screen with nowhere to go.
Also ignore .uploads/ — it holds driver licence, ID and vehicle scans plus
profile photos, which are personal data and must not be committed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
46 lines
1.7 KiB
TypeScript
46 lines
1.7 KiB
TypeScript
import Constants from "expo-constants";
|
|
|
|
/**
|
|
* Turns whatever sits in `drivers.profile_image_url` into something an
|
|
* `<Image>` can load.
|
|
*
|
|
* That column holds one of two things. A driver who took their photo in the
|
|
* app stores an opaque name ("a1b2….jpg") that only means anything to
|
|
* /(api)/driver/photo; an owner who filled the field in from the admin
|
|
* dashboard stores a full external URL. Both have to render, so the shape of
|
|
* the value decides how it is read — which also means older profiles carrying
|
|
* a real URL keep working untouched.
|
|
*/
|
|
const ABSOLUTE = /^(https?:|data:|file:|blob:)/i;
|
|
|
|
/**
|
|
* The origin an <Image> should fetch from.
|
|
*
|
|
* `fetchAPI` gets away with relative paths because expo-router resolves them,
|
|
* and in development it resolves them against the Metro dev server rather than
|
|
* the configured origin. An <Image> URL has to be absolute, so it has to make
|
|
* the same choice by hand — otherwise every API call goes to the laptop while
|
|
* every avatar goes to production (or, worse, to the placeholder origin in
|
|
* .env, and silently renders nothing).
|
|
*/
|
|
const apiOrigin = (): string => {
|
|
if (__DEV__) {
|
|
const hostUri = Constants.expoConfig?.hostUri;
|
|
if (hostUri) return `http://${hostUri}`;
|
|
}
|
|
|
|
return (process.env.EXPO_PUBLIC_SERVER_URL ?? "").replace(/\/+$/, "");
|
|
};
|
|
|
|
export const driverPhotoUri = (value?: string | null): string | undefined => {
|
|
if (!value) return undefined;
|
|
if (ABSOLUTE.test(value)) return value;
|
|
|
|
const origin = apiOrigin();
|
|
if (!origin) return undefined;
|
|
|
|
// The literal "(api)" is part of the path — this app's routes are addressed
|
|
// that way throughout, not as an expo-router group that gets stripped.
|
|
return `${origin}/(api)/driver/photo?name=${encodeURIComponent(value)}`;
|
|
};
|