Some of the classes declared above are a little bewildering to me; it appears as if we are already introducing potential flaws, despite getting to a stage of refactoring. My implementation of this tends to sway from RBACS specification, which is why I have been hesitant to post and write up any code. Ideally, I would love to see a UML (Sequence & Class) diagram, of the current design.
All data should be independent of the format in the Data Access Logic Components. Admittedly this is not in the scope of the tutorial, however in order to demonstrate a functional Object Orientated Design (OOD), I believe this is a fundamental Component, i.e. alternating between XPATH and SQL.
I did mention that we should have a glossary of definitions/acronyms, which would have resolved the matter of ‘Principal’. Even an explanation of the patterns and why they are being used, would be advantageous as you can see where they are applicable and the problem they solve, which will also aid in the refactoring with there necessity.
Generally, when implementing Object Orientated Design (OOD), naming conventions are derived on business entities, as to why we have ‘PearAuthorizationEdit’ is beyond me. Whilst PHP does not implement namespaces, I still find that there is not a necessity to prefix classes with a company or brand name; even common method names such ‘initialize’ are being exchanged for ambiguous names such as ‘setUp’ or ‘can’.
One aspect I touched on briefly was placing the logic into the database using Stored Procedures (SP) or the database itself. IMO, I find that is essentially the best method as it allows for flexibility on the actual returned data and the DB administrator can handle the data to be represented by the principal.
- What if were using this with a web service, do we continually negotiate passing a username and password, or do you pass a token?
- The strange thing I see is that you seem to assume the protocol is automatically HTTP.
If I were to implement the current design in an e-commerce site
, where would I be able to implement Auditing
, and Transactions
(State that Transactions
are required in the current model)? I find that matching security to the role of an e-commerce site
sets initial standards for your own implementation. Another scenario, what if we have a table of employees and another for consumers, does the current design
allow for this? Generally, I have found WAP authentication
simply matches the mobile number
to a user
, so I doubt there is a need for ‘WapSignIn’
, I realise this is insecure; however it all depends on the context
of its use.
), I owe you a little apology as previously, I misinterpreted your code (Late Night Coding
). Glad you like your code being unethical though. J