z230

2026-06-12 15:29:57 +02:00
parent 39e578af2d
commit 35e6310dac
79 changed files with 27428 additions and 0 deletions
@@ -0,0 +1,76 @@
+# janssenpc_file_send v2.5
+
+Odesílací skript na JNJ počítači: přejmenuje soubory ve `##JNJPrenos`, zašifruje
+(Fernet/AES-128) a odešle na `https://msgs.buzalka.cz/upload-file`, pak přesune
+do `Trash`. Detekci nových souborů zajišťuje `janssenpc_file_watch.py`.
+Stahování ze serveru řeší samostatný `janssenpc_file_receive` (ručně) — sem nepatří.
+
+## Spuštění
+Spouští se automaticky přes `janssenpc_file_watch.py` (watchdog). Ručně:
+```
+C:\Users\vbuzalka\OneDrive - JNJ\##JNJPrenos\Python\python.exe "...\janssenpc_file_send.py"
+```
+
+## Co je nového v v2.5 — diagnostika JNJ filtru
+
+Důvod: v logu z 2026-06-12 byl poslední soubor označen jako `UPLOADED` + `PŘESUNUTO`,
+ale **doma fakticky nepřišel**. Podezření na korporátní filtr (Zscaler/SiteMinder),
+který už dříve sabotoval downloady (`403 + ?_sm_nck=1`). v2.4 logoval jen
+`resp.json()['status']`, takže podvrženou/přesměrovanou odpověď nebylo poznat.
+
+### 1. Funkce `upload()` — podrobný log každého POSTu
+Loguje:
+- přesné jméno v multipartu `repr(enc_name)` (odhalí problémové znaky/diakritiku),
+- velikost zašifrovaného payloadu i původního souboru,
+- **HTTP kód** a dobu trvání,
+- **finální URL** po redirectech (`resp.url`),
+- celý **řetěz redirectů** (`resp.history` + `Location`),
+- hlavičky `Content-Type`, `Server`, `Content-Length`,
+- **tělo odpovědi** (oříznuté na 1500 B).
+
+### 2. Detekce stop filtru → `⚠ PODEZŘENÍ NA FILTR`
+Zaloguje varování, pokud:
+- `_sm_nck` ve finální URL (SiteMinder/Zscaler replay),
+- finální URL je na cizím hostu (přesměrováno),
+- `Content-Type` není `application/json`,
+- tělo vypadá jako HTML (block page),
+- hlavička `Server` není `uvicorn` ani `nginx`.
+
+> **Pozn.:** Před uvicornem běží SWAG reverse proxy, takže `Server: nginx` je
+> NORMÁLNÍ a poplach se na něj nehlásí. Spolehlivý důkaz pravé odpovědi serveru je
+> přítomnost `dropbox_path` v JSON těle (to generuje jen `app.py`).
+
+## Ověřeno v provozu (2026-06-12)
+První ostrý běh v2.5 prokázal, že přenosový řetězec klient → server → Dropbox
+funguje korektně: `HTTP 200`, finální URL bez redirectu/`_sm_nck`, pravé JSON tělo
+s `dropbox_path`, soubor fyzicky dorazil do `U:\Dropbox\!!!Days\Downloads Z230\`
+(velikost bajt po bajtu sedí). Dřívější podezření na JNJ filtr se NEPOTVRDILO —
+šlo o zpožděný Dropbox sync na domácí straně.
+
+### 3. Bezpečné mazání — Trash JEN při ověřeném úspěchu
+Soubor se přesune do `Trash` **pouze** když:
+`HTTP 200` **a** `Content-Type: application/json` **a** pole `status` ∈
+`{OK, UPLOADED, SAVED, RECEIVED}`.
+
+Jinak se loguje `PONECHÁNO` a soubor zůstává ve složce — aby falešný „úspěch"
+podvržený filtrem nesmazal nepřenesený soubor. (Pozn.: `OK_STATUSES` případně sladit
+s tím, co skutečně vrací `app.py` na `/upload-file` — ověřit z těla v logu.)
+
+## Jak diagnostikovat
+1. Nasadit v2.5 na JNJ stroj místo v2.4 (jako `janssenpc_file_send.py`).
+2. Spustit přenos, otevřít `file_send.log` u sekce `>> UPLOAD start`.
+3. Porovnat: pokud je tam `⚠ PODEZŘENÍ NA FILTR` nebo `status` mimo množinu →
+   chyba je na cestě (filtr / endpoint), ne v serveru. Pokud je odpověď čistá JSON
+   `uvicorn` 200 a soubor přesto doma chybí → problém je až na serveru
+   (`/upload-file` dešifrování / zápis do Dropboxu) — řešit v `app.py`.
+
+## Vazby
+- Watcher: `janssenpc_file_watch.py` (v1.1).
+- Server: `app.py` ≥ v2.3, endpoint `POST /upload-file` (dešifruje `.enc` → Dropbox
+  `/!!!Days/Downloads Z230/`).
+- Protějšek pro download: `janssenpc_file_receive_v1.2`.
+
+## Historie
+- v2.5 (2026-06-12): podrobný logging uploadu + detekce filtru + Trash jen při ověřeném úspěchu
+- v2.4 (2026-06-05): Fernet šifrování uploadu, endpoint `/upload-file`
+- v2.2 (2026-06-02): odesílání bez šifrování přes `/upload-dropbox`