Add permissions and user groups

[IanMayo]

It could be useful for us to think about the business requirements around permissions and user groups.

Here are some initial thoughts:

• some kind of authentication required for an access to API
• some users only have some verbs on API (GET), others have more.
• some users only have some verbs on API for some tables

I wonder if there are any online sources with best practices for securing REST APIs?

[thevahidal]

We can look for any good practices but there are two things that we must consider, Authentication (Which basically means if the user has access), and Authorization (Which means the level of access that the user has). I think the something like PocketBase implemented it is really neat, maybe we can adopt their way of doing it.

[IanMayo]

For old-skool web-applications, the hard work was done on the server, including making calls to other backend systems. CORS protection is valid in this context, since we can say Soul should only accept requests from the local server:

But, with modern single-page applications, it's code in the user's browser that is making the REST call. This means we have to open CORS for all addresses:

Sorry if I'm mistaken in the above @thevahidal , but it does seem that for modern SPAs we can only protect Soul in production via authentication and authorisation.

[IanMayo]

Hello @thevahidal - if you're able to put any more high-level thoughts into here, we'll try to move forward on the further detail, and subsequent implementation.

[thevahidal]

For the CORS thing we only have to tell Soul to trust the frontend web apps origin, so the browsers can't complain about it. But you're right that for true protection we need authentication and authorization. But as you know it's a heavy feature and we need a good design for it.

[IanMayo]

Here is the approach taken to auth in a similar app (PostGrest) - but it pushes most responsibilities to the database, but we don't have role-based table access in SQLite.

[IanMayo]

I've just thought of another approach to security. We could introduce a property whereby the API is only available to be called from a Soul Extension. So, users can create a static front-end-only site, host it as an extension, and the REST API is only available from that static site.

In this mode, Soul would not expose any REST routes at all.

That seems pretty bomb-proof :-)

What do you think, @AbegaM ?

[AbegaM]

@IanMayo That seems like a great idea. I will see how we can make the API only accessible from Soul.

[IanMayo]

I've just thought of another approach to security. We could introduce a property whereby the API is only available to be called from a Soul Extension. So, users can create a static front-end-only site, host it as an extension, and the REST API is only available from that static site.

In this mode, Soul would not expose any REST routes at all.

That seems pretty bomb-proof :-)

What do you think, @AbegaM ?

FYI @thevahidal , @AbegaM and I are going to try to progress the above in coming weeks. We'll be sure to share design thoughts/plans before we start writing code.

[thevahidal]

@IanMayo That's awesome, man. I can't wait to see your designs!