|
|
@@ -4970,12 +4970,15 @@ opnieuw opslaan. Nagemeten
|
|
|
allemaal een plaats — ga dus niet in de module zoeken. De view leest `plaats`
|
|
|
via `taxonomy_index`, en die wordt alleen voor **gepubliceerde** nodes gevuld.
|
|
|
|
|
|
-**Uploads via `bestand_upload/upload` zijn sinds 2026-09-15 tijdelijk
|
|
|
-(`status = 0`).** `file_save_data()` zet standaard `FILE_STATUS_PERMANENT`; de
|
|
|
-resource zet hem daarna terug op 0. `file_field_presave()` maakt het bestand
|
|
|
-permanent zodra `node_save()` het aan een veld hangt; `system_cron` verwijdert
|
|
|
-de rest na 6 uur (`DRUPAL_MAXIMUM_TEMP_FILE_AGE`). Een gebruiker die 6+ uur
|
|
|
-tussen uploaden en indienen laat, verliest dus zijn foto — bewust geaccepteerd.
|
|
|
+**⚠️ Uploads via `bestand_upload/upload` zijn PERMANENT — de oudere notitie
|
|
|
+"tijdelijk (`status = 0`), cron ruimt na 6 uur op" KLOPT NIET MEER.** Gemeten
|
|
|
+2026-09-22: `_custom_bestand_upload()` zet `$file->status = 0` en een paar
|
|
|
+regels lager, in dezelfde functie, weer `FILE_STATUS_PERMANENT`
|
|
|
+(`custom.evenementen_aanmaken.inc` regels 429-443) — die eerste zet is dode
|
|
|
+code. Twee gevolgen: (1) een app-upload verschijnt **meteen** in het fotoboek
|
|
|
+van de gebruiker (endpoint `mijn_fotos`), wat de bedoeling is; (2) een
|
|
|
+gebruiker die uploadt en dan afhaakt laat een weesbestand achter dat
|
|
|
+`system_cron` **nooit** opruimt, want die kijkt alleen naar `status = 0`.
|
|
|
Let bij grote foto's op: de app stuurt base64 in een JSON-body (5 MB foto ≈
|
|
|
7 MB POST), dus `post_max_size` moet daar boven zitten, en de mediakiezer in
|
|
|
FlutterFlow kan met *Max Width/Height* vooraf verkleinen.
|
|
|
@@ -5584,6 +5587,32 @@ de inlognaam van de auteur, dus user enumeration op al je redacteuren.
|
|
|
verwarrende rondes voordat dit duidelijk werd; voortaan gewoon altijd
|
|
|
meegeven. Credentials staan niet hier (git-bestand) maar in de lokale
|
|
|
Claude-projectmemory.
|
|
|
+- **⚠️ Geef een sessie-gebonden curl ALTIJD als ÉÉN blok met variabelen —
|
|
|
+ nooit als losse commando's met in te vullen placeholders.** Staande
|
|
|
+ voorkeur Bob, 2026-09-22: hij plakt het eerste blok als script en
|
|
|
+ hergebruikt het per gebruiker, dus een vervolgregel met `SESSNAAM=SESSID`
|
|
|
+ erin kost handwerk en levert fouten op. Werkend sjabloon (wachtwoorden
|
|
|
+ invullen uit de lokale projectmemory, niet in dit git-bestand):
|
|
|
+ ```
|
|
|
+ WEBHOST="devbob.uitgaanskrant.com"
|
|
|
+ AUTH_USER="bob"; AUTH_PASS="..." # Basic Auth, alleen devbob
|
|
|
+ GEBRUIKER="bobhoreca"; WACHTWOORD="..." # Drupal-account
|
|
|
+ R=$(curl -s -u "${AUTH_USER}:${AUTH_PASS}" -X POST \
|
|
|
+ "https://${WEBHOST}/en/flutterdrup/user/login.json" \
|
|
|
+ -H "Content-Type: application/json" -H "Accept: application/json" \
|
|
|
+ -d "{\"username\":\"${GEBRUIKER}\",\"password\":\"${WACHTWOORD}\"}")
|
|
|
+ COOKIE="$(echo "$R" | jq -r '.session_name')=$(echo "$R" | jq -r '.sessid')"
|
|
|
+ TOKEN=$(echo "$R" | jq -r '.token')
|
|
|
+ # elke vervolg-call gebruikt exact dezelfde variabelen:
|
|
|
+ curl -s -u "${AUTH_USER}:${AUTH_PASS}" -H "Cookie: $COOKIE" \
|
|
|
+ "https://${WEBHOST}/nl/flutterdrup/mijn_fotos.json?limit=3" | jq
|
|
|
+ ```
|
|
|
+ **Log niet een tweede keer in zodra `$COOKIE` gezet is.** Een POST naar
|
|
|
+ `user/login.json` mét cookie geeft eerst `["CSRF validation failed"]` (een
|
|
|
+ POST op een bestaande sessie wil `-H "X-CSRF-Token: $TOKEN"`) en daarna
|
|
|
+ `["Already logged in as <naam>"]`. Beide zijn ruis, geen fout in je
|
|
|
+ endpoint: voor een GET-resource heb je alleen `$COOKIE` nodig, het token
|
|
|
+ is uitsluitend voor schrijf-requests.
|
|
|
- **Drupal page cache bootstrapt vóór de sessie** — een ooit anoniem
|
|
|
gecachete response (bv. een 403) kan session-bootstrap, hooks én
|
|
|
custom-module-logging volledig overslaan. Bij twijfel: Drupal-cache
|
