Skip to main content

FlightBooking

HTTP trigger for FlightBookingOrchestrator (Domain/FlightBookingOrchestrator.cs) -- the customer-facing entry point for the ondgo.gds/ondgo.booking extraction (docs/MICROSERVICES_DECOMPOSITION.md). Accepts exactly two real caller types, both wired from day one (see Infrastructure/Auth/BookingAuthExtensions.cs's doc comment for why there's no OpenIddict inbound scheme, unlike every other extracted host):

  • Real human end-users: the same legacy JwtBearer token they already hold everywhere else in this codebase; WalletId is derived from that token's own "defaultWallet" claim, never trusted from client-supplied body input.
  • Travel-agency B2B partners (external callers, confirmed directly with the user): the ApiKey scheme (Infrastructure/Auth/AgencyApiKeyAuthenticationHandler.cs). WalletId is derived from the "wallet_id" claim the handler sets from the agency tenant's OWN Wallet.WalletId -- an agency books and pays out of its own account, mirroring TicketIssuanceOrchestrator's IAgencyWalletService model exactly -- never from client-supplied body input either, for the same "don't trust the caller to name an arbitrary wallet" reasoning as the customer path.

Routed through ondgo.gateway at /flights (ondgo.gateway/Startup.cs's flights_cluster -- this doc comment previously claimed otherwise; confirmed stale against the actual gateway config during the Search port below and corrected here). Book/Cancel are still not called by anything live -- ondgo.api/Controllers/Tickets/TicketOSController.cs remains the live flight-booking code, completely untouched by this pass.