One upcoming laarc feature is to be able to search private bookmarks. (By the way, you can create private bookmarks on laarc by submitting to /l/private. I’ve been using it instead of Pinboard lately.)
To search private data, I need to come up with some way of sharing authentication between the main site and search.laarc.io. But it would be annoying to have to log in separately, both for users and for us: the search feature is currently running on a separate box (in fact a free Heroku instance) and hence can’t access any internal files (like password hashes). This is security 101.
Originally I was planning to scope laarc’s user cookie to .laarc.io rather than www.laarc.io. That way when users visit search.laarc.io you’d automatically be searching your private data, because the user cookie alone is enough to create a private search key in algolia.
For one, it increases the attack surface. A flaw in search.laarc.io could expose the user cookie.
The simple solution is to hash the user cookie and then set that as a new cookie (e.g. “auth”) on .laarc.io. The site already uses a similar hashing scheme for authenticating your upvotes (otherwise someone could send you a link like “click here: <url>” which would cause you to upvote their post just by visiting that url).
But openID was always in the back of my mind as “the right solution.” There are even old comments from 2008 in the Arc codebase related to openID, so pg was thinking along the same lines. That would give people a way to build services on top of laarc in general, rather than me crafting a solution for search specifically.
But OpenID is on the way out. I was just going to go with hashing the user cookie. Is there a better way?
I notice that apply.ycombinator.com lets you log in using your hacker news username, so they solved this same problem. I wonder if they used OpenID.