# 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`