SSR Websites: Loaders, Forms with CSRF and Customer Sign-In

Intro

0:00 A website comes alive with data : products, stock, reviews, the orders of a customer. In this video, the Calm Home shop reads four databases, takes a form, and lets customers sign in, each one seeing only their own orders.

Data on a website, the usual way

0:15 Data on a website usually means an API for every page, tokens kept in the browser, every form checked twice, in the browser and on the server, CSRF tokens and sessions written by hand, and a filter on every query, so one customer never sees the orders of another. Forget it once, and data leaks. With API Maker, a page reads its data on the server, in a loader, only from the tables its website lists, forms come with CSRF and server checks, and the rows of each visitor are a rule, written once.

0:49 In this video : loaders and ctx dot db, only the tables you list, one page reading three engines, rules for columns, a form checked on the server, customers who sign in, and rows that belong to each customer.

Loaders and ctx.db

1:04 A page reads its data in a loader : a function that runs on the server before the page renders. A visitor asks for a page, its loader calls ctx dot db, the server checks the rules of site dot config, reads the database in the same process, and the page gets the rows as its data. No API to write in between, and no token in the browser.

Only the tables you list

1:27 A website reads only the tables it lists. Make a new file from a template : the model page with data, at pages slash reviews. The preview refuses it at once : the model reads its sample table, mongodb, shop, items, this website does not list it, and the page says what to add. This page should list the reviews of Calm Home : the database catalog, the table reviews, and each one shows its title.

1:54 Save : refused again, the reviews are not listed either. Open site dot config, add the table to data dot read, save, and the reviews list. One line, in one file, opened one table.

One page, three engines

2:08 One page may read several engines. The page of a product reads the product from MongoDB, its stock in each warehouse from SQL Server, and its reviews from MongoDB, at the same time ; the names of the reviewers come from PostgreSQL. Open the Aurora desk lamp : its stock in four warehouses, and its reviews, each one signed with a first name.

Rules for columns

2:31 Only a first name? The loader asks for the last name and the email too. But the rule of the customers table gives two columns : the id and the first name. So the server reads those two, whatever the page asks for. A careless page, or code an AI assistant wrote, can not leak an email : the rule sits in one file, easy to review. Settings sums it up : the tables the website reads, the tables it writes : none, how its customers sign in, ctx dot sys : off, and a strict content security policy.

3:05 It all comes from site dot config : every table, with its columns and its rows.

Four ways to reach data

3:11 ctx dot db is one of four ways to reach data. ctx dot api calls the APIs of the account as the visitor would, with their access rules and their hooks. ctx dot sys may do everything the account may, so it stays off until site dot config turns it on. ctx dot fetch reaches only the hosts the settings list. And ctx dot cache keeps a value between requests, for a minute or for an hour.

A form

3:40 Now a form. From the models, pick Form : an action that takes the post, checks every field on the server, and shows a message after. It is made at pages slash contact. The model is plain HTML, so it fits any UI library : here it gets the Bootstrap classes of the shop, and the preview shows the form. In a browser tab, type a name, an email without its domain, and a message that is too short.

4:09 The browser lets both pass. Send : the server checks the values, and the page comes back with an error under each field, and what was typed is still there. Fix the email, write a real message, send, and the page comes back with a message shown once.

CSRF

4:26 That form carried a hidden CSRF token : the server adds one to every form that posts. A post from another site comes without it, and is refused with a 403 before any code of the page runs : the form expired. Nothing to write, and nothing to forget.

Customers sign in

4:44 Now customers sign in. The orders page needs a signed-in customer, so a visitor lands on the sign in page first. Kabir is a customer in PostgreSQL : an email, a password, and sign in, through the auth provider customers of the account. Back on the orders page : one order, read from MySQL. It opens.

Rows of each customer

5:06 Now put the id of an order of another customer in the address : not found. The page asked for any order, and the server still gave only the orders of Kabir. How? The orders page asks for every order : its find is empty. The rule of the orders table adds the customer of the session to every read, update and removal. A row read by its id is checked against the same rule, so the order of someone else is not found.

5:34 And a visitor the rule can not place reaches nothing. A forgotten filter can no longer show the data of someone else.

The session

5:42 The session is a cookie sealed with AES 256 GCM : the browser can neither read it nor change it. It is HttpOnly, so no script of the page sees it, and SameSite Lax. Who may open a page is decided before its code runs : the account pages send a visitor to sign in first. And a wrong email and a wrong password get the same answer, so the sign in page does not tell which emails exist.

Recap

6:11 To sum up. Loaders read data on the server, with ctx dot db. A website reads only the tables it lists, with rules for their columns and rows. Forms are checked on the server, with CSRF built in. Customers sign in with the auth providers of the account, and each one reaches only their own rows. Next : cache, SEO, images and going live. API Maker. Build faster, spend smarter, deliver better.