The place of Authentication in Domain Model
Posted: Fri Oct 14, 2005 3:25 pm
You can skip this - these are my thoughts on the problem
In Front Controller (344) Fowler writes "In a complex Web site there are many similar things you need to do when handling a request. These things include security, internationalization, and providing particular views for certain users." The front controller, however, is for handling all requests to a web site, so stuck wondering where Authentication and Session management fit into the mix.
The most tricky thing is that certain domain objects and almost all templates must be aware who is currently logged in and what rights they have.
Previously, I put a "User" object inside the registry. This contained the username, userid, and userrights. Whenever it was needed, it was called from the Registry, and then the data it contained operated on. The thing was, when you determined the correct user to load, and whether or not the user was authenticated, and whether or not a session should be started, they where all stuck in Transaction style functions. No good for a Domain Model.
So, these are a different kind of object. They're not persisted in the database, and they do things that affect the presentation, but they still contain business logic.
Well, here we go:
Read here
authenticate() - You call this function and everything magically happens (including the user object getting registered)
login() / logout() / session() / remember() - These perform various authentication actions
assertLogin() / assertLogout() ... - This checks the environment and determines whether or not we should perform the actions (sorta like a Front Controller...)
validateLogin() / validateSession() - Determine whether or not the attempt by the user was correct: if not, then don't do the actual action
destroySession() - destroy a stale or logged out session
createSession() - create a new session
cacheSession() - send http headers to override PHP's no cache to "private"
How should I factor these functions into their own domain object classes?
In Front Controller (344) Fowler writes "In a complex Web site there are many similar things you need to do when handling a request. These things include security, internationalization, and providing particular views for certain users." The front controller, however, is for handling all requests to a web site, so stuck wondering where Authentication and Session management fit into the mix.
The most tricky thing is that certain domain objects and almost all templates must be aware who is currently logged in and what rights they have.
Previously, I put a "User" object inside the registry. This contained the username, userid, and userrights. Whenever it was needed, it was called from the Registry, and then the data it contained operated on. The thing was, when you determined the correct user to load, and whether or not the user was authenticated, and whether or not a session should be started, they where all stuck in Transaction style functions. No good for a Domain Model.
So, these are a different kind of object. They're not persisted in the database, and they do things that affect the presentation, but they still contain business logic.
Well, here we go:
Read here
authenticate() - You call this function and everything magically happens (including the user object getting registered)
login() / logout() / session() / remember() - These perform various authentication actions
assertLogin() / assertLogout() ... - This checks the environment and determines whether or not we should perform the actions (sorta like a Front Controller...)
validateLogin() / validateSession() - Determine whether or not the attempt by the user was correct: if not, then don't do the actual action
destroySession() - destroy a stale or logged out session
createSession() - create a new session
cacheSession() - send http headers to override PHP's no cache to "private"
How should I factor these functions into their own domain object classes?