|
|
@@ -218,17 +218,54 @@ voor browse-endpoints. Drupal-niveau, geen Claude-taak. **Bijvangst
|
|
|
**hardcoded Basic-Auth-header mee** (`Authorization: Basic
|
|
|
Ym9iOnNlcmhpaQ==`, decodeert naar `bob:serhii`) — dit staat letterlijk
|
|
|
in de gecompileerde APK en is dus met een gratis decompiler
|
|
|
-(bv. `jadx`) door iedereen uit te lezen. Neem dit mee in de
|
|
|
-P0-5-afweging: als het achterliggende Drupal-account meer kan dan
|
|
|
-alleen lezen (bv. schrijven t.b.v. de favorieten-sync uit P1-7), is dit
|
|
|
-een device-brede, niet-intrekbare credential zolang de app in de wild
|
|
|
-is. Oplossing hangt af van wat P0-5 uitwijst (anonieme leestoegang zou
|
|
|
-dit hele Basic-Auth-blok overbodig maken).
|
|
|
+(bv. `jadx`) door iedereen uit te lezen. **Verduidelijkt door Bob
|
|
|
+(2026-08-12): dit account is alleen nodig voor de
|
|
|
+`devbob.uitgaanskrant.com`-omgeving (dev/staging zit achter een
|
|
|
+username/wachtwoord-poort) — tegen de productie-URL
|
|
|
+(`uitgaanskrant.com`, wat de app daadwerkelijk aanroept) doet de header
|
|
|
+niets schadelijks, geeft geen foutmelding, is dus effectief dood
|
|
|
+gewicht daar.** Praktisch gevolg: minder urgent dan eerder
|
|
|
+ingeschat (geen live-productie-credential-lek), maar nog steeds het
|
|
|
+opruimen waard — een onnodige hardcoded header die alsnog een
|
|
|
+dev-omgevingswachtwoord blootlegt zodra iemand de APK decompileert, en
|
|
|
+die zonder functie is zodra de app alleen tegen productie draait.
|
|
|
|
|
|
-**P0-7 · Eigenaar: Onbepaald (onderzoek nodig vóór builder-fix).**
|
|
|
-Horecagelegenheid-infodata (titel/inhoud/logo) komt **structureel niet
|
|
|
-aan** — bevestigd 2026-08-12 op een verse build, live op 2 verschillende
|
|
|
-gelegenheden (niet 1 incident):
|
|
|
+**P0-7 · Eigenaar: Bob (Drupal-niveau — root cause bevestigd server-side,
|
|
|
+geen Claude/app-taak).** Horecagelegenheid-infodata (titel/inhoud/logo)
|
|
|
+komt **structureel niet aan** — bevestigd 2026-08-12 op een verse
|
|
|
+build, live op 2 verschillende gelegenheden (niet 1 incident).
|
|
|
+**Root cause definitief bevestigd (2026-08-12, Claude, directe curl
|
|
|
+op de Drupal-endpoint, buiten de app om):** het endpoint achter
|
|
|
+`EstablishmentInfoCall`
|
|
|
+(`https://uitgaanskrant.com/en/flutterdrup/views/flutterflowmobiel_establishment_info.json?display_id=services_1&nid=<nid>`,
|
|
|
+`lib/backend/api_requests/api_calls.dart:907-908`) geeft voor **elke**
|
|
|
+geteste `nid` een **HTTP 500** terug (Drupal's generieke "The website
|
|
|
+encountered an unexpected error. Please try again later."-pagina, geen
|
|
|
+JSON) — getest met 3 verschillende echte nid's uit de live
|
|
|
+establishments-lijst (`91142` = De Beun, `91140` = Hotel Den Helder,
|
|
|
+`58844` = Brasserie Veldt), allemaal 500. Ook geprobeerd met `/nl/`
|
|
|
+i.p.v. `/en/` als taalprefix (de andere API-calls in dit project
|
|
|
+gebruiken allemaal `/nl/` — dit ene endpoint wijkt af) en zonder
|
|
|
+taalprefix: **blijft 500**, dus de taalprefix-inconsistentie is niet de
|
|
|
+oorzaak (wel een aparte kleine inconsistentie om ooit recht te trekken).
|
|
|
+De app-kant (`getJsonField`/`valueOrDefault`/JSONPath) doet exact wat
|
|
|
+hij moet doen met een kapotte respons: stil terugvallen op de
|
|
|
+design-time placeholder — **dit is dus geen Flutter/FlutterFlow-bug,
|
|
|
+het is een kapotte Drupal Views-`display` (`services_1` op de
|
|
|
+`flutterflowmobiel_establishment_info`-view)**. Fix zit aan
|
|
|
+Drupal-kant: de Drupal-watchdog/PHP-errorlog raadplegen voor de exacte
|
|
|
+exceptie (productie toont geen foutdetails naar buiten, dus die is
|
|
|
+alleen server-side te vinden) — vermoedelijk een kapotte
|
|
|
+Views-relatie/veld sinds een eerdere wijziging aan het content-model
|
|
|
+(bv. de recente favorieten/media-uitbreidingen). **Bijvangst tijdens
|
|
|
+het testen:** de establishments-lijst-endpoint (`EstablishmentsCall`)
|
|
|
+werkt zelf prima — dat verklaart ook waarom de "events op deze
|
|
|
+locatie"-carousel op dezelfde pagina wél goede data toont: die gebruikt
|
|
|
+een ander, werkend endpoint.
|
|
|
+
|
|
|
+**Live bevindingen in de app zelf (2026-08-12, symptoombeeld — de
|
|
|
+root cause hierboven is inmiddels het echte aanknopingspunt, dit is
|
|
|
+puur de zichtbare impact):**
|
|
|
- **`HorecagelegenheidCurrent`** (horecagelegenheidpagina, bereikt via
|
|
|
`HorecagelegenhedenOverzicht` → kaart tikken): zowel bij "De Beun"
|
|
|
(Heiloo) als "Hotel Den Helder" bleef de infosectie **permanent**
|
|
|
@@ -264,37 +301,18 @@ gelegenheden (niet 1 incident):
|
|
|
volgende poging heeft een evenement met een **wél ingevulde**
|
|
|
`horecaid` nodig, bv. via de widget-tree of een gerichte API-check
|
|
|
welk evenement een horecaid heeft).
|
|
|
-- **Nog niet hard bevestigd, wel plausibele kandidaat-oorzaken (verder
|
|
|
- onderzoek nodig vóór een builder-fix zin heeft):**
|
|
|
- 1. `EstablishmentInfoCall`'s JSONPath-expressies
|
|
|
- (`r'''$[:].nid'''`/`titel`/`content`/etc.,
|
|
|
- `lib/backend/api_requests/api_calls.dart:925` e.v.) versus de
|
|
|
- werkelijke vorm van de Drupal-JSON-respons — als de respons niet
|
|
|
- een array-met-1-object is zoals verwacht, levert `getJsonField`
|
|
|
- stilzwijgend `null` (geen crash, geen foutmelding) en valt alles
|
|
|
- terug op de design-time placeholder.
|
|
|
- 2. De `nid` die de overzicht-kaart doorgeeft bij navigatie
|
|
|
- (`horecagelegenheden_overzicht_page_data_type_widget.dart:397-403`
|
|
|
- en de 5 vergelijkbare blokken verderop in hetzelfde bestand, regel
|
|
|
- 606/790/974/1158/1342) gebruikt
|
|
|
- `getJsonField(item, r'''$.nid''').toString()` — als het onderliggende
|
|
|
- veld `null` is, geeft Dart's `null.toString()` de **letterlijke
|
|
|
- string `"null"`** terug (geen exceptie), die dan als een
|
|
|
- "geldige" nid wordt doorgegeven aan `EstablishmentInfoCall`. Let
|
|
|
- op: dit verklaart *niet zonder meer* waarom de events-carousel op
|
|
|
- dezelfde pagina wél de juiste gelegenheid vond (die lijkt een
|
|
|
- eigen/werkende nid-scoping te hebben) — dus mogelijk is dit niet
|
|
|
- de (enige) oorzaak; vandaar "kandidaat", niet "bevestigd".
|
|
|
- - **Aanbevolen volgende stap:** één gelegenheid opzoeken waarvan de
|
|
|
- echte `nid` bekend is (bv. via Widget Inspector/`View Code` of een
|
|
|
- directe Drupal-check) en `EstablishmentInfoCall`'s endpoint
|
|
|
- (`https://uitgaanskrant.com/en/flutterdrup/views/flutterflowmobiel_establishment_info.json?display_id=services_1&nid=<echte-nid>`)
|
|
|
- los curlen (met de Basic-Auth-header uit P0-5's bijvangst) om te
|
|
|
- zien of de JSON-vorm klopt met wat `EstablishmentInfoCall`
|
|
|
- verwacht — dat scheidt kandidaat 1 en 2 definitief. **P0** omdat
|
|
|
- dit een kernpagina raakt (horecagelegenheidpagina) die voor
|
|
|
- *iedere* bezochte gelegenheid vrijwel leeg oogt voor een
|
|
|
- eindgebruiker.
|
|
|
+- **Twee eerder overwogen app-side kandidaat-oorzaken zijn met de
|
|
|
+ curl-test hierboven uitgesloten** (voor de volledigheid, om te
|
|
|
+ voorkomen dat een volgende sessie ze opnieuw onderzoekt): het is
|
|
|
+ niet een JSONPath/response-vorm-mismatch in `EstablishmentInfoCall`,
|
|
|
+ en niet de `getJsonField(item, r'''$.nid''').toString()`-constructie in
|
|
|
+ de overzicht-kaart-navigatie (`horecagelegenheden_overzicht_page_data_type_widget.dart:397-403`
|
|
|
+ e.v.) die een `null`-veld als de string `"null"` zou doorgeven — de
|
|
|
+ geteste nid's (`91142`/`91140`/`58844`) waren stuk voor stuk gewoon
|
|
|
+ geldig (bevestigd via de werkende establishments-lijst), en de
|
|
|
+ endpoint faalde alsnog voor alle drie. **P0** omdat dit een
|
|
|
+ kernpagina raakt (horecagelegenheidpagina) die voor *iedere* bezochte
|
|
|
+ gelegenheid vrijwel leeg oogt voor een eindgebruiker.
|
|
|
|
|
|
## P1 — snel na livegang
|
|
|
|
