pinoyprogammer
Techie
Vertical and Horizontal Authentication:
Vertical authentication (VA) is "Who are you?"
Horizontal authentication (HA) is "Is this yours?" or "Does the owner of this allow you to do this to this?*"
*e.g. "Does Anna Lyn Monaco, owner of her [wall], allow you to [view] or [write on] her [wall]
VA checks identity. HA checks particular permission granted by owner of content or user of higher position.
Example: Ms. Christina Moran is only a student of College of C. she wishes to view Anna Lyn's grades. To view it, she must ask Monaco or their Department Head to grant her permission to do so. However, if the Moran has something higher than being a Department Head, such as being a Dean, she can access it without any permission from the aforementioned two.
Let content access be CA: CA = HA || VA.
ADDENDUM: The Dept Head can only access the grades of students under her department. To view grades of other students, she must ask another Dept Heads
[The story aforementioned is hypothetical and does not accurately reflect reality]
Simple steps in an API:
My master (who uses Slim Framework with GUMP and Eloquent) taught me this:
1. Accept the Request
2. Read the Request
3. Validate the Request
4. Extract the validated data
5. Modify the data as input
6. Process or use it with a query
7. Modify the output
8. Prepare the response
9. Respond
- Step 3 includes both vertical and horizontal authorization for a content, and also validation and filtration of input.
- Step 4 is more assignment of $_POST elements to an array
- Step 5 and 7 is the use of Accessors and Mutators such as that of Laravel Eloquent
- Step 6 is doing something with the database, not sure if S6 is applicable for non-persistent things
- Request and Response pertains to HTTP.
My master hardly thinks in OOP and is forced to do so.
Internally Beautiful:
Steve Jobs said that the internal components of a computer must also be aesthetically beautiful. (Is "aesthetically beautiful" redundant?)
Try to apply that heuristics to your software. Beautiful source code is always simple and maintainable.
We do not want a botched code.
Worse than worst:
When building a an information system, assume the worse thing than the worst thing.
According to Nassim Taleb, the Fukushima Reactor was built with a safety system that only mitigates for only up to the last worst earthquake, not for the worse than worst; they should have prepared it for 'the worse earthquake than the worst earthquake' in the relevant history.
Look what happened to Fukushima Reactor. It is worse than Chernobyl's.
In information systems, the worst things you can get are interruption of power during operational hours, massive data loss/wipeout, failure of backup systems.
BOTTOMLINE: Assume what's worse than the worst in history when building a system.
Memory Supplement:
When building a an information system, assume the worse thing than the worst thing.
According to Nassim Taleb, the Fukushima Reactor was built with a safety system that only mitigates for only up to the last worst earthquake, not for the worse than worst; they should have prepared it for 'the worse earthquake than the worst earthquake' in the relevant history.
Look what happened to Fukushima Reactor. It is worse than Chernobyl's.
In information systems, the worst things you can get are interruption of power during operational hours, massive data loss/wipeout, failure of backup systems.
BOTTOMLINE: Assume what's worse than the worst in history when building a system.
Vertical authentication (VA) is "Who are you?"
Horizontal authentication (HA) is "Is this yours?" or "Does the owner of this allow you to do this to this?*"
*e.g. "Does Anna Lyn Monaco, owner of her [wall], allow you to [view] or [write on] her [wall]
VA checks identity. HA checks particular permission granted by owner of content or user of higher position.
Example: Ms. Christina Moran is only a student of College of C. she wishes to view Anna Lyn's grades. To view it, she must ask Monaco or their Department Head to grant her permission to do so. However, if the Moran has something higher than being a Department Head, such as being a Dean, she can access it without any permission from the aforementioned two.
Let content access be CA: CA = HA || VA.
ADDENDUM: The Dept Head can only access the grades of students under her department. To view grades of other students, she must ask another Dept Heads
[The story aforementioned is hypothetical and does not accurately reflect reality]
Simple steps in an API:
My master (who uses Slim Framework with GUMP and Eloquent) taught me this:
1. Accept the Request
2. Read the Request
3. Validate the Request
4. Extract the validated data
5. Modify the data as input
6. Process or use it with a query
7. Modify the output
8. Prepare the response
9. Respond
- Step 3 includes both vertical and horizontal authorization for a content, and also validation and filtration of input.
- Step 4 is more assignment of $_POST elements to an array
- Step 5 and 7 is the use of Accessors and Mutators such as that of Laravel Eloquent
- Step 6 is doing something with the database, not sure if S6 is applicable for non-persistent things
- Request and Response pertains to HTTP.
My master hardly thinks in OOP and is forced to do so.
Internally Beautiful:
Steve Jobs said that the internal components of a computer must also be aesthetically beautiful. (Is "aesthetically beautiful" redundant?)
Try to apply that heuristics to your software. Beautiful source code is always simple and maintainable.
We do not want a botched code.
Worse than worst:
When building a an information system, assume the worse thing than the worst thing.
According to Nassim Taleb, the Fukushima Reactor was built with a safety system that only mitigates for only up to the last worst earthquake, not for the worse than worst; they should have prepared it for 'the worse earthquake than the worst earthquake' in the relevant history.
Look what happened to Fukushima Reactor. It is worse than Chernobyl's.
In information systems, the worst things you can get are interruption of power during operational hours, massive data loss/wipeout, failure of backup systems.
BOTTOMLINE: Assume what's worse than the worst in history when building a system.
Memory Supplement:
When building a an information system, assume the worse thing than the worst thing.
According to Nassim Taleb, the Fukushima Reactor was built with a safety system that only mitigates for only up to the last worst earthquake, not for the worse than worst; they should have prepared it for 'the worse earthquake than the worst earthquake' in the relevant history.
Look what happened to Fukushima Reactor. It is worse than Chernobyl's.
In information systems, the worst things you can get are interruption of power during operational hours, massive data loss/wipeout, failure of backup systems.
BOTTOMLINE: Assume what's worse than the worst in history when building a system.