mirror of
https://github.com/Rolands-Laucis/Socio.git
synced 2026-05-21 06:46:19 -06:00
upd
This commit is contained in:
parent
75b5f34ec6
commit
4eba58b024
3 changed files with 21 additions and 16 deletions
12
README.md
12
README.md
|
|
@ -6,11 +6,11 @@
|
|||
|
||||
No more API middleware and backend DB interfacing functions and wrappers and handlers. Write your SQL queries on the frontend and have their results be automagically refreshed on all clients when a resource is changed on the server DB. This is secure.
|
||||
|
||||
[Basic Demo](https://github.com/Rolands-Laucis/Socio/blob/master/demos/basic/readme.md) - interactive bare-bones demo.
|
||||
[Basic Demo](https://github.com/Rolands-Laucis/Socio/blob/master/demos/basic/readme.md) - interactive bare-bones demo project.
|
||||
|
||||
[Secure Full-Stack Framework Demo](https://github.com/Rolands-Laucis/Socio/tree/master/demos/full-stack_framework#readme) - interactive demo on a SvelteKit-Vite app.
|
||||
[Secure Full-Stack Framework Demo](https://github.com/Rolands-Laucis/Socio/tree/master/demos/full-stack_framework#readme) - interactive demo project with SvelteKit and Vite.
|
||||
|
||||
[Simple Documentation](https://github.com/Rolands-Laucis/Socio/blob/master/core/docs.md) page to see direct examples and explanations of how to use various parts of the lib. Might be out of date, but the lib core files arent that big, and they are full of comments, so u can read up on those.
|
||||
[Simple Documentation](https://github.com/Rolands-Laucis/Socio/blob/master/core/docs.md) page to see direct examples and explanations of how to use various parts of the lib.
|
||||
|
||||
### Instalation
|
||||
In your Node.js project root dir:
|
||||
|
|
@ -20,7 +20,7 @@ npm i socio
|
|||
|
||||
## How? ✨
|
||||
|
||||
On the backend instantiate the ``SocioServer`` class and provide it a single DB (of your choice) raw query function, that will receive the SQL string and dynamic parameters object. The raw result of that is passed back to the caller on the client side, where the SQL and params sit - where an instance of ``SocioClient`` has made a .query() call. Using the same mechanism, an automagical subscription to that SQL resource can be registered via the .subscribe() method, that runs your callback function whenever the data this query relies upon has changed on the backend DB for any reason.
|
||||
On the backend instantiate the ``SocioServer`` class and provide it a single DB (of your choice) raw query function, that will receive the SQL string and dynamic parameters object. The raw result of that is passed back to the caller on the client side, where the SQL and params sit - where an instance of ``SocioClient`` has made a .query() call. Using the same mechanism, an automagical subscription to that SQL resource can be registered via the .subscribe() method, that runs your callback function whenever the data this query relies upon has changed on the backend DB.
|
||||
|
||||
## What about SQL injections and overall data safety? 💉
|
||||
|
||||
|
|
@ -105,10 +105,10 @@ As this is an open source project that i spend my free time on, perhaps someone
|
|||
* plenty more
|
||||
|
||||
## Related lib and tech 🔗
|
||||
* [WS](https://www.npmjs.com/package/ws) *Socio uses on the server*
|
||||
* [The WebSocket API](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) *Socio uses on the browser*
|
||||
* [https://github.com/ghostebony/sse](https://github.com/ghostebony/sse)
|
||||
* [Server-sent events API](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events)
|
||||
* [The WebSocket API](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) *Socio uses on the browser*
|
||||
* [WS](https://www.npmjs.com/package/ws) *Socio uses on the server*
|
||||
* [Firebase Realtime Database](https://firebase.google.com/docs/database) serverless database. Google backed.
|
||||
* [PocketBase](https://pocketbase.io/) serverless database.
|
||||
* [SurrealDB](https://surrealdb.com/) serverless database.
|
||||
|
|
|
|||
|
|
@ -6,11 +6,11 @@
|
|||
|
||||
No more API middleware and backend DB interfacing functions and wrappers and handlers. Write your SQL queries on the frontend and have their results be automagically refreshed on all clients when a resource is changed on the server DB. This is secure.
|
||||
|
||||
[Basic Demo](https://github.com/Rolands-Laucis/Socio/blob/master/demos/basic/readme.md) - interactive bare-bones demo.
|
||||
[Basic Demo](https://github.com/Rolands-Laucis/Socio/blob/master/demos/basic/readme.md) - interactive bare-bones demo project.
|
||||
|
||||
[Secure Full-Stack Framework Demo](https://github.com/Rolands-Laucis/Socio/tree/master/demos/full-stack_framework#readme) - interactive demo on a SvelteKit-Vite app.
|
||||
[Secure Full-Stack Framework Demo](https://github.com/Rolands-Laucis/Socio/tree/master/demos/full-stack_framework#readme) - interactive demo project with SvelteKit and Vite.
|
||||
|
||||
[Simple Documentation](https://github.com/Rolands-Laucis/Socio/blob/master/core/docs.md) page to see direct examples and explanations of how to use various parts of the lib. Might be out of date, but the lib core files arent that big, and they are full of comments, so u can read up on those.
|
||||
[Simple Documentation](https://github.com/Rolands-Laucis/Socio/blob/master/core/docs.md) page to see direct examples and explanations of how to use various parts of the lib.
|
||||
|
||||
### Instalation
|
||||
In your Node.js project root dir:
|
||||
|
|
@ -20,7 +20,7 @@ npm i socio
|
|||
|
||||
## How? ✨
|
||||
|
||||
On the backend instantiate the ``SocioServer`` class and provide it a single DB (of your choice) raw query function, that will receive the SQL string and dynamic parameters object. The raw result of that is passed back to the caller on the client side, where the SQL and params sit - where an instance of ``SocioClient`` has made a .query() call. Using the same mechanism, an automagical subscription to that SQL resource can be registered via the .subscribe() method, that runs your callback function whenever the data this query relies upon has changed on the backend DB for any reason.
|
||||
On the backend instantiate the ``SocioServer`` class and provide it a single DB (of your choice) raw query function, that will receive the SQL string and dynamic parameters object. The raw result of that is passed back to the caller on the client side, where the SQL and params sit - where an instance of ``SocioClient`` has made a .query() call. Using the same mechanism, an automagical subscription to that SQL resource can be registered via the .subscribe() method, that runs your callback function whenever the data this query relies upon has changed on the backend DB.
|
||||
|
||||
## What about SQL injections and overall data safety? 💉
|
||||
|
||||
|
|
@ -105,10 +105,10 @@ As this is an open source project that i spend my free time on, perhaps someone
|
|||
* plenty more
|
||||
|
||||
## Related lib and tech 🔗
|
||||
* [WS](https://www.npmjs.com/package/ws) *Socio uses on the server*
|
||||
* [The WebSocket API](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) *Socio uses on the browser*
|
||||
* [https://github.com/ghostebony/sse](https://github.com/ghostebony/sse)
|
||||
* [Server-sent events API](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events)
|
||||
* [The WebSocket API](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) *Socio uses on the browser*
|
||||
* [WS](https://www.npmjs.com/package/ws) *Socio uses on the server*
|
||||
* [Firebase Realtime Database](https://firebase.google.com/docs/database) serverless database. Google backed.
|
||||
* [PocketBase](https://pocketbase.io/) serverless database.
|
||||
* [SurrealDB](https://surrealdb.com/) serverless database.
|
||||
|
|
|
|||
13
core/docs.md
13
core/docs.md
|
|
@ -3,11 +3,15 @@
|
|||
|
||||
### Overview
|
||||
|
||||
The ``./core.js`` file contains logic to be run on a backend server. It exports the class ``SocioServer`` that you instantiate and work with mostly during just the setup initialization of your backend. It creates a websocket server on a port and listens for clients to connect. It is the transaction middle-man between your DB and the SocioClient on the frontend doing queries.
|
||||
* [WS](https://www.npmjs.com/package/ws) Socio uses on the server.
|
||||
* [The WebSocket API](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) Socio uses on the browser.
|
||||
|
||||
The ``./core-client.js`` file contains logic to be run on the frontend browser side of js. It exports the class ``SocioClient`` that you instantiate and work with during the entire lifetime of the page. Use it to make SQL queries to the backend that do some magic to keep your data realtime using WebSocket technology.
|
||||
The ``./core.ts`` file contains logic to be run on a backend server. It exports the class ``SocioServer`` that you instantiate and work with mostly during just the setup initialization of your backend. It creates a websocket server on a port and listens for clients to connect. It is the transaction middle-man between your DB and the SocioClient on the frontend doing queries.
|
||||
|
||||
The ``./secure.js`` file contains logic to be run on a backend server. It exports the class ``SocioSecurity`` that you instantiate and work with mostly during just the setup initialization of your backend. There is also a Vite plugin (``SocioSecurityPlugin``) that wraps that class, that you can use instead in your Vite app config. Should also work as a Rollup plugin, but havent tested. This securely encrypts the socio SQL query strings before serving the production code to the client, such that the client cannot see nor alter the query string, protecting against SQL attacks and general fuckery. However, it is still up to you to sanitize and protect yourself from SQL injections when inserting dynamic data into a query string! An identical setup of this class should be created on the backend server and handed to the SocioServer instance, for it to be able to decrypt the incoming SQL queries. Use .env files to keep your project secrets safe and consistent!
|
||||
The ``./core-client.ts`` file contains logic to be run on the frontend browser side of js. It exports the class ``SocioClient`` that you instantiate and work with during the entire lifetime of the page. Use it to make SQL queries to the backend that do some magic to keep your data realtime using WebSocket technology.
|
||||
|
||||
The ``./secure.ts`` file contains logic to be run on a backend server. It exports the class ``SocioSecurity`` that you instantiate and work with mostly during just the setup initialization of your backend. There is also a Vite plugin (``SocioSecurityPlugin``) that wraps that class, that you can use instead in your Vite app config. Should also work as a Rollup plugin, but havent tested. This securely encrypts the socio SQL query strings before serving the production code to the client, such that the client cannot see nor alter, nor impersonate the query string. However, it is still up to you to sanitize and protect yourself from SQL injections when inserting dynamic data into a query string! An identical setup of this class should be created on the backend server and handed to the SocioServer instance, for it to be able to decrypt the incoming SQL queries. Use .env files to keep your project secrets safe and consistent!
|
||||
**Use HTTPS and WSS secure protocols** to protect against snooping and man-in-the-middle attacks on the dynamic query data.
|
||||
|
||||
### SQL and NoSQL
|
||||
Currently the lib has been developed with a main focus on SQL queries being written on the frontend. This matters, bcs i parse the sent strings with the assumption that they are valid SQL syntax. However, the lib now also supports a NoSQL paradigm in the form of what i call "Server Props".
|
||||
|
|
@ -59,7 +63,8 @@ socserv.RegisterLifecycleHookHandler("auth", (client:SocioSession, params:object
|
|||
//then in your qeury function, add in the user_id dynamic param
|
||||
async function QueryWrap (client:SocioSession, id:id, sql:string, params = {}) {
|
||||
if('user_id' in params) //replace the params client side dummy user_id with the real one. Because the client side user_id cannot be trusted.
|
||||
params.user_id = auth_clients[client.id];
|
||||
params.user_id = auth_clients[client.id];
|
||||
//you could also check if(client.authenticated) ... but that is unnecessary since the incoming msg wouldn't even get this far if the -auth flag is set and the user isnt authed.
|
||||
|
||||
return (await sequelize.query(sql, { logging: false, raw: true, replacements: params }))[0];
|
||||
}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue