On 1/19/06, Tom Locke <[EMAIL PROTECTED]> wrote: > 1. The SQLObject provider is too heavy handed with my database. I know > I can change the table names, but some things, like an alternate-id > field called userId are assumed.
It would be nice to be able to use the SQLObject provider with any classes... you just tell it which class/fields to use. Being able to swap that one piece of the provider while keeping the rest would be nice. It *is* quite valuable for identity to have a built in model that a user can run with immediately. > 2. Identity management, or at least the SQLObject provider, seems to > now be tied up with "visit tracking". I haven't dug deeply yet, but I > don't think I need such a thing. I haven't taken a hard look at that code either. But, I'm not sure if there's a cost incurred specifically for having "visit tracking". > 3. Providing a custom IdentityProvider is now done via the plugin > mechanism. This seems to make it a lot more complicated to drop in a > custom class. Maybe it's just a case of lacking documentation. I think it is. It's not very complicated... The only thing it requires that you might not have otherwise (initially at least) is a setup.py script. Make your provider class in whatever module you want, and then in setup.py tell setuptools where to find that. (Take a look at the setup.py in the TurboGears project and you'll see that it's quite easy to tell setuptools where to find things that satisfy entry_points.) > The upshot is I've decided to back out all the identity stuff in my app > and just code my own stuff from scratch. My guess is that's more of a reaction to lack of docs than identity being truly incapable of stretching to your needs. > It would be nice to see a simpler public API that just handled the > basics such as the identity cookie, login-form etc. and have the more > sophisticated stuff built on top of that. That way I can pick my own > balance between framework-support vs. design-freedom. I don't know how many people have tried to write identity providers. It may be the case that you can leverage the code in the existing API just overriding the parts you need. > Thanks for the great work - please just consider this a bit of > user-feedback. Feedback is always good, and identity is one of those areas where i know people's requirements will vary dramatically. Striking the balance between extensibility and built-in functionality is the tricky bit. Kevin
