Výpis příloh
Části jedné zprávy, s jejich bajty v base64.
Spustí skutečné volání proti vašemu pracovnímu prostoru, s vaším vlastním klíčem.
GET /temp-mail/inboxes/{id}/messages/{messageId}/attachments
Části jedné zprávy, s jejich bajty v base64.
Token schránky
export OE=https://api.openemail.ukexport INBOX="Authorization: Bearer oe_inbox_kQ8v…"Každé volání níže nese token, který vrátil POST /temp-mail/inboxes, v téže hlavičce Authorization: Bearer, jakou používá API klíč. Samotná adresa neopravňuje k ničemu a to oddělení je smyslem celé funkce, ne formalitou: jednorázová adresa se předá straně, kterou si držíte od těla, ve chvíli, kdy je vydána.
Id v cestě musí jmenovat tutéž schránku jako token. Schránku identifikuje už samotný token, takže je to pásek i kšandy, ale znamená to, že volající, který si splete dvě schránky, dostane 404 místo toho, aby potichu četl cizí poštu.
Příklad
Metadata i obsah v jedné odpovědi, ne výpis plus jedno stažení na každou část. Jednorázová schránka drží hrstku malých souborů a dva okružní průchody kvůli přečtení PDF jsou při té velikosti špatný obchod.
curl "$OE/temp-mail/inboxes/tinb_9c2f41ab7d3e4c118a0f5d72/messages/tmail_4b81c07d2fa9418e93c6a13f/attachments" \ -H "$INBOX"{ "object": "list", "data": [ { "object": "attachment", "attachmentId": "tmail_4b81c07d2fa9418e93c6a13f-0", "filename": "invoice.pdf", "contentType": "application/pdf", "size": 12345, "content": "JVBERi0xLjQKJc…" } ]}content je null, když část přesáhla 8MB strop úložiště. Není to prázdný soubor, a právě proto se metadata servírují tak jako tak, aby klient mohl říct „příliš velké na uložení“ místo toho, aby nabízel stažení o 0 bajtech.
Tyto bajty dodal útočník a byly přijaty od anonymního odesílatele. Cokoli je vykresluje, musí to dělat mimo origin vaší aplikace.