@tiddlywiki/mws 0.0.14 → 0.0.16

package/editions/mws-docs/tiddlers/$__StoryList.tid

@@ -1,5 +1,5 @@
-created: 20250426194618683
-list: [[MWS and SQLite]] HelloThere Installation Usage Reference
-modified: 20250426194618683
+created: 20250428174600355
+list: [[Access Control]] [[Moduler Design]] [[MWS and SQLite]] [[Request Server]] Architecture HelloThere Installation Usage Reference
+modified: 20250428174603436
 title: $:/StoryList
 type: text/vnd.tiddlywiki

package/editions/mws-docs/tiddlers/Access Control.md

@@ -0,0 +1,17 @@
+Access Control is implemented separately for both recipes and bags, but bags can inherit the ACL of recipes they are added to. 
+
+### Permission Inheritance
+- Users receive combined permissions from all assigned roles
+- When roles grant different permission levels for the same resource, the higher access level is granted. For example, if one role grants "read" and another grants "write" access to a recipe, the user receives "write" access since it includes all lower-level permissions. If a role grants "admin", it inherits both "read" and "write". 
+
+### "Readonly" permission
+
+If this were reversed, and users with explicit "read" access were forbidden from writing, it would significantly complicate roles. 
+
+Imagine a group of engineers working on several projects. Each project has people who are responsible for editing the documentation for everyone else. So everyone needs to be granted the read permission on all projects, but only a few people are granted the write permission on each project. 
+
+The easiest approach is to maintain one role which grants "read" access to all users, and then maintain additional roles to grant "write" access to the users responsible for each project. 
+
+If granting read access explicitly prevented a user from writing, we would need to create two roles for each project, one which which grants write access for the project, and another which grants read access to all other projects. 
+
+Every time a new project is added, all other projects would need to grant "read" access to that new "all projects but one" role on every single wiki for every single project in the entire organization. 

package/editions/mws-docs/tiddlers/Access Control.md.meta

@@ -0,0 +1,5 @@
+created: 20250428145509001
+modified: 20250428174641314
+tags: Architecture
+title: Access Control
+type: text/markdown

package/editions/mws-docs/tiddlers/Application Access & Security.md

@@ -0,0 +1,98 @@
+
+Users can be administered through two interfaces:
+
+1. Web-based Administrative Interface
+   - Accessible to all users.
+   - Provides graphical interface for user operations
+   - Real-time validation and feedback
+1. Command-line Interface (CLI) Tools
+   - Only available to server owner.
+   - Suitable for automation and scripting
+   - Enables batch operations
+   - Useful for system initialization
+
+Each user account contains the following essential components:
+
+- **Username**
+  - Must be unique across the system
+  - Case-sensitive
+  - Used for authentication and audit trails
+- **Password**
+  - Stored using secure hashing algorithms
+  - Never stored in plaintext
+  - Subject to complexity requirements
+- **Email**
+  - Eventually used for the obvious password reset.
+- **Role Assignments**
+  - Multiple roles can be assigned
+  - Inherited permissions from all assigned roles
+  - Dynamic permission calculation based on role combination
+
+## Access Levels
+
+Conceptually, there are 6 access levels.
+
+- **Site owner** - has file system access to the server, and can run CLI commands. Presumably they also have a site admin account. 
+- **Site admin** - Users with the admin *role*. They can assign owners and change permissions, and have full read and write access. Most ACL checks are skipped for the admin role. 
+- **Entity owner** - Users who "own" an entity (bag or recipe). They can change permissions for that entity, and have full read and write access. *Entity admins* cannot change the owner.
+- **Entity admin** - Users granted the admin *permission* on an entity. They cannot change the owner, but they can change the permissions of other users for that entity. 
+- **Entity write** - Users granted the write *permission* on an enitity. They can list, read, create, update, and delete tiddlers, but cannot change permissions. 
+- **Entity read** - Users granted the read *permission* on an entity. They can list and read tiddlers, but cannot do anything else. 
+
+## Entities
+
+- **Bag** - A collection of tiddlers with unique titles
+- **Recipe** - A stack of bags in a specific order. Bags may inherit the ACL of a recipe they are included in. 
+
+## Roles
+
+- Roles have names and descriptions
+- Multiple users can be assigned to a role
+
+## Permissions
+
+- **READ** - Read tiddlers from an entity.
+- **WRITE** - Write tiddlers to an entity.
+- **ADMIN** - Update ACL for an entity.
+
+## Admin
+
+- There is an admin *role* and an admin *permission*. 
+- Roles are given specific permissions for specific entities (bags and recipes).
+- The admin *role* has automatic admin *permission* for everything.
+
+## ACL
+
+- Grants the **Permission** for an **Entity** to a **Role**. 
+- Entities without an ACL are either public or private (configurable).
+
+## Ownership
+
+- Ownership of an entity grants the "admin" *permission*.
+- Only site admins can change the owner of an entity. 
+- Users with "admin" *permission* **cannot** change ownership.
+
+## User Types
+
+#### Administrator (ADMIN) Role
+
+- Full system access and configuration rights
+- Most access checks are skipped
+- Can create, modify, and delete user accounts
+- Manages role assignments and permissions
+- Has full permissions on all recipes and bags
+
+#### Regular Users
+
+- Created by administrators
+- Permissions determined by assigned roles
+- Access limited to specific recipes based on role permissions
+- Access to recipes without an ACL is based on recipe config
+
+#### Guest Users
+
+- Users not logged in.
+- No inherent permissions
+- Can access recipes which allow it
+- Read/write can be enabled by server config
+- Useful for public wikis or documentation sites

package/editions/mws-docs/tiddlers/Application Access & Security.md.meta

@@ -0,0 +1,5 @@
+created: 20250428144431745
+modified: 20250428152640317
+tags: Reference
+title: Application Access & Security
+type: text/markdown

package/editions/mws-docs/tiddlers/HTTP API.md

@@ -0,0 +1,17 @@
+The MultiWikiServer HTTP API provides management and tiddler endpoints. 
+
+The design goals of the API are:
+
+ - Connect the client and server as transparently as possible. 
+ - Be easy to understand and use via Javascript. 
+ - Have strict validation of incoming requests.
+
+## Management
+
+- On the client, most request paths are defined by a single adaptor function which accepts the input for the server and returns a promise which resolves to the server's parsed response.  
+- The server may throw a user error (or a string), which is expected to return to the client. It should give them an actionable understanding of what went wrong. 
+- The API essentially forwards a function call from the client to the server, using `fetch`. It expects a Javascript client, and is not intended to support form submissions directly.
+
+## Tiddler
+
+The tiddler API was based on [the API of TiddlyWeb](https://tank.peermore.com/tanks/tiddlyweb/HTTP%20API), first developed in 2008 by Chris Dent, but is more oriented around JSON and Typescript. The concept of resources remains and in the future it will hopefully be adapted to serve static versions of tiddlers. 

package/editions/mws-docs/tiddlers/HTTP API.md.meta

@@ -0,0 +1,5 @@
+created: 20250428152532763
+modified: 20250428152617476
+tags: Reference
+title: HTTP API
+type: text/markdown

package/editions/mws-docs/tiddlers/Installation.tid

@@ -1,5 +1,5 @@
 created: 20241105133737778
-modified: 20250417165800863
+modified: 20250428144159846
 tags: TableOfContents
 title: Installation
 type: text/vnd.tiddlywiki
@@ -20,5 +20,14 @@ See [[Troubleshooting]] if you encounter any errors.
 To update your copy of MWS in the future with newer changes will require re-downloading the code, taking care not to lose any changes you might have made.
 
 # Make a backup: Copy or zip your project folder to a safe backup folder.  <<.copy-code-to-clipboard "tar -cf archive.tar my_folder">>
-# Get the latest version. Notice that the second word is `install` instead of `init`. This pulls the latest version from NPM and installs it. <<.copy-code-to-clipboard "npm install @tiddlywiki/mws@latest">>
+# Get the latest version. Notice that the second word is `install` instead of `init`. This pulls the latest version from NPM and installs it. <<.copy-code-to-clipboard "npm install @tiddlywiki/mws@latest --save-exact">>
 # Start the server. On startup, MWS checks the database schema and updates it automatically if there are changes. Normally this works just fine, but it can fail, which is why it's important to save a backup first. <<.copy-code-to-clipboard "npm start">>
+
+!!! Git repo
+
+It is optionally recommended to save a history of your project configuration using git. 
+
+* On Windows you can use [[GitHub Desktop|https://github.com/apps/desktop]]. 
+* On Linux, git is usually preinstalled or available via the default package manager for your distro. 
+
+If you decide to do this, you should move the wiki folder out of the project folder, and change the `wikiPath` setting accordingly. 

package/editions/mws-docs/tiddlers/Moduler Design.md

@@ -22,3 +22,8 @@
 
 - Maps route definitions into service handlers
 - HTTP, Websockets
+
+### Database Connector
+- Prisma handles query translation (wasm or native addon)
+- Prisma supports custom adapters, and also provides standard ones
+- Connector classes in MWS take care of database setup and schema updates

package/editions/mws-docs/tiddlers/Moduler Design.md.meta

@@ -1,5 +1,5 @@
 created: 20250418140335465
-modified: 20250418183050517
+modified: 20250428143321351
 tags: Architecture
 title: Moduler Design
 type: text/markdown

package/editions/mws-docs/tiddlers/Reference.md

@@ -1,149 +0,0 @@
-# Authentication & Authorization
-
-## Overview
-
-Our application has transitioned from a conventional username/password authentication system to a more robust Authentication and Authorization implementation. This new system supports multiple user accounts, roles, permissions, and a comprehensive access control list.
-
-## Key Features
-
-1. Multiple User Accounts
-1. Role-based Access Control
-1. Granular Permissions
-1. Access Control List (ACL)
-
-## Application Access & Security
-
-### Access Levels
-
-Conceptually, there are 6 access levels.
-
-- **Site owner** - has file system access to the server, and can run CLI commands. Presumably they also have a site admin account. 
-- **Site admin** - Users with the admin *role*. They can assign owners and change permissions, and have full read and write access.
-- **Entity owner** - Users who "own" an entity (bag or recipe). They can change permissions for that entity, and have full read and write access.
-- **Entity admin** - Users granted the admin *permission* on an entity. They cannot change the owner, but they can change the permissions of other users for that entity. 
-- **Entity write** - Users granted the write *permission* on an enitity. They can list, read, create, update, and delete tiddlers, but cannot change permissions. 
-- **Entity read** - Users granted the read *permission* on an entity. They can list and read tiddlers, but cannot do anything else. 
-
-### Initial Setup
-
-When you first launch the Multiwiki Server, it creates a default admin user. The username is `admin` and the password is `1234`. To secure your installation you should change this immediately. 
-
-### Entities
-
-- **Bag** - A collection of tiddlers with unique titles
-- **Recipe** - A stack of bags in a specific order. Bags may inherit the ACL of a recipe they are included in. 
-
-### Roles
-
-- Roles have names and descriptions
-- Multiple users can be assigned to a role
-
-### Permissions
-
-- **READ** - Read tiddlers from an entity.
-- **WRITE** - Write tiddlers to an entity.
-- **ADMIN** - Update ACL for an entity.
-
-### ACL
-
-- Grants the **Permission** for an **Entity** to a **Role**. 
-- Entities without an ACL are either public or private (configurable).
-
-### Ownership
-
-- Ownership of an entity grants the "admin" *permission*.
-- Only site admins can change the owner of an entity. 
-- Users with "admin" *permission* **cannot** change ownership.
-
-### User Types
-
-#### Administrator (ADMIN) Role
-
-- Full system access and configuration rights
-- Most access checks are skipped
-- Can create, modify, and delete user accounts
-- Manages role assignments and permissions
-- Has full permissions on all recipes and bags
-
-#### Regular Users
-
-- Created by administrators
-- Permissions determined by assigned roles
-- Access limited to specific recipes based on role permissions
-- Access to recipes without an ACL is based on recipe config
-
-#### Guest Users
-
-- Users not logged in.
-- No inherent permissions
-- Can access recipes which allow it
-- Read/write can be enabled by server config
-- Useful for public wikis or documentation sites
-
-### Access Control
-
-Access Control is implemented separately for both recipes and bags, but bags can in inherit the ACL of recipes they are added to. 
-
-#### Permission Inheritance
-- Users receive combined permissions from all assigned roles
-- When roles grant different permission levels for the same resource, the higher access level is granted. For example, if one role grants "read" and another grants "write" access to a recipe, the user receives "write" access since it includes all lower-level permissions.
-
-If this were reversed, and users with explicit "read" access were forbidden from writing, it would significantly complicate roles. 
-
-Imagine a group of engineers working on several projects. Each project has people who are responsible for editing the documentation for everyone else. So everyone needs to be granted the read permission on all projects, but only a few people are granted the write permission on each project. 
-
-The easiest approach is to maintain one role which grants "read" access to all users, and then maintain additional roles to grant "write" access to the users responsible for each project. 
-
-If granting read access explicitly prevented a user from writing, we would need to create two roles for each project, one which which grants write access for the project, and another which grants read access to all other projects. 
-
-Every time a new project is added, all other projects would need to grant "read" access to that new "all projects but one" role on every single wiki for every single project in the entire organization. 
-
-## User Management & Security Architecture
-
-### User Account Management
-
-Users can be administered through two interfaces:
-
-1. Web-based Administrative Interface
-   - Accessible to all users.
-   - Provides graphical interface for user operations
-   - Real-time validation and feedback
-1. Command-line Interface (CLI) Tools
-   - Only available to server owner.
-   - Suitable for automation and scripting
-   - Enables batch operations
-   - Useful for system initialization
-
-Each user account contains the following essential components:
-
-- **Username**
-  - Must be unique across the system
-  - Case-sensitive
-  - Used for authentication and audit trails
-- **Password**
-  - Stored using secure hashing algorithms
-  - Never stored in plaintext
-  - Subject to complexity requirements
-- **Email**
-  - Eventually used for the obvious password reset.
-- **Role Assignments**
-  - Multiple roles can be assigned
-  - Inherited permissions from all assigned roles
-  - Dynamic permission calculation based on role combination
-
-# HTTP API
-
-The MultiWikiServer HTTP API provides management and tiddler endpoints. It was based on [the API of TiddlyWeb](https://tank.peermore.com/tanks/tiddlyweb/HTTP%20API), first developed in 2008 by Chris Dent, but is more oriented around JSON and Typescript. 
-
-The design goals of the API are:
-
- - Connect the client and server as transparently as possible. 
- - Follow the principles of remote procedure calls.
- - Be easy to understand and use via Javascript. 
- - Have strict validation of incoming requests.
-
-General points about the design:
-
-- On the client, most request paths are defined by a single adaptor function which accepts the input for the server and returns a promise which resolves to the server's parsed response.  
-- The server may throw a user error, which is expected to return to the client. It should give them an actionable understanding of what went wrong. 
-

package/editions/mws-docs/tiddlers/Reference.md.meta

@@ -1,2 +1,5 @@
+created: 20250428144428969
+modified: 20250428152626286
+tags: TableOfContents
 title: Reference
-tags: TableOfContents
+type: text/x-markdown

package/editions/mws-docs/tiddlers/Usage.tid

@@ -1,5 +1,5 @@
 created: 20241105133737778
-modified: 20250417170530535
+modified: 20250428144341860
 tags: TableOfContents
 title: Usage
 type: text/vnd.tiddlywiki
@@ -8,7 +8,7 @@ Once MWS is successfully [[installed|Installation]], you can access it by visiti
 
 On first start, a default user is created with username `admin` and password `1234`. However, also by default, the server is only accessible to browsers on the same machine.
 
-If you intend to put an MWS installation on a public network like the Internet, the server will need to be secured with the following steps:
+If you intend to make an MWS installation available on the Internet, the server should first be secured with the following steps:
 
-* Change the administrator password.
+* Change the administrator password
 * Install HTTPS server certificates.

package/package.json

@@ -1,7 +1,8 @@
 {
   "name": "@tiddlywiki/mws",
+  "description": "TiddlyWiki Multiple Wiki Server",
   "private": false,
-  "version": "0.0.14",
+  "version": "0.0.16",
   "type": "module",
   "exports": {
     "types": "./src/server.ts",
@@ -33,7 +34,7 @@
     "prisma": "npm run gen:client && npm run gen:sql",
     "prisma:studio": "DATABASE_URL=file:../editions/mws/store/database.sqlite prisma studio",
     "certs": "(cd runtime-config && bash localhost_certs.sh)",
-    "start": "npm run build && node mws.dev.mjs",
+    "start": "SKIPDTS=1 npm run build && node mws.dev.mjs init-store && node mws.dev.mjs listen",
     "build": "npm run tsc && tsup",
     "install-android": "GYP_DEFINES=\"android_ndk_path=''\" npm install",
     "postinstall": "env-cmd -e prisma-env prisma generate",
@@ -42,7 +43,8 @@
     "test": "(git clean -dfx tests && cd tests && npm install .. --no-save && npm test)",
     "fulltest": "mv node_modules node_modules_old; npm run test:pack; mv node_modules_old node_modules",
     "prisma:adapter:better": "cp -rfv ../prisma/packages/adapter-better-sqlite3/src/* src/adapter-better-sqlite3",
-    "prisma:adapter:libsql": "cp -rfv ../prisma/packages/adapter-libsql/src/* src/adapter-libsql"
+    "prisma:adapter:libsql": "cp -rfv ../prisma/packages/adapter-libsql/src/* src/adapter-libsql",
+    "prepublishOnly": "npm run build && node mws.dev.mjs --client-build"
   },
   "dependencies": {
     "@prisma/adapter-better-sqlite3": "6.7.0-dev.48",
@@ -59,6 +61,7 @@
     "zod": "^3.24.2"
   },
   "devDependencies": {
+    "commander": "^13.1.0",
     "esbuild": "0.25.2",
     "mime-types": "^2.1.35",
     "send": "^1.1.0",