Applications and keys
Creating an application
Sign in, open Applications, and add one. You need a name; the URL is optional and is only used to show the site's icon beside the name.
The application page shows its keys as soon as it exists, and every client needs them before it will send anything.
The two keys
Every client authenticates with two values, both on the application's settings page.
| Key | What it is |
|---|---|
| Ingest key | Lets a client post events to this application, and reaches nothing else in your account. Rotatable, and safe to ship in a browser bundle. |
| Project key | Says which application a report is filed against. |
In the Laravel client they are LB_KEY and LB_PROJECT_KEY. In the JavaScript packages they are loginKey and projectKey: those names are the packages' own and are older than the ingest key, but the value to give them is the one above.
The DSN
A DSN is both keys and the endpoint in one string, which is easier to paste into a deployment tool than three separate variables.
LB_DSN=https://login_key:project_key@www.larabug.com/api/log
Where a client supports both, the DSN wins: if LB_DSN is set, the separate keys are ignored.
Where the keys can go
Both of them can go in a browser. That is what the ingest key is for: it opens exactly one thing, posting events to one application, and it cannot read an issue or delete one. Every JavaScript bundle that reports browser errors ships it, which is unavoidable and by design.
Narrow it further with the allowed origins on the same settings page, which is the list of sites a report is accepted from.
What does not belong in a browser is the account token the HTTP API reads with. That one is your account.
Rotating a key
Rotate the ingest key from the application's settings. The old one stops being accepted immediately, so deploy the new one first if you would rather not lose the events in between.