On 1/10/06, Jeff Watkins <[EMAIL PROTECTED]> wrote: > The next step for Identity is to throw out the SQLObject code and use > direct SQL queries, which will dramatically reduce the number of hits > to the database if you belong to more than one group or have more > than one permission. It's currently dreadfully inefficient because it > "thinks in objects" instead of "thinking in queries".
Actually, I wouldn't recommend that approach. It potentially loses database independence (not *too* likely, if you're talking simple selects), but it does open up the possibility of SQL injection attacks. I guess that can be mitigated by using prepared statements. Regardless: I think the best way to handle simple yet common authentication needs is to put the needed data in the cookie. Most apps don't have that many distinct permissions or groups: just hold those in memory. Then put the minimal amount of data into the cookie to reflect who the user is and what they can do. That kind of setup would then require no database hits after authentication. This will undoubtedly not work for all cases, but that's why identity providers are pluggable. (Good use of entry points on the identity provider plugins, by the way...) I'm also much more interested in figuring out if RuleDispatch is a better fit for the authorization rules, because that is a user-facing API change and not just a performance improvement. Performance improvements can happen after 0.9 comes out, but major API changes would ideally happen now. I'm also not super concerned with slimming down the distribution right now. It needs to be possible to turn off functionality that is not needed, but it's not critical for that functionality to be completely separate from the main egg (right now). It's time to rein in changes and start heading toward a release. Kevin
