Page 1 of 1

LiveCodeServer-database-API

Posted: Mon Jan 12, 2026 6:35 pm
by stam
Hi all, I thought this may be of help/interest for some.

LiveCodeServer-database-API is a database-agnostic API with industrial security, and can be adapted to any project. Using Server, you can do all database operations over HTTP using RPC (remote procedure call) rather than REST, which seems a more natural fit for LiveCode.
The repo is available at https://github.com/stam66/LiveCodeServer-database-API.

This project was derived from an effort to provide HTTP access to a MySQL database I'm using in a webapp project (not LiveCode), where I wanted to write companion apps (probably in LiveCode) to use the same database, and actually wanting to play with Server I guess.

Server is the middleware on the remote server that bridges between client app and database. I generated a working version of this, but then I got Claude Code to review my repo, and it surprised me with a large number of critical vulnerabilities I hadn't even considered (like preventing hackers from using time to response as a way of predicting chars in the password, MIME-sniffing, IP-based rate limiting, etc).
With Claude's help, I've created a rock-solid API for my project and then got it to help create a generalisable API, that can be used either with MySQL, PostreSQL, SQLite or ODBC - there are templates for all and a generic endpoint template. It also includes a template for data audit that will capture any data changes in detail automatically.

In short, you would create an API directory on your server that has a database configured and LiveCode Server installed, copy the basic files and modify some templates for your specific setup and it should just work (he says...).

Security features include:
Security Headers
  • X-Content-Type-Options: Prevents MIME-sniffing
  • X-Frame-Options: Prevents clickjacking
  • X-XSS-Protection: Enables browser XSS protection
  • CORS: Cross-origin resource sharing configured
  • CSP: Content Security Policy
SQL Injection Prevention
  • validateNumericID() - Validates and sanitizes numeric IDs
  • sqlEscape() - Escapes SQL special characters
Authentication
  • JWT-based authentication with HMAC-SHA256 (JSON Web Token)
  • Constant-time password comparison (timing attack protection)
  • Token expiration (default: 30 minutes)
  • Salted password hashing with PBKDF2-like approach
Rate Limiting
  • IP-based rate limiting (configured per endpoint)
  • Automatic cleanup of expired limits
  • Proxy/load balancer support (X-Forwarded-For)
Documentation and templates/examples are included in the repo, but I haven't really tested these thoroughly (my specific project works terrifically, but this was not based on the generalisable version, as that was derived from my specific project).

Feedback/comments welcome here and (preferably) on GitHub - just raise an issue at https://github.com/stam66/LiveCodeServer-database-API.

Stam

Re: LiveCodeServer-database-API

Posted: Wed Jan 14, 2026 4:12 pm
by coleman
Thanks for sharing this, looks like a really useful project.

Using LiveCode Server with an RPC-style API feels like a good fit for LiveCode apps, especially when you’re doing frequent database operations and want to keep things simple on the client side. I also like that security was clearly thought about from the start — things like rate limiting, JWT auth, and basic SQL-injection protection are often overlooked in small projects.

The fact that it can be adapted for different databases (MySQL, PostgreSQL, SQLite, ODBC) makes it practical for real-world use, not just demos. Having templates to start from is a big plus too.

It might be helpful for newcomers if there was a small client-side example showing how to authenticate and run a basic query from a LiveCode stack — that would probably make adoption even easier.

Also, slightly off topic, but when people do an oculus proxies review or talk about tooling and infrastructure choices, it’s nice to see projects like this that focus on security and clean design from the beginning.

Overall, nice work — thanks for putting it out there and documenting it