|
Gerry Schmitz wrote: MVVM pattern is that it can inadvertently lead to apps that have too many layers and too many allocations.
Remind me again which pattern is it exactly that guarantees that can't happen?
|
|
|
|
|
You're talking wrappers, frameworks and methodologies (MVVM). A "pattern" can be a simple plug-in that "adds" functionality instead of masking or contorting it.
MVVM is a "bunch" of patterns; all directed to "indirection".
A simple statement like: NO code behind ... is a pattern (of behaviour).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Ok. But I don't see how that answers my question?
|
|
|
|
|
Quote: Ok. But I don't see how that answers my question?
I gave you an example: a plug-in. Where are the "layers" and "allocations"? One function reference. Are you saying a plug-in is not a pattern? What is a "door"?
Your "argument" is all patterns are "faulty". Back it up.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
And that guarantees that it will not have "too many layers"?
|
|
|
|
|
I'm searching for good, general literature* on how to design and implement access control management. I'd like to build up the knowledge to design a system myself and/or make informed decisions about the architecture of one.
My focus is authorization, not authentication.
*literature = online,offline,free,paid; anything goes.
Some concrete questions could be
- "in which roughness should I store permissions?"
- "in which format should I store my permissions?"
- "should I use RBAC, UBAC, ACL,... and how would I concretely implement them, cleanly?"
- "How do I combine all that with a system that contains several individual organizations with their own set of permissions?"
Does anyone have recommendations? Even a "look in this corner of the internet would help".
(I really cannot find anything useful about this topic. All search results contain the same hipster stuff)
Just to make sure ... what I'm not looking for:
- A cook book.
- Answers that just say "use this or that, because it's the standard"
- Some "hip" book after which you nod, say "yes, aha, I see", but didn't really make you smarter.
|
|
|
|
|
|
Do you have any recommendations of the many?
Also: Be aware that google is very different depending on the country you are searching from and the locale on your computer. You might get better results than linkedIn and companies trying to sell their products - which is what I get.
|
|
|
|
|
D4rkTrick wrote: Do you have any recommendations of the many?
You need to review what you find and decide for yourself which best meets your requirements.
|
|
|
|
|
D4rkTrick wrote: "in which roughness should I store permissions?"
Having considered that many times what I came up with is that you cannot answer that question without business requirements. And probably some business domain knowledge yourself.
Consider these cases...
Who should have permission to edit a social security number at a company? Who should be able to view it?
Contrast that with who should have permission to change the delivery address? Who should be able to view it? (Even more prickly can someone change a delivery address on an order that has already been delivered?)
Should there be a admin (root admin) that can change everything?
Are there assets that will be shared between companies? If so then who sets the permissions? (That was a very real business case that I had to deal with.)
Answering questions like that is FAR more important than how you implement it in general. But it will certainly drive implementation details.
I would be very wary of suggestions that you should 'plan for the future'. For instance in one of many parallel futures you might be asked to add a field on one form, so obviously the solution is that every single field on every form must have a permission from the beginning. And then the users (not developers) who will be actually setting that up will need to understand hundreds of permissions and implications (like what if the social security number is on two different forms?)
I worked for a company with hundreds of permissions. No one knew what they all did. There was also disagreement about what they should do. So those tasked with changing them just had to experiment.
D4rkTrick wrote: "should I use RBAC, UBAC, ACL,... and how would I concretely implement them, cleanly?"
I doubt 'cleanly' exists in any medium size application. And really unlikely when it gets bigger.
So just pick one and look at it in detail.
And then really study how to log changes that users make. All users. Log in this case means to a persistent data store. Adds and updates are easy. Deletes are much harder.
|
|
|
|
|
I didn't mean to try to find the answers here on the board, sorry for the misunderstanding. The questions were merely examples. I'm aware that "clean" or "good" are adjectives that are strongly coupled to the use case.
My main goal is to find good literature.
|
|
|
|
|
I understood that.
I was merely pointing out that there is no general answer. Rather you need to start with the domain space rather than than trying to find one solution.
If you don't have an actual domain space, or perhaps even if you do, then just pick one of the solutions and study it.
|
|
|
|
|
Can't tell if you want to secure a door or an app.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
App 
|
|
|
|
|
|
Thank you. The information seems quite specific. Do you also have literature for a more abstract - close to mathematical - level?
|
|
|
|
|
It's a "Pattern"; like doors and windows. An abstraction of a "door" or a "window"? That would be a rectangle; with a hole. Math? Width and height.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Here's the literature I was able to find through libera on IRC. Very helpful to me. Hopefully also helpful for other people reading this..
Online:
Books
In regard of books I found that looking at the references can help. In combination with archive.org's free book library it's possible to skim over books quite quickly
Specific topics
Object Capability System:
Quote: the object graph is the permission graph, and so there are no separate access control checks that you have to make like shown in that slide. An object has authority to call methods on another object if and only if it actually has a reference to that other object.
Links:
- Habitat Chronicles: What Are Capabilities?
- http://erights.org/talks/thesis/markm-thesis.pdf
- Bringing Object-orientation to Security Programming (Mark S. Miller, Google) - YouTube
OT
Here's some basic insight I've gained during looking at various sources.
The basic question you want to get answered is has_access(user, action, resource).
Example: has_access(uid, read, user_list).
You might want to take it even more abstract and say has_access(entity, action, resource), where entity could be a user, a group, an organization or anything else that is able to perform actions in your system. Perhaps even has_access(resource, action, resource) might be an appropriate abstraction.
With a hierarchical permission structure, you would need a recursive check function:
r = resource
loop:
if(r.has_access(user, action)) return true
r = r.parent()
if( r == null) return false
If a resource can be owned by several parents, you would need to account for that with r.parents().
|
|
|
|
|
I use IODA architecture since the very beginning, nearly 10 years now. I develop SW more than 30 years as a profi.
It is the first approach/technique, that offers the option to produce reusable, small classes like "lego building blocks".
It is ortogonal to other best practices like CleanCode, DRY and other.
It has a strong impact on unit testing: Unit testing will be easy.
The reason is simple:
IODA was designed to reduce dependencies between classes to a minimum.
I - Integration - calls all other, but does not contain logic or data
O - Operation - contains logic, just work with data, do not know other operations or integrations
D - Data - holds the data and knows/deals only about itself and its childs. No operations here.
A - API - Application Interfaces - To deal with the environment or to provide general functions like data validation and other stuff
All of these classes are devolped by the project. Standard-Libraries can be found below this code.
If you then divide the Operations in "IO operations" and "other operations" you get the following:
IO_operation "reader" reads "data_ger",
operation "translator" translates "data_ger" to english data "data_eng"
and then the IO operation "View_data" presents it to the user.
And the integrator "TextManager" has a method like
void viewAsEnglish(int textIdGer, string readLang = "ger")
{
var data_ger = reader.Read(textIdGer, readLang);
var data_eng = translator.Translate(data_ger, "eng");
dataViewer.View(data_eng);
}
After longer practice you will automatically think in these four types, when creating a new class.
And yes, it will work fine in real projects.
Now lets start discussion about it, if you want.
**Links**
Detailed description:
https://www.infoq.com/news/2015/05/ioda-architecture/[^]
Bigger sample project (documentation only in german, sorry)
GitHub - jpr65/VersandEtiketten: This is a reference projekt for IODA and also a developer test ticket. Only in german, possible later also in english.[^]
** Images **
IODA - Principle Diagram
IODA - Libraries
modified 1-Dec-23 2:53am.
|
|
|
|
|
I haven't seen this architecture before. Seems interesting but there is one thing I don't get:
Ralf Peine 2023 wrote: I - Integration - calls all other, but does not contain logic or data
O - Operation - contains logic, just work with data, do not know other operations or integrations
If I need to to implement something like "if operation1 fails do operation2", where do I place the logic? I cannot place it in the integration units (cannot contain logic or data) and cannot place it in one of the operations (do not know other operations).
What is the solution?
Mircea
|
|
|
|
|
Yes, that's some important point.
You may add minimal logic into the integrator to set switches for the workflow.
However, the decision why a switch is set should again be made in an operation, if it is not a simple true/false decision.
It is ***allowed*** to put logik in integrators, sometimes it is easy for the moment, but this leads to technical debt and is sometimes difficult to test. Especially while doing hotfixes, you will break the IODA principles, and this is ok, for the moment.
The more you stick to the IODA principles, the more testable and reusable the code will be, that you create.
|
|
|
|
|
Like perhaps everything along these lines it has some utility as long as it is not taken as an absolute.
I certainly do not want to see every single operation in a million line application decomposed like this.
For example I have written reports at various times in various languages and attempting to decompose them often lead to nothing but making it harder to understand the whole.
Then after that one must consider in standard business programming of maintaining an application over years with multiple changes in employees is this likely to be rigorously maintained? If it isn't then doesn't it just devolve into what the original code might have looked like the first place?
|
|
|
|
|
I see ETL: extract, translate, load.
Your sample "integrator" looks more like a "translator".
While my "data" may not have methods, it resides in a repository that does: add, delete, update, query. Data as another object. The methods represent an "API".
And I have "operations" that depend on other operations: "distance" calculators for anything that needs to calculate a distance (in pixels, paces, yards, or feet); or an angle; or "a collision detector" while moving.
I don't disagree with the architecture, but things aren't that clear cut.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
This example and the dokumentation are very small. Please read the detailed description of Ralf Westphal.
"Translation" is what the integrator manages, and "integration" is the type of the class in the meaning of IODA.
Reason for IODA approach is the following
"Functional dependencies are evil!"
Only the integrator classes are allowed to call operation classes.
So, in an ideal world, you have no functional dependencies.
|
|
|
|
|
If you want people to appreciate the benefits of this approach, write an article, hosted here on Code Project showing a non-trivial application created using these techniques. I find myself deeply distrustful of prescriptive ways of working when they are presented as absolutes (e.g. "Functional dependencies are evil!"). No approach is 100% perfect and, generally, there are always be exceptions to the absolutes that are the driving reason for a new way of working.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
