3
$\begingroup$

Most programming languages model the human beings using the system, as data like any other data. It is only through loose convention and framework level convention that things like authentication and data ownership are dealt with. While flexible, this leads re implementation of things which users of the system expect to just work, and on the main haven't changed much in the past decade.

Are there programming languages which model the user as a fundamental primitive?

When I say user, I do not mean authentication. And any type system which attempted to model users would of course need to be extensible by program authors to tailor to the needs to software products. But like so many languages have things such as tasks, memory, data types, built into the language itself with all of that extensibility available, it seems like we should have a "user role", "user identity" keyword that allows for algebraic expressiveness of what our products demand.

Why should "is the current user / 3rd party which is accessing the data on behalf of the user allowed to access this data for a certain reason" always be implemented in library level code, when this concern is perhaps the most important consideration for any business making its profit off of the manipulation and storage of contracts pertaining to services rendered?

It surprises me that this has not been solved at a language level given its importance.

$\endgroup$
9
  • 2
    $\begingroup$ Authentication mechanisms have changed rather a lot in the last decade and will continue to change in the next decade. Besides the rise of 2FA, fingerprint and face authentication, password managers, hardware keys and OTP, we have much better password hashing algorithms, and we now understand that it's counterproductive to force users to change periodically their password. Best practices change, and passwordless authentication is most likely going to get more common. $\endgroup$
    – kaya3
    Commented Apr 29 at 1:47
  • 2
    $\begingroup$ More generally, if the language favours a particular model of the user, then it will only be useful for writing programs where that model is both accurate and reasonably complete. A model of human users won't be very well-suited for writing APIs, for example; rather a lot of code has no (direct) human user at all, it is used by other code. $\endgroup$
    – kaya3
    Commented Apr 29 at 1:50
  • $\begingroup$ PostgreSQL roles and privileges. Roles are PostgreSQL's concept of users or groups, and the database actions they may perform can be restricted, including preventing users from modifying tables others have created (ownership). This question suggests that these permissions don't natively extend to individual rows, but you can even do that using triggers (albeit this goes back to re-implementation). $\endgroup$
    – tarzh
    Commented Apr 29 at 2:48
  • 2
    $\begingroup$ I think you need to edit the question with some more details of what it means to model the users as language constructs; at the moment it's not clear what sorts of language feature might fit within that description, and one of the obvious possibilities has just been ruled out. Either examples of what that would entail, or a direct description of the perimeter of what you're thinking of, could make that work. $\endgroup$
    – Michael Homer ♦
    Commented Apr 29 at 3:43
  • 2
    $\begingroup$ What would ‘human being’ mean for a microservice?  A script?  A web service?  A GUI application under the control of an automated test suite?  A GUI app accessed over a remote desktop?  A cron job?  A stored function in a database?  A program launched by a human but running in the background?  What could you model that would be simple enough to cover many of those cases, but still be complex enough to be worth doing? $\endgroup$
    – gidds
    Commented Apr 29 at 23:26

2 Answers 2

Reset to default
3
$\begingroup$

Are there programming languages which model the user as a fundamental primitive?

Perhaps. There are all sorts of DSLs out there and there is a good chance some of them cover specific user/role/capabilities models. I won't even try to give a list, because it depends much more on what one considers "programming languages" than anything else.

Why should "is the current user / 3rd party which is accessing the data on behalf of the user allowed to access this data for a certain reason" always be implemented in library level code, when this concern is perhaps the most important consideration for any business making its profit off of the manipulation and storage of contracts pertaining to services rendered?

Because these concepts really are not as simple as they sound, and conversely the generic parts are as simple to be useless.

Even concepts like "user role" and "user identity" vary wildly between authN/authZ approaches. Is the identity an opaque token? Is it a UPN with meaningful user and domain? Is it a distinguished name with hierarchical information? Are there even identities, or just anonymous sessions with individual capabilities?

The generic stuff that remains does not make for great abstractions. If you want a generic identifier, languages already offer tons of those - numbers, strings, raw bytes, opaque objects. If you want a generic "can this session do that?" - that is maybe a simple bool, a first-class function, or a code path that does not even have access to disallowed actions.
These abstractions are much more generic than the use-case of users/roles/capabilities. Restricting them to that narrative or duplicating them is a loss for general purpose languages.

$\endgroup$
3
  • $\begingroup$ The specifics of how one identifies the symbolic truth - "who invoked this method and are they allowed to"? do vary widely. But do do processor architectures. By your logic, we wouldn't use any higher level languages because some chips are little endian and some are big - but that's the exact reason we need higher level languages. JavaScript had to add private identifiers at a language level... I think the current user who is triggering method execution is the most important aspect and it's surprising this is always re implemented $\endgroup$
    – Bryan Rayner
    Commented May 12 at 14:54
  • $\begingroup$ @BryanRayner I think that you even think there is a current user - be it in the meaning of at least one, exactly one, or even that there is such a thing as users - means you are not looking at this broad enough. High level languages add domain agnostic abstractions on top of the bare metal, what you describe is extremely domain specific and this a whole different focus than what general purpose languages provide. $\endgroup$
    – MisterMiyagi
    Commented May 27 at 17:10
  • $\begingroup$ As a data point, I have spent the better part of the last year deploying a new authN and authZ mechanism at my dayjob. Yet only about 1% of code is aware there are users, about 10% is aware there are capabilities, and at least 50% avoids having even traces of knowledge about either concept on purpose. "Who requested this" is an opaque blob in an audit log at the very edge of our infrastructure. $\endgroup$
    – MisterMiyagi
    Commented May 27 at 17:17
-3
$\begingroup$

Languages tend to add abstractions and/or tools (within the languages) which help developers to build even more abstractions, through development.

It seems to me that the existence of an entity User, in the language (maybe in form of language constructs, maybe in form of data-structures, maybe both) would not produce more, but less abstraction.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .