Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I can understand why you are getting confused. I was/am still a bit confused. So, unfortunately I cannot answer your question directly. But, one thing i am doing in order to clarify all this stuff in my head is to think in terms of 'domain objects' as opposed to database records. </p> <p>My tactic to deal with this issue is to create my own Auth Adaptor that is passed a 'User Base Object' along with the user credentials. My 'User Base' is kind of like a repository of users.</p> <p>So the Zend Auth is left being 'an interface' to other Zend Components whilst i still have a bit more control over my system for storing and accessing 'Users'. My User_Base class could be a wrapper around a Zend Db tbl or even just have some hard code in it that i can use for testing.</p> <p>So in general-</p> <ul> <li><p>design your own model of a 'user'</p></li> <li><p>design your own Auth Adaptor - starting with the minimum interface required as outlined here: <a href="http://framework.zend.com/manual/en/zend.auth.html" rel="noreferrer">http://framework.zend.com/manual/en/zend.auth.html</a></p></li> <li><p>and just keep it all simple and go slowly as you learn more about it.</p></li> </ul> <p>well that's what i am gonna do anyway.</p> <p>I aint even gonna bother with Zend ACL just yet til i have Auth clear in my head.</p> <hr> <p>I'm revamping a legacy site and converting it to Zend MVC</p> <p>These are some things (perhaps unconventional) that I have had to get to grips with for my 'model' to work. :</p> <ul> <li>an app may be used by users from multiple 'user bases' - openID, legacy users table, new users table, fleeting guests, etc</li> <li>a guest's identity might just be a hash created when they first arrive</li> <li>whereas, a legacy user's identity might be represented by an id in the legacy users table</li> <li>users and user_accounts are separate things. don't try to mix them into one concept cos it could get complicated.</li> <li>there may be many different types of accounts in the system. I.e. Buyers Accounts versus Sellers accounts. Readers_Account versus Writers_Account </li> <li>accounts 'have' users - 'primary account holder', 'admin super user', etc</li> <li>the relationship between the users and an account are represented by, say, 'account_users' (a local subset of all users in all user bases)</li> <li>roles arew attached to account_users (the users of that particular account).(As opposed to roles floating around )</li> <li>don't be afraid to have more than one Zend application on a server to represent a website - e.g admin app, members app, front end app.</li> <li>don't be afraid to let these apps use model objects stored in say 'shared models' folder, with the only model code that directly relates to the individual app sitting in the /application/models/foomodel folders.</li> <li>each app might have its own custom Auth adaptor </li> <li>an admin auth adaptor may only allow users from the 'admin users table' whereas a front end app's Auth adaptor might be able to authenticate users from the guest userbase, staff, or members user base.</li> <li>might be a speical case where front-end apps session is cleared and replced by member session upon elevation when member logs in.</li> <li>one user object per app per webclient at anyone time (as opposed to trying to reference a person with a guest user AND a member user - that's too complicated)</li> <li>one session per user per app (namespaced to avoid conflicts with other apps that they may be logged into on that domain) - (as opposed to trying to simultaneously refer to 'the person using it' with a guest session AND a member session. again, that's too complicated)</li> </ul> <p>ok i am starting to ramble....but you get the idea. Don't let the Zend_Auth+Zend Db tutorials that you see sway your own model. they are just simplified examples.</p> <p>nuff said </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload