|

»

»

Heads... major refactor of user management just merged

View: New views

5 Messages — Rating Filter: Alert me

	Heads... major refactor of user management just merged by Tim Almdal :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Heads up, I just merged a major refactor of the user management into the master. It should work w/o running the upgrader, but to be safe, run the upgrader to insure that you are at gallery version 16. This refactor creates the IdentityProvider interface and an identity helper identity.php to allow access to user and groups. Identity providers can be changed from the Admin/Identity Manager screen. Modules that provide a IdentityProvider implementation are locked on the Module Administration page. IdentityProviders parameters are specified in an identity.php configuration file residing in the module/config directory. In the gallery3-contrib repository under modules/ldap there is a read-only LDAP IdentityProvider. One of the advantages of this approach, is that a module that interfaces directly to a WordPress or Drupal user administration could be written and then Gallery3 would share that installation's users and groups. No user/password synchronization issues as there is only one user administration system. As usually any problem can be tracked via our trac system: https://sourceforge.net/apps/trac/gallery/ Tim Website: http://www.timalmdal.com ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ]
	Re: Heads... major refactor of user management just merged by Andy Staudacher-3 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Tue, Oct 27, 2009 at 5:25 AM, Tim Almdal <tnalmdal@...> wrote: Heads up, I just merged a major refactor of the user management into the master. It should work w/o running the upgrader, but to be safe, run the upgrader to insure that you are at gallery version 16. Great! Some questions: :) This refactor creates the IdentityProvider interface and an identity helper identity.php to allow access to user and groups. Identity providers can be changed from the Admin/Identity Manager screen. Modules that provide a IdentityProvider implementation are locked on the Module Administration page. IdentityProviders parameters are specified in an identity.php configuration file residing in the module/config directory. In the gallery3-contrib repository under modules/ldap there is a read-only LDAP IdentityProvider. Read-only meaning that no users can be created (=only existing LDAP users can use G3) and that no user / group attributes (=name, password, etc.) can be changed? At any given time, can more than 1 identity provider be enabled? I.e. does it try to look up a user name sequentially first in provider 1, then in provider 2, etc? Use case: OpenID. Or would an OpenID module be implemented differently, i.e. by having an OpenID module interact with the one and only active identity provider module? If only one provider is active at any give time, does that mean that we automatically disable the "create user" UI in G3's admin area when the provider is read-only? One of the advantages of this approach, is that a module that interfaces directly to a WordPress or Drupal user administration could be written and then Gallery3 would share that installation's users and groups. No user/password synchronization issues as there is only one user administration system. Is there already some minimal documentation? E.g. I wonder what kind of user->id and group->id stability requirements we have. I.e. User ID must be stable. A provider returning a user object must guarantee that a user's ID never changes for the lifetime of the Gallery 3 installation. The (integer) user ID is the one stable identifier that is allowed to be used anywhere in the G3 database (e.g. in the notifications table). What about the stability requirements for group->id? Do we have the same requirements there too? Also, we need a proof of concept implementation of the identity provider interface with Drupal or WordPress to ensure that the API is a good fit for the applications most users will integrate with. And it should be a read/write implementation to show that this works fine as well. Thanks, - Andy As usually any problem can be tracked via our trac system: https://sourceforge.net/apps/trac/gallery/ Tim Website: http://www.timalmdal.com ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ] ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ]
	Re: Heads... major refactor of user management just merged by Bharat Mediratta :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Andy Staudacher wrote: > Read-only meaning that no users can be created (=only existing LDAP > users can use G3) and that no user / group attributes (=name, password, > etc.) can be changed? > > At any given time, can more than 1 identity provider be enabled? I.e. > does it try to look up a user name sequentially first in provider 1, > then in provider 2, etc? > Use case: OpenID. Or would an OpenID module be implemented differently, > i.e. by having an OpenID module interact with the one and only active > identity provider module? > > If only one provider is active at any give time, does that mean that we > automatically disable the "create user" UI in G3's admin area when the > provider is read-only? The impetus for this change was that folks internal at Google want to use Gallery 3 and have it authenticate against the Google internal LDAP. From that perspective, it doesn't make much sense to have multiple providers. If there's a strong use case for multiple providers, we should identify a use case and prioritize it based on the number of users who we expect to use it. For now, this is first implementation flushes out many of the issues we knew to be latent with our original authentication approach. > One of the advantages of this approach, is that a module that > interfaces directly to a WordPress or Drupal user administration > could be written and then Gallery3 would share that installation's > users and groups. No user/password synchronization issues as there > is only one user administration system. > > > Is there already some minimal documentation? > > E.g. I wonder what kind of user->id and group->id stability requirements > we have. I.e. User ID must be stable. A provider returning a user object > must guarantee that a user's ID never changes for the lifetime of the > Gallery 3 installation. The (integer) user ID is the one stable > identifier that is allowed to be used anywhere in the G3 database (e.g. > in the notifications table). > What about the stability requirements for group->id? Do we have the same > requirements there too? Id stability is implicit here, as it is in almost all other systems. I can't think of a system offhand which allows you to change your underlying ids after creation. I'm not overly concerned with this issue. > Also, we need a proof of concept implementation of the identity provider > interface with Drupal or WordPress to ensure that the API is a good fit > for the applications most users will integrate with. And it should be a > read/write implementation to show that this works fine as well. I agree that we should provide Drupal and Wordpress integrations. I disagree that we need a read/write implementation-- I can't think of any scenarios where I'd want to use the Gallery 3 interfaces to do user administration for WP/Drupal. Can you tell me what scenarios you had in mind? -Bharat ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ]
	Re: Heads... major refactor of user management just merged by Andy Staudacher-3 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Tue, Oct 27, 2009 at 1:31 PM, Bharat Mediratta <bharat@...> wrote: Andy Staudacher wrote: Read-only meaning that no users can be created (=only existing LDAP users can use G3) and that no user / group attributes (=name, password, etc.) can be changed? At any given time, can more than 1 identity provider be enabled? I.e. does it try to look up a user name sequentially first in provider 1, then in provider 2, etc? Use case: OpenID. Or would an OpenID module be implemented differently, i.e. by having an OpenID module interact with the one and only active identity provider module? If only one provider is active at any give time, does that mean that we automatically disable the "create user" UI in G3's admin area when the provider is read-only? The impetus for this change was that folks internal at Google want to use Gallery 3 and have it authenticate against the Google internal LDAP. From that perspective, it doesn't make much sense to have multiple providers. If there's a strong use case for multiple providers, we should identify a use case and prioritize it based on the number of users who we expect to use it. For now, this is first implementation flushes out many of the issues we knew to be latent with our original authentication approach. One of the advantages of this approach, is that a module that interfaces directly to a WordPress or Drupal user administration could be written and then Gallery3 would share that installation's users and groups. No user/password synchronization issues as there is only one user administration system. Is there already some minimal documentation? E.g. I wonder what kind of user->id and group->id stability requirements we have. I.e. User ID must be stable. A provider returning a user object must guarantee that a user's ID never changes for the lifetime of the Gallery 3 installation. The (integer) user ID is the one stable identifier that is allowed to be used anywhere in the G3 database (e.g. in the notifications table). What about the stability requirements for group->id? Do we have the same requirements there too? Id stability is implicit here, as it is in almost all other systems. I can't think of a system offhand which allows you to change your underlying ids after creation. I'm not overly concerned with this issue. Works for me. Also, we need a proof of concept implementation of the identity provider interface with Drupal or WordPress to ensure that the API is a good fit for the applications most users will integrate with. And it should be a read/write implementation to show that this works fine as well. I agree that we should provide Drupal and Wordpress integrations. I disagree that we need a read/write implementation-- I can't think of any scenarios where I'd want to use the Gallery 3 interfaces to do user administration for WP/Drupal. Can you tell me what scenarios you had in mind? A read-only (=in G3-lingo) interface is fine IMO. With G2 we got away with a read-only integration as well. If you want updates (e.g. changed user attributes) from Gallery to the other application, you could write a Gallery module and hook into user update events. What I'm concerned about is that we have an interface that offers a mode (read-write) that isn't actually used by anything, but G3 internals. To ensure that this mode actually makes sense, I'd like to see an external use for it. But maybe that's just it. Maybe it's not intended for external use, and we'll see if it makes any sense for external use in the rare event that someone ever tries to use read-write from another application. But as mentioned in my initial reply: Does that imply that we disable all identity-related write operations when the active identity provider is read-only? On the API-level and in the UI? Another API-related question: What about user:: vs. identity::? I see some redundancy, e.g. user::active() is a copy of identity::active_user(). Other methods in IdentityProvider are mostly delegates to user_core. Why didn't we include active() in that list of delegates as well? Can we at least get rid of the code duplication? Should we have a code audit test to verify that user:: isn't called directly anywhere in module / theme code? Thanks, - Andy -Bharat ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ]
	Re: Heads... major refactor of user management just merged by Tim Almdal :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message All the G3 internals use the identity helper. There is a unit test to insure that there are no direct calls to the database against the user and group tables. What about user:: vs. identity::? The user module is the default IdentityProvider implementation. And some of the code you saw was a merge gone bad... the duplication has been removed from the user helper. Andy Staudacher wrote: On Tue, Oct 27, 2009 at 1:31 PM, Bharat Mediratta <bharat@...> wrote: Andy Staudacher wrote: Read-only meaning that no users can be created (=only existing LDAP users can use G3) and that no user / group attributes (=name, password, etc.) can be changed? At any given time, can more than 1 identity provider be enabled? I.e. does it try to look up a user name sequentially first in provider 1, then in provider 2, etc? Use case: OpenID. Or would an OpenID module be implemented differently, i.e. by having an OpenID module interact with the one and only active identity provider module? If only one provider is active at any give time, does that mean that we automatically disable the "create user" UI in G3's admin area when the provider is read-only? The impetus for this change was that folks internal at Google want to use Gallery 3 and have it authenticate against the Google internal LDAP. From that perspective, it doesn't make much sense to have multiple providers. If there's a strong use case for multiple providers, we should identify a use case and prioritize it based on the number of users who we expect to use it. For now, this is first implementation flushes out many of the issues we knew to be latent with our original authentication approach. One of the advantages of this approach, is that a module that interfaces directly to a WordPress or Drupal user administration could be written and then Gallery3 would share that installation's users and groups. No user/password synchronization issues as there is only one user administration system. Is there already some minimal documentation? E.g. I wonder what kind of user->id and group->id stability requirements we have. I.e. User ID must be stable. A provider returning a user object must guarantee that a user's ID never changes for the lifetime of the Gallery 3 installation. The (integer) user ID is the one stable identifier that is allowed to be used anywhere in the G3 database (e.g. in the notifications table). What about the stability requirements for group->id? Do we have the same requirements there too? Id stability is implicit here, as it is in almost all other systems. I can't think of a system offhand which allows you to change your underlying ids after creation. I'm not overly concerned with this issue. Works for me. Also, we need a proof of concept implementation of the identity provider interface with Drupal or WordPress to ensure that the API is a good fit for the applications most users will integrate with. And it should be a read/write implementation to show that this works fine as well. I agree that we should provide Drupal and Wordpress integrations. I disagree that we need a read/write implementation-- I can't think of any scenarios where I'd want to use the Gallery 3 interfaces to do user administration for WP/Drupal. Can you tell me what scenarios you had in mind? A read-only (=in G3-lingo) interface is fine IMO. With G2 we got away with a read-only integration as well. If you want updates (e.g. changed user attributes) from Gallery to the other application, you could write a Gallery module and hook into user update events. What I'm concerned about is that we have an interface that offers a mode (read-write) that isn't actually used by anything, but G3 internals. To ensure that this mode actually makes sense, I'd like to see an external use for it. But maybe that's just it. Maybe it's not intended for external use, and we'll see if it makes any sense for external use in the rare event that someone ever tries to use read-write from another application. But as mentioned in my initial reply: Does that imply that we disable all identity-related write operations when the active identity provider is read-only? On the API-level and in the UI? Another API-related question: What about user:: vs. identity::? I see some redundancy, e.g. user::active() is a copy of identity::active_user(). Other methods in IdentityProvider are mostly delegates to user_core. Why didn't we include active() in that list of delegates as well? Can we at least get rid of the code duplication? Should we have a code audit test to verify that user:: isn't called directly anywhere in module / theme code? Thanks, - Andy -Bharat No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.36/2465 - Release Date: 10/28/09 09:34:00 ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ]