Chapter 13. Cookie Scheme

Old cookie format: 

*.$LJ::DOMAIN = ws:<user>:<sessid>:<auth>:<flags>

New cookie format: 

2 + n cookies

The 2 cookies work like this:


  • Master session cookie. We control this one tightly.

  • Bound to: www.$LJ::DOMAIN. No user content is on www.*

  • Format:


    • The version number is a code-wise version number.

    • uid is used now, now instead of user.

    • session/auth/flags all work as before.

    • generation/poetry is free-form text/poetry, so you can write a haiku and go after people for subverting security to steal copyrighted, perhaps poetic, material.


The “I'm logged in!” cookie. This one advertised to all subdomains that the user is logged in. If it is stolen, it does not matter. It is only used to bridge the two cookies. It is useless by itself.

Form: not present (not logged in), or:


The n cookies work like this:

The “n” cookies are 1-per-user account. They are bound to <subdomain>.$LJ::DOMAIN optionally with a path=/username/ restriction when <subdomain> is not a username, and is actually “users” or “communities”.

ljdomsess.<subdomain>” or ljdomsess.bob
“ljdomsess.<subdomain>.<user>” or

The format of this cookie is:



So, cookie is valid if:

The cookie should expire every 24 hours.

Future: cookies are bound to first two octets of IP address.

Procedure 13.1. Cookie re-direction

  1. If cookie is not present, but ljloggedin=1 cookie is present, then redirect user to:


  2. which will make a “ljdomsess_*” cookie, then redirect them to:


  3. which will then redirect them to <source_url>.

Mapping to Paths.  LJ::get_remote() needs to be modified to respect the right cookie based on the current hostname.

For talkscreen.bml or any XMLHTTPRequest that goes to a userdomain, that endpoint has to make sure it only operates on data owned by the current hostname/path.

Cookie Permissions

  1. does malicious style.

  2. goodguy visits, gets ljdomsess stolen.

Attacker should not be able to use goodguy's ljdomsess cookie to manipulate goodguy's data using, say, delcomment.bml with args of ?user=goodguy&jtalkid=<commentid>.

delcomment.bml and other endpoints should verify that the user=<user> argument matches the current hostname/path.

This means: <sub><user> should do XMLHTTPRequests not to <sub>, but to <sub><user>/endpoint.bml (otherwise ambiguous).