Integrate a new face-ID search application at `faceai.regalamiunsorriso.it` with the legacy site at `www.regalamiunsorriso.it`, while keeping changes to the legacy site small and preserving the current download/account rules.
Relevant current integration points in the legacy site:
- The race photo page still uses a `select` with id `tipoPuntoFoto` in `www/fotoCR.jsp` and `www/fotoCR-en.jsp`.
- The client-side navigation for race photo search is built in `www/_js/rus-ecom-240621.js` through `searching()`, `searchingTPF()`, `searchingPF()`, `goPage()`, and `mostraFoto()`.
- The logged-in user is exposed from the Java session as `utenteLogon` and related session beans in shared JSP includes such as `www/_inc_header.jsp`.
- The current photo modal and download gate are driven by `www/fotoView.jsp`, where download access is checked with `user.puoScaricareFoto()` or free-race logic.
- The actual download link still goes through the existing legacy file path and business rules, so photo-credit subtraction should remain on the legacy side instead of being reimplemented in Node.
## Important Constraint
There is one hard technical constraint to make explicit:
The legacy site identity is held in the Java web session, not in PHP. That means a pure PHP-only bridge on `www` cannot securely determine who the user is from the existing session cookie unless there is already an external shared auth service.
Because of that, the recommended plan needs one of these two options:
1. Preferred: a very small server-side bridge on the legacy Java or JSP side, or at the reverse proxy level with app support, to mint a trusted handoff token for FaceAI.
There is also an operational constraint from the implementation side:
The bridge should be designed so it can be deployed without setting up a full local Java development environment and without recompiling the existing application locally. That makes a tiny JSP-based handoff endpoint or a minimal existing-controller extension preferable to adding new compiled Java modules.
Do not try to make the Node app directly trust the legacy `JSESSIONID` cookie.
Even if the cookie domain is widened to `.regalamiunsorriso.it`, the Node app still cannot safely resolve that session unless both apps share the same session store and session format. That would be more invasive than a handoff bridge.
Instead:
1. User clicks the new FaceAI button on the legacy race page.
2. Legacy site creates a short-lived signed token with:
- legacy user id
- email
- display name
- language
- access flags for FaceAI
- race id
- race slug or descriptor
- current page URL as `returnUrl`
- expiry time, ideally 1 to 5 minutes
3. Browser is redirected to `https://faceai.regalamiunsorriso.it/auth/callback?token=...`
4. FaceAI validates the token and sets its own cookie on `.regalamiunsorriso.it`, for example `rus_faceai_session`
5. FaceAI uses its own session cookie afterward
This gives the new app shared-domain cookies while avoiding direct dependency on the Java session internals.
The handoff token should already include whether the feature is allowed. That check should be done on the legacy side where the real account state already exists.
Minimal validation inputs:
- logged-in user exists
- account is active enough to use the feature
To avoid unnecessary database reads, compute this from already-loaded session/account state when possible. Only hit the database if the existing session object does not contain enough information.
## Minimal Changes To The Old Site
The smallest practical change set on the legacy site is:
The old site needs one small return-integration path so FaceAI can send the user back to the race page showing only the matched images.
That should be implemented as one of these:
- a new legacy endpoint that accepts a signed FaceAI result token and loads the matched photo set into the request or session before rendering the race page
- an extension of the existing photo search flow so it can accept a FaceAI result id and fetch the matched photo ids server-side
This is preferable to putting the matched ids directly in the browser URL, because the result set may be long and should remain tamper-resistant.
8. FaceAI polls until the processing job completes.
9. Once the result is ready, FaceAI redirects the browser back to the original race page on `www`.
10. The legacy site resolves the matched photo ids and renders the race page filtered to those photos only, similar in spirit to the existing pettorale-based flow.
11. User opens and downloads photos exactly as they do today, through the legacy site.
For v1, the header should be a very close copy, not just a lightweight brand reference. The goal is that the user should feel they are still inside the same site family during the upload and waiting flow.
