-
Notifications
You must be signed in to change notification settings - Fork 2
Dead Drop
Dead Drop packages captured requests into a portable file another operator can open in their own Joro instance. No team server, no network path between you, no shared infrastructure — just a file.
It is the offline counterpart to the shared flagged-requests feed in Team-Server. Use flagged requests when you are all on a team server; use a dead drop when you are not, or when the recipient is outside the engagement's collaboration setup.
Click the spider in the app header. It carries a badge showing how many requests you have staged.
Dead Drop is deliberately not a tab in the top navigation.
Right-click and choose Stage for Dead Drop from:
- History — a row in the request list, or the detail pane.
- Detect — a row in the findings table. The item's note is pre-filled with the rule name and the matched evidence.
- Manipulate — the HTTP editor, which snapshots the current request and response of the active tab.
Staging from History dedupes on the source request, so staging the same row twice is a no-op. Staging from Manipulate does not — each snapshot is a separate item, so you can capture several steps of the same request as you iterate on it.
The Dead Drop page has two columns.
Staged is what you are assembling. Above the list, set:
- Author / From — pre-filled from your team nickname if you have one.
- Title — optional.
- Note — optional, describes the drop as a whole.
Each staged item has its own note field and an X to remove it. Drag the handle to reorder — the order is preserved on export, so you can lay out a multi-step chain in the sequence the recipient should read it. Click any item to open it in a read-only request and response viewer.
Export .jord writes the file. Clear empties the staged list.
Imported is the other side. Import .jord opens a drop someone sent you and shows its title, author, export time, and note, followed by the items in the order they were staged. Click any item to open the same viewer. Close discards the imported drop from view; the file is untouched.
Each item carries its own raw request and response bytes rather than a reference to a request ID. Request history is local to each Joro instance, so an ID means nothing on another machine — the bytes travel with the drop, which is what makes it openable anywhere.
Files are compressed. Import accepts both compressed and plain JSON.
That completeness is the point, and it is also the caveat: whatever was in the request is in the file, including Authorization headers, session cookies, and credentials in the body. Compression is not encryption. Check what you have staged before you export, and hand the file over through a channel you would be willing to send the same credentials through.
The list of staged items lives in the page only. Reloading the browser loses it. The exported .jord file is the durable artifact — stage, export, and then clear.
- Team-Server — shared flagged requests, the live equivalent when you are on a team server
- History — where most staging starts
- Detect — stage the request behind a finding, with the evidence pre-filled as the note