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

Nasadit v2.5 na JNJ stroj místo v2.4 (jako janssenpc_file_send.py).
Spustit přenos, otevřít file_send.log u sekce >> UPLOAD start.
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

3.8 KiB Raw Blame History