> For the complete documentation index, see [llms.txt](https://comunity.gitbook.io/learning.comunitynexus/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://comunity.gitbook.io/learning.comunitynexus/26.2/toolkit-guides/web-sites/web-site-prerequisites-and-data-access.md).

# Web site prerequisites and data access

A web site is hosted by the platform but built by you.

This page covers what you need in place before developing a web site locally, and what governs the data a web site can display. Neither is required to create a web site, which is done entirely in the Toolkit.

## Local tooling

| Requirement         | Purpose                                                                                                                                                                                                  |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Git**             | Clones the web site repository and returns your work to it. Without it, the repository cannot be worked on locally.                                                                                      |
| **Node.js and npm** | Installs the helper library package and runs the site locally.                                                                                                                                           |
| **A coding agent**  | Reads the helper library documentation and generates the application. The workflow requires an agent that can write files; running commands is optional, as build steps can be run in your own terminal. |

## DevOps authentication

Web site repositories are hosted in Azure DevOps, which authenticates separately from any other repository host your organisation uses. Credentials for other hosts do not apply.

To clone or push:

1. In DevOps, open **User settings** and select **Personal access tokens**.
2. Create a token scoped to **Code (read & write)**, for the organisation holding the web sites project.
3. Copy the token when it is displayed. It is shown once.
4. When Git prompts, supply any value as the username and the token as the password.

Configure a credential helper to avoid re-entering the token on every operation. On macOS:

```bash
git config --global credential.helper osxkeychain
```

{% hint style="warning" %}
Record the token's expiry date. An expired token presents as a permissions failure rather than an expiry message, which is easily mistaken for a loss of repository access.
{% endhint %}

## What your web site can display

A web site reads project data through the platform's data service. What it can read, and whether a visitor must sign in first, is determined by **table security** on each entity, not by the web site.

### Metadata and records are governed differently

The web site discovers which entities exist by reading the project's **metadata**. Metadata is readable without authentication: entity names, field names, types and keys are available to any caller.

**Records** are governed by table security. A read of an entity's records succeeds only where the requesting user holds **View** on that entity.

{% hint style="warning" %}
A project's entity and field names are public regardless of table security. Table security governs access to records, not to the model that describes them.
{% endhint %}

### Setting table security

Open the entity, select **Edit table security**, and grant permissions per role.

Permissions are **Delete**, **Insert**, **Replace**, **Update** and **View**. Roles are **Administrator**, **Staff**, **User**, **Anonymous users** and **Registered users**.

To let a web site display an entity's records without requiring a visitor to sign in, grant **View** to **Anonymous users**.

{% hint style="danger" %}
Granting a permission to **Anonymous users** makes that entity reachable without any sign-in. Grant **View** only where the data is intended to be public, and do not grant **Insert**, **Update**, **Replace** or **Delete** to anonymous users, because doing so allows unauthenticated changes to your data.
{% endhint %}

Granting a permission to each individual role is equivalent to granting it to **Registered users**. Where every signed-in user should have access, set it once on **Registered users**.

### Publishing security changes

Table security changes take effect only after a **metadata publish**. Until then the entity continues to respond as it did before, which can appear as a failed change rather than an unpublished one.

## How access appears in a web site

Where the helper library's documented pattern is followed, a web site attempts every read anonymously first and responds to the result:

| Table security                                       | What the visitor sees                                                      |
| ---------------------------------------------------- | -------------------------------------------------------------------------- |
| **View** granted to **Anonymous users**              | Records, with no prompt to sign in.                                        |
| **View** not granted to **Anonymous users**          | A prompt to sign in, shown only at the point the data is requested.        |
| Signed in, but **View** not held by that user's role | A message distinguishing insufficient permission from not being signed in. |

Setting one entity readable anonymously while others require a sign-in is the quickest way to confirm a web site is behaving correctly: it produces both outcomes on the same screen.

## Where to go next

* [Create a web site](/learning.comunitynexus/26.2/toolkit-guides/web-sites/create-a-web-site.md)