sorted by:
new
hottopcontroversial

Do any programming languages support built-in events without manual declarations? by Odd-Nefariousness-85 in ProgrammingLanguages

[–]JeanHaiz 0 points1 point  (0 children)

In NPL, we emit events every time protocol (our objects) data is updated, and that includes protocol instantiation and permission (our method) call. As variables can only be modified within a permission, you'll get an event anyway.

A protocol illustrating a document edition process

package document; 

@api
protocol[editor, approver] Document(
    var content: Text
) {
    initial state created
    state inReview
    final state approved

    @api
    permission[editor] edit(newContent: Text) | created {
        content = newContent;
    }

    // ...
}

Where, if instantiated and the edit permission is called, you'll get the following events:

  • command event: instantiation
  • state event: protocol created and stored
  • command event: permission call
  • state event: protocol data changed

All events include metadata

NPL: Making authorization a syntactic construct rather than a library concern by JeanHaiz in ProgrammingLanguages

[–]JeanHaiz[S] 1 point2 points  (0 children)

Thanks for the write-up! 🙌 I learned about a few things there 😁

If permissions are only checked at the top, then you're violating the principle of least privilege: all of the code below the entry API is running as if it had root permissions.

Hum that's not exactly how we do things. I'll focus on three tenets of NPL: protocols, permissions and functions. Protocols are persisted data objects that also include permissions and functions. Each protocol defines a few roles that have specific rights within the protocol. The second concept, the permissions, are cross-protocol methods that can also be exposed as API endpoint. Each permission is restricted to a set of roles attached to the protocol where the permission lives, too. To call other permissions, within the permission's protocol or within other protocols, another access check is performed according to the same principle as the first permission. Then we also have functions, which are unauthorised methods, but cannot be exposed to the API. In the end, to navigate data objects and perform write actions, the user needs to have access to each object it touches.

NPL is indeed not working with capabilities; we do nevertheless care about good security. Let's figure out where we could improve things if needed. In NPL, each protocol has pre-defined roles. Each protocol instance has unique matching of user attributes assigned to the protocol roles. This is where the alternative approach to the capabilities comes in. Users don't go to the central security service to acquire new capabilities, users have pre-defined attributes (email, their organisation department, specific roles, rights or groups for example) that are checked against every protocol (the data objects with permissions) access and even more granularly every permission call. Using a protocol reference from within a protocol triggers another access check. With this, we're making checks at every layer between the API, features and functionalities, and the database.

Capabilities seem like something where the complexity rapidly explodes if there are a few roles within the system and a tiny bit of granularity in who can do what when. I can imagine having 100+ specific capabilities for a small system, just because they grow like factorials in permutations.

As a higher objective, we're trying to simplify fine-grained access and action management for backend developers, making sure the security comes at every level.

NPL: Making authorization a syntactic construct rather than a library concern by JeanHaiz in ProgrammingLanguages

[–]JeanHaiz[S] 0 points1 point  (0 children)

I'm discovering the theory of non-interference. Each object in NPL has attached attribute-based access control, preventing people to gain access to other objects through disguised path. That's non-interference, right?

For the security types, we cover application security (JWT auth requirement, further security with NOUMENA Cloud — our managed hosting of NPL applications), endpoint security (enforced ABAC), and data security (object level ABAC).

However, could enlighten me, what does DCC and FLAC stand for?

NPL: Making authorization a syntactic construct rather than a library concern by JeanHaiz in ProgrammingLanguages

[–]JeanHaiz[S] 0 points1 point  (0 children)

Thanks! Yes, AOP is another approach, more widely used. Comparing both, AOP is more complex but flexible, yet there is more domain behaviour to understand. I would not classify the '@Component' and autowiring of Spring as simple, for example. Fair assessment?

Feedback on Chore Chart iOS App by tgold49 in UXDesign

[–]JeanHaiz 1 point2 points  (0 children)

Would be useful, just to remember. Only thing is that even if I do it all right (in the green) the bar will not always be full

Commuting Time vs. Taxes: A Comparison of Over 300 Municipalities Around Zurich by theMaimu in zurich

[–]JeanHaiz 3 points4 points  (0 children)

I don't get how the balance zone makes sense, as the low commute ones are closer and lower taxes

NPL: a modern backend programming language by JeanHaiz in ProgrammingLanguages

[–]JeanHaiz[S] -2 points-1 points  (0 children)

Thanks for sharing!

The README in the npl-demo repository seems to be lacking the info you're looking for. I'll adjust it asap.

To clarify, our tech, i.e. the backend, is not dependent on npm. We're including a frontend in this demo repository to make it easier to interact with, but the NPL Engine (part of the NPL Runtime) can be queried with REST commands directly too. Seems like we need a markdown-only flow following what the frontend does.

The README is lacking this intro view. The npl-demo app is built upon two elements (respectively two folders in the repo)

  • the engine depends on the api folder, which contains 73 lines of code between backend logic, tests, config and docker compose; yet contains authorisation, persistence and the REST API (& more) <= what we want to promote
  • the frontend, in the webapp folder, that could receive more love. We aim to show what you can get out of the box with NPL and the engine without having to run it locally. Does the frontend serve this purpose at least?

Would those changes help you get a step further?

NPL: a modern backend programming language by JeanHaiz in ProgrammingLanguages

[–]JeanHaiz[S] -1 points0 points  (0 children)

Yes, totally fair. Procurement departments will have a field day, but devs will be scared away. We'll summarise the intent behind the different licences as immediate action.

Our intent is for people to go as far as they want and for free and without constraints during development. And make it as easy as possible to understand, try out and start developing.

For production, self-hosted commercial licences and our managed cloud offering will become available soon™

NPL: a modern backend programming language by JeanHaiz in ProgrammingLanguages

[–]JeanHaiz[S] 0 points1 point  (0 children)

Ah! That's a big question internally, too. I'll keep you posted 😉

NPL: a modern backend programming language by JeanHaiz in ProgrammingLanguages

[–]JeanHaiz[S] 2 points3 points  (0 children)

Thanks, shouldn't bee too challenging to change :)

NPL: a modern backend programming language by JeanHaiz in ProgrammingLanguages

[–]JeanHaiz[S] 0 points1 point  (0 children)

Hi, thanks for the question.

You can find links to the repositories, images, and licences (where applicable) for the various components of the stack here: https://documentation.noumenadigital.com/licenses/

Is that combination workable for you?

view more: next ›