lapis dove
I’m building an app that integrates with Lichess via the Board API (board:play scope), and I’m running into a limitation with POST /api/board/seek:
Rapid/Classical/Correspondence seeks work
Blitz/Bullet seeks are rejected (e.g., time=5, increment=0 -> Invalid time control)
I understand from the docs and issue discussions that this is currently intentional.
Still, I’d like to request support for Blitz/Bullet seeks for normal Board API consumers.
keen plinth
what are you building?
lapis dove
i have a lichess powered site, www.azchess.az, we have talked in lichess i think, i have implemented all core functiones and followed your strict rules, but i want users be able to play blitz and bullet as well. i have no plan to compete with lichess, just making more friendly interface with additional instruments, for localised use. we are pro lichess popularisation and localisation.
keen plinth
you're most welcome to compete with lichess
Nice website, may I see the source code please?
lapis dove
sure, you can, what code specificly you need? which section? board api? i can provide any section
keen plinth
the whole frontend, I noticed it's GPL licensed since it includes chessground
lapis dove
yes we use chessground, let me prepare for you.
you need it zip to be sent here or any prefered way?
keen plinth
The preferred way would be a public github repo, but you can also provide a zip, here or sent to t@lichess.org. I'll then make it into a public github repo myself
thanks
lapis dove
i will make public repo so you dont spent time on it.
lapis dove
so can we have permission for blitz and bullet?
keen plinth
Published as https://github.com/ornicar/azchess.az-frontend
keen plinth
there is no such permission system, I would have to develop it
keen plinth
I see that you proxy all the client requests to lichess through your server, why? That won't scale well
lapis dove
we will have coach/student/admin hub in development, you’re right — proxying everything is not our intended end-state.
We started with a server-side BFF model for security (OAuth token protection), authorization, and integration isolation during MVP.
We are now moving to a selective model: only user-authenticated and state-changing calls stay server-side, while cacheable/public read traffic is moved off the proxy path with direct access and/or edge caching.
lapis dove
there is no such permission system, I would have to develop it
sorry for causing you extra job, how i can support you? i have already moved to yearly donation to lichess, i feel i need to support and collaborate with lichess, as we are part of lichess, i realy appreciate your work, lichess is really brilliant.
keen plinth
OAuth token protection
well i noticed the client has the lichess token anyway, and sends it to your server with every request
lapis dove
im fixing it now as 1. Keep proxy only where needed
login/token endpoints
private user data
all write actions (move, challenge, message, etc.)
2. Stop proxying public read-heavy endpoints
public profile, leaderboard, public game data
fetch directly from client or serve via edge/cache layer
3. Add caching for remaining reads
short TTL cache for repeated requests
reduces hits to both AZChess and Lichess
keen plinth
also it would be nice to set a user-agent instead of just node so that lichess knows who's making requests
Keep proxy only where needed
I don't understand how that's needed, and what extra security you'd be gaining from it
proxying moves adds latency, and is not going to scale
lapis dove
also it would be nice to set a user-agent instead of just `node` so that lichess...
I’ll implement this now by setting a proper AZChess User-Agent in the shared Lichess request layer, so every outbound call identifies
i have trouble also with identifing cheaters, i cant wire my report system to yours as its not possible with api..:( so now i cant report directly from azchess, have to identify cheater suspect, go to lichess and report there, any suggest making it better?
lapis dove
user-agent issue done
keen plinth
link to pre-filled form https://lichess.org/report?username=thibault
keen plinth
even if I had a way to lift the board API limits for some clients, I would still need to be sure that the moves are played from such clients. I'm not sure how that would work
lapis dove
We now send a proper AZChess User-Agent on our server-side requests to lichess.org (instead of generic Node), so traffic is identifiable.
keen plinth
and anyone can send the same user-agent
lapis dove
..:( sad to accept but you are right, my bad, You’re right — User-Agent alone is not an authenticity source.
We’re moving board actions to be player-originated (browser -> lichess with the user’s own OAuth token) instead of server-relayed where possible, so moves are attributable to the actual player session.
For any remaining server-side calls, we can keep them minimal and transparent (strict endpoint allowlist, per-user auth checks, rate limits, and stable infrastructure details if needed).
If you have a preferred trust model for exceptions, we’ll align to it.
If board requests come directly from user OAuth tokens issued to our AZChess OAuth client, is that the trust model you need for considering higher limits? i can move board traffic to direct client -> lichess (moves, stream, events) using each user’s OAuth token
keen plinth
I thought about that but one could reuse that token in a cheat bot
azchess would become a token factory for cheat bots
lapis dove
you are right
what i think is to address that, we will not expose Lichess OAuth tokens to client JS/apps and can keep tokens server-side only (HTTP-only session context).
Board actions will go through tightly scoped AZChess server endpoints with strict endpoint allowlist (no generic relay),
authenticated session binding, CSRF + origin checks,
per-user and per-game rate limits,
abuse detection / anomaly throttling.
So a leaked script cannot just reuse raw tokens outside azchess.
At the same time, we’re reducing unnecessary proxying (non-board calls) and keeping a clear azchess User-Agent for transparency.
If you prefer additional trust controls, we can align to your preferred model (e.g. fixed egress IP(s), extra request metadata, or any policy you recommend).
lapis dove
i added shared guard: app/api/lichess/board/_guard.ts
requires authenticated AZChess session
enforces same-origin Origin check
adds per-session/per-endpoint rate limiting
uses cookie-only Lichess token resolution
Added cookie-only token helper in app/api/lichess/_utils.ts
Updated all board endpoints to use guard + explicit board UA:
board/move
board/resign
board/events
board/stream/[gameId]
board/chat
board/seek
board/draw
board/draw/accept
board/draw/decline
board/takeback
lapis dove
azchess would become a token factory for cheat bots
any news?
lapis dove
Dear Tibaut, any progress?
keen plinth
Uh, no, I couldn't see a way and had to move to other things
lapis dove
any suggest how i can allow users play blitz and bullet?..:( it really important for my app..:( please
one more issue, can you add to api joining and managing teams? for tournaments
keen plinth
They can play blitz and bullet in direct challenges, but not in the lobby. Such are the terms of our API, which have always been clearly stated.
We tried to find a way to give your app special rights to bypass these otherwise necessary limitations. I'm not opposed to the idea of it. But so far we have failed to find a satisfying way to achieve it.
Either the token is sent to the client and then it can be reused from somewhere else; or you proxy all the moves through your server, which creates a bottleneck and will make you exceed the by-IP rate limits.
I don't think there will be APIs for managing teams, I think that's best done from our team UI.
lapis dove
just give me your terms and i will implement exactly as you wish but please dont reject blitz and bullet for me. im agree with any implementation you will ask
keen plinth
I'm not "rejecting blitz and bullet for you". The API is the same for everyone and I have not treated you differently
lapis dove
i understand just tell me what to do wo you can give special rights for bullet and blitz
keen plinth
The issue is technical. If there exists a sound technical solution, that ensures player safety, and doesn't add too much complexity to Lichess, I'm open to implementing it.
I thought about using the Origin HTTP header to whitelist board token requests coming from the https://www.azchess.az/ origin. But non-browser clients can set that header themselves and pretend to be from your website, so it's not safe
lapis dove
may be you can grant us minimal pilot trust model for lobby bullet/blitz, with strict limits and rollback.
Could you tell us which of these would be the minimum acceptable primitives from your side to even consider a pilot?
-Short-lived game-scoped credentials (very small TTL, single-purpose)
-Proof-of-possession (signed request binding, not bearer-only)
-Attestation-gated issuance (web constraints / mobile app attestation)
-Dedicated capped lane (hard per-user/per-client caps + kill switch)
-Mandatory telemetry feed (client id, request class, abuse signals)
keen plinth
these are some fancy words, sorry for asking but did an LLM produce them? Sorry if not I don't mean to offend
maybe we just don't speak the same dev language, as I've never heard of any of that
lapis dove
im sorry tibaut, i just not native lang speaker..:(( im putting my gibberish to translator..:((
im just tring find a solution..:(
lapis dove
can you give us permission for 5min games at least?