Trang này chưa có bằng ngôn ngữ của bạn. Bạn đang đọc bản tiếng Anh.
Cookies
Cookies in and out of a profile
- Ten
- Fields the app reads in your file
- 3
- Ways an expiry may be spelled
- One
- Profiles per file
- Arrived and refused
- What you are told after import
What the file holds
You get one file of plain JSON: a list of records, one per cookie.
Each record carries the eight things below that decide where the cookie goes back and how long it lives there, and whatever else the engine gave with them. The import reads two more: a whole address, used in place of one built from the domain, and the session flag.
Name and value
The session token itself, and the name the site reads it by.
Domain and path
Which site gets the cookie back and which part of that site.
Secure and HttpOnly
Whether it travels only over an encrypted connection and whether page scripts may see it.
SameSite and expiry
Whether it goes along on a request begun at another site, and when it dies.
Which files will do
Import cookies in the profile menu takes JSON and Netscape, including exports from other antidetect browsers, Firefox records and the .txt that cookie extensions and curl write.
An expiry in milliseconds becomes seconds, a session mark does not wipe an expiry, and a cookie past its expiry is not loaded.
You take the whole jar
With Export cookies in the profile menu, the shipped build takes everything the profile holds rather than the cookies of the page in front of you. The number in the message is the number of records written to the file.
Where that jar sits is decided by the engine the app is set to, and so is whether the profile has to be open.
The file is named after the profile by default, with anything outside letters, digits, dot, dash and underscore replaced, and you choose where it goes.
| The engine in the settings | Where the jar is | To read it or write it |
|---|---|---|
| ARMANOS Browser | Inside the running browser | The profile has to be running in that build |
| Built in engine | In the profile folder on disk | Open or closed, both work |
You are told, not handed an empty file
Export from the window, and clearing
Inside an open profile, Cmd+Shift+K on a Mac or Ctrl+Shift+K elsewhere exports its cookies straight to a file.
Clear cookies… in the profile menu deletes every cookie of a profile on this computer, and Clear cookies in the bar does it for a selection. Site data stays.
The file is a set of live sign-ins
Whoever opens that file can sign in as those accounts, so the app says it before the save dialog rather than after.
The file is held by permissions and not by a password. On macOS and Linux it goes to your account alone, and those permissions travel with the copy.
On Windows permissions are not what protects a file. There it takes the rights of the folder you saved it into.
Delete it once the move is done
You see what did not arrive
A browser turns a cookie away for plenty of ordinary reasons, and one bare number of what arrived reads as a session moved in full.
So the message carries both numbers, and somebody the site still asks to sign in knows where to look.
Three of the reasons below are the app's own refusals and the last one comes from the browser, though the message counts them all as one number.
| What the file had | What happens to it | Where it counts |
|---|---|---|
| No domain and no address | There is nowhere to send the cookie back to | Refused |
| No name | A record without a name is not a cookie | Refused |
| An expiry the browser cannot read | The date is dropped and the cookie still goes in | Arrived and refused both |
| A rule of the browser itself | Secure on a plain address, or a domain that does not match | Refused |
What this does not do
- Archives and files in neither JSON nor Netscape are not read.
- You are not told which rule refused which cookie. The count is on screen and the detail behind it is not.
- Into an existing profile, cookies go one profile at a time, with no load across a selection.
- It does not sign you in by itself. A site weighs the device and the address too and can ask for the session again.
How to check
Every claim above sits in one file, and most have a stand you can run.
- Export reads the whole jar, not the page in front of you
- apps/desktop/src/lib/forkPage.js · apps/desktop/test/cookie-transfer.js
- SameSite and the expiry reach the browser on import
- apps/desktop/test/cookie-transfer.js
- Import counts what was refused beside what arrived
- apps/desktop/src/main/main.js
- The cookie file is written for your account alone
- apps/desktop/src/lib/secureFile.js · apps/desktop/test/secrets-on-disk.js
- A flow reads a cookie only for the site its step stands on
- apps/desktop/src/main/main.js · apps/desktop/test/rules-and-runs.js
- Cookies over the API, open or closed profile
- apps/desktop/test/api-куки.js · apps/desktop/test/api-куки-закрытого-живьём.js
Questions
- Can I bring a file from another tool?
- If it is an ordinary list of cookie records, yes. We read the fields a cookie has, not one product's own database.
- Can a script read and load cookies?
- Yes, through the local API, open or closed profile; the cookies stay on this computer.
- Do the two numbers in the message add up?
- Not always. A cookie whose date could not be read goes in without it and is counted on both sides, because a lost expiry is worth telling you about.
- Will the account still be signed in after the move?
- Often, though not always. The site weighs the machine and the address too, so a session arriving without its own fingerprint looks like a new device.
Take one session with you
In ARMANOS, open a profile and write its jar to a file you carry yourself.