@autobusal/order-confirm 1.2.1 → 1.3.0

package/OrderConfirm.tsx

@@ -4,12 +4,12 @@ import { useSearchParams, useParams, useNavigate, Navigate } from 'react-router-
 import { AiOutlineCheck } from 'react-icons/ai';
 import { BiErrorAlt } from 'react-icons/bi';
 import { IoReturnUpBackOutline } from 'react-icons/io5';
-import { Meta, Button } from '@autobusal/common';
+import { Meta, Button, LoadingParagraph } from '@autobusal/common';
 import Reason from './Reason';
 import Telegram from './Telegram/Telegram';
 import { Title, Actions } from './styles';
 import { useUserStore } from '@autobusal/providers/stores/user';
-import { useReleaseOrder } from './services';
+import { useReleaseOrder, useGetOrderNumber } from './services';
 import { flush } from '@autobusal/providers/Setup/commerce';
 
 interface Props {
@@ -25,6 +25,21 @@ const escapeHtml = (value: string): string => (
   }[char] as string))
 );
 
+/*
+ * What stands in for the confirmation sentence until the booking reference
+ * has been fetched.
+ *
+ * The page's own <Title> already says "reserved" / "purchased", so the
+ * outcome is on screen the whole time - only the reference is waited for,
+ * and the two lines sit in the same `.box` the sentence will land in, so
+ * nothing shifts when it arrives.
+ */
+const Waiting = (): JSX.Element => (
+  <div className="box">
+    <LoadingParagraph count={ 2 } />
+  </div>
+);
+
 // long enough to read the confirmation and its order number, short enough
 // that nobody wonders whether the page has finished
 const REDIRECT_AFTER = 5000;
@@ -40,6 +55,24 @@ const OrderConfirm = ({ t }: Props): (JSX.Element | null) => {
 
   const { data: UserData } = useUserStore();
 
+  const { data: NumberData, isPending: numberPending } = useGetOrderNumber(hash);
+
+  /*
+   * Claude - 2026-08-31 (ruled by Ferjolt: "We should not show the internal
+   * hash anywhere but should show always the PNR").
+   *
+   * This used to fall back to `hash` when the lookup had not answered, which
+   * is how a live buyer came to see a 15-character Hashids token where the
+   * six-character booking reference belonged: the lookup was rate-limited
+   * during the "Too Many Attempts" episode, the fallback fired, and the page
+   * confidently printed an internal credential the visitor cannot type into
+   * "check your reservation" and cannot quote to anyone.
+   *
+   * The hash is no longer a fallback at all. It is not a booking reference,
+   * so it is never the answer to "what is my booking reference".
+   */
+  const orderNumber = NumberData?.order_number ?? '';
+
   /*
    * Claude - 2026-08-22 (audit finding BOOK-11-b): this page is where the
    * gateway's cancelUrl AND failUrl land, and it used to say "your order
@@ -131,9 +164,24 @@ const OrderConfirm = ({ t }: Props): (JSX.Element | null) => {
         { t(`order_confirm.title.${ type }`) }
       </Title>
 
-      <div className="box" dangerouslySetInnerHTML={{
-        __html: t(`order_confirm.content.${ type === 'cancelled' && released ? 'released' : type }`, { order: `<strong>${ escapeHtml(String(hash ?? '')) }</strong>` })
-      }} />
+      { /* Claude - 2026-08-29 (audit A3-03h, low): the booking's REAL order
+           number, not the URL hash. This page announced the 15-character
+           Hashids token as "your order with number ..." while the email, the
+           ticket and the invoice all named the six-character PNR - and the
+           PNR is what /viewtrip's own Order Number field accepts and what a
+           support desk can look up.
+
+           2026-08-31: the sentence waits for the number rather than filling
+           the gap with the hash. It is one short GET on a page that then sits
+           for five seconds before redirecting, so the wait is not felt - and
+           announcing the wrong reference is worse than announcing it a moment
+           later. `order` is bolded because the visitor is expected to WRITE
+           IT DOWN; it is the only thing on the page they need to keep. */ }
+      { numberPending ? <Waiting /> : (
+        <div className="box" dangerouslySetInnerHTML={{
+          __html: t(`order_confirm.content.${ type === 'cancelled' && released ? 'released' : type }`, { order: `<strong>${ escapeHtml(orderNumber) }</strong>` })
+        }} />
+      ) }
 
       <>
         { (type === 'cancelled' && message !== '') && <Reason message={ message } t={ t } /> }

package/package.json

@@ -1,7 +1,10 @@
 {
   "name": "@autobusal/order-confirm",
-  "version": "1.2.1",
+  "version": "1.3.0",
   "author": "Ferjolt Ozuni",
   "type": "module",
-  "main": "index.ts"
+  "main": "index.ts",
+  "publishConfig": {
+    "access": "public"
+  }
 }

package/services.ts

@@ -36,6 +36,42 @@ export const useGetOrderTelegramStatus = (hash: string): UseQueryResult<OrderTel
   })
 );
 
+/**
+ * The booking's real Order Number, from the hash this page was given.
+ *
+ * Claude - 2026-08-29 (audit A3-03h, low). The confirmation had only the URL
+ * hash and printed it as "your order with number gnl3d5kolxpw78q", while the
+ * email, the ticket and the invoice for the same booking all said ZRQGV2 -
+ * and ZRQGV2 is the code the /viewtrip lookup and a support desk actually
+ * accept. Not retried and allowed to fail: a confirmation page must never
+ * fail to confirm, so the caller falls back to the hash.
+ */
+export const useGetOrderNumber = (hash?: string): UseQueryResult<{ order_number: string }> => (
+  useQuery({
+    queryKey: ['order-number', hash],
+    enabled: hash !== undefined && hash !== '',
+
+    /*
+     * Claude - 2026-08-31: this is the one query on the page that MUST answer.
+     * It was `retry: false`, and a single rate-limited response was enough to
+     * lose the buyer their booking reference on the page that exists to give
+     * it to them - which is how a live buyer was shown the internal hash.
+     *
+     * Retrying is safe here in a way it is not for the payment calls in the
+     * same file: this is a read, it creates nothing, and repeating it cannot
+     * duplicate an order the way a repeated initiation could.
+     */
+    retry: 3,
+    queryFn: async () => (
+      await apiClient
+        .get('/api/orders/number', { params: { hash } })
+        .then(response => (
+          response.data
+        ))
+    )
+  })
+);
+
 /*
  * Claude - 2026-08-22 (audit finding BOOK-11-b): the "cancelled" return
  * page used to claim the order was cancelled while the reservation kept

package/CHANGELOG.md

@@ -1,76 +0,0 @@
-# Changelog
-
-## 1.2.1
-
-### Fixed
-
-- **The cancelled-payment page tells the truth.** It used to say "your order has been cancelled" while the reservation kept holding its seats for two more hours - and the gateway's failUrl lands on the same page, so auto-cancelling would kill declined-card retries. New copy (payment not completed, nothing charged, reservation still held), a Try-again action, and a real "Release my reservation" button through the hash-authorised cancel endpoint. (Audit BOOK-11-b.)
-
-## 1.2.0
-
-- Announces `purchase` on arrival, for a **purchased** order only — a reservation is not revenue and a cancelled attempt certainly is not. Cleared as it fires, so refreshing this page (a plain URL with the buyer's order number on it) cannot report the same sale twice.
-
-All notable changes to this package are documented here. This project follows
-[Keep a Changelog](https://keepachangelog.com/) and [Semantic Versioning](https://semver.org/).
-
-## [1.1.3] - 2026-08-01
-
-### Changed
-
-- **The confirmation moves on to the order after five seconds**, where the
-  tickets and the invoice actually are. A dead-end success page turned
-  downloading the thing you had just bought into a hunt. Only for purchased
-  and reserved: a cancellation has nothing to go to, and bouncing someone
-  off a notice they may still be reading would be its own small insult.
-  Cleared on unmount, so pressing a button first does not leave a second
-  navigation queued behind the one you chose.
-
-## [1.1.2] - 2026-07-30
-
-### Fixed
-
-- **`noIndex` never used on the order confirmation page (`OrderConfirm.tsx`).**
-  Reserved/purchased/cancelled order confirmations are reachable by anyone
-  with the emailed link, no login required, and each is single-use - there is
-  no canonical indexable version. `<Meta>`'s `noIndex` prop existed but was
-  never passed anywhere in the app; it now is here.
-
-## [1.1.1] - 2026-07-25
-
-### Fixed
-
-- The "Connect Telegram" addon widget now also renders on `reserved` order
-  confirmations, not just `purchased` ones - a reserve-then-pay-later
-  booking has no other page offering the binding link, so it was a dead
-  end for the Telegram addon on that path.
-
-## [1.1.0] - 2026-07-25
-
-### Added
-
-- **Post-purchase Telegram addon binding.** When a purchased order has a
-  Telegram notification addon still awaiting binding, the "purchased"
-  confirmation page now shows a "Connect Telegram" deep link (polls obtapi's
-  `GET /api/orders/telegram/status?hash=...` every 4s until bound). Mirrors
-  magus's account-level `AccountTelegram` binding flow, but order-scoped
-  since a guest checkout has no account to bind against.
-
-## [1.0.1] - 2026-07-19
-
-### Security
-
-- `OrderConfirm.tsx`: fixed an HTML-injection (XSS) vector. The `hash` segment
-  comes straight from the URL (`/orders/:type/:hash`) and was interpolated into
-  markup rendered via `dangerouslySetInnerHTML`. Added an `escapeHtml` helper
-  that encodes `& < > " '` and applied it to the hash before interpolation
-  (`<strong>${ escapeHtml(String(hash ?? '')) }</strong>`), so a crafted hash
-  (e.g. containing `<img onerror=...>`) can no longer inject markup.
-
-### Fixed
-
-- `OrderConfirm.tsx`: the "Manage order" action now routes based on auth state.
-  A logged-in user is sent to `/account/orders` (where the order is listed)
-  instead of the public `/viewtrip/:hash` lookup form that email-gates access to
-  their own order; guests still use the public `/viewtrip/:hash` lookup.
-
-Authored by Ferjolt Ozuni. Consolidated from the magus and alvavel whitelabel patch sets into canonical @autobusal source (eliminates per-repo patch-package divergence).