Authentication
Logging in unlocks the project-editing methods (download reads work without it
for shared projects, but save, share and metadata writes need an
authenticated session). Authentication is entirely cookie-driven, and
s-api4js keeps those cookies in a tough-cookie
jar so you don't have to manage them.
Logging in
After a successful login the session is populated:
What login does
login() runs the same handshake a browser does:
GET /csrf_token/— primes thescratchcsrftokencookie.POST /login/— sends the credentials with the CSRF header; Scratch replies with thescratchsessionsidcookie, captured into the jar.GET /session/— reads back the account details and theX-Tokenused for authenticated requests.
A rejected login throws a ScratchAPIError
(status 403); the message includes Scratch's reason where available.
You can re-read the session state at any time, and clear it when done:
The cookie jar
The jar is shared across every request the session makes. Reach it via
session.jar to inspect or persist cookies — for example to resume a session
later without logging in again:
Constructor options
new ScratchSession(options) and ScratchSession.login(user, pass, options)
both accept:
A custom fetch is handy for proxies, retries, or running on a runtime whose
fetch you want to control:
Authenticated requests carry the X-Token (and X-CSRFToken) headers and the
session cookie, spread across four hosts: scratch.mit.edu (login/session),
api.scratch.mit.edu (reads + metadata writes), projects.scratch.mit.edu
(project JSON) and assets.scratch.mit.edu (costumes/sounds). Because all four
are subdomains of scratch.mit.edu, the jar sends the session cookie to each.