Nabble - gallery-devel

Re: I wonder who got facebook.com/gallery2

2009-11-05T20:37:29Z

Donald Webster wrote:
> http://www.facebook.com/gallery2
>
> Anyone recognize that person? I miss-typed /gallery3 and was like "omg?"

No idea!

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
__[ 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 ]

I wonder who got facebook.com/gallery2

2009-11-05T15:30:23Z

http://www.facebook.com/gallery2

Anyone recognize that person? I miss-typed /gallery3 and was like "omg?"

AIM: fryfrog
WWW: http://www.fryfrog.com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
__[ 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 ]

User Registration module

2009-11-03T17:06:52Z

Just added this module to -contrib repository.

The codex page is at: http://codex.gallery2.org/Gallery3:Modules:register

Tim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
__[ 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 ]

[Fwd: PHP 5.3.1RC2 Testing]

2009-11-03T11:18:16Z

FYI.

-------- Original Message --------
Subject: PHP 5.3.1RC2 Testing
Date: Tue, 03 Nov 2009 20:15:49 +0100
From: Johannes Schlüter <johannes@...>
Organization: php.net
To: PHP QA List <php-qa@...>

Hello!

You are receiving this email because your project has been selected to
take part in a new effort by the PHP QA Team to make sure that your
project still works with PHP versions to-be-released. With this we
hope to make sure that you are either aware of things that might
break, or to make sure we don't introduce any strange regressions.
With this effort we hope to build a better relationship between the
PHP Team and the major projects.

If you do not want to receive these heads-up emails, please reply to
me personally and I will remove you from the list; but, we hope that
you want to actively help us making PHP a better and more stable tool.

The third release candidate of PHP 5.3.1 was just released and can
be downloaded from http://downloads.php.net/johannes/, the win32
binaries are available at http://windows.php.net/qa/. Please try this
release candidate against your code and let us know if any regressions
should you find any. This RC is needed as a few crash bugs were found
and fixed. Depending on the feedback the goal is to release 5.3.1 using
the same code base soon, so timely testing would be extremely helpful.

In case you think that other projects should also receive this kinds
of emails, please let me know privately, and I will add them to the
list of projects to contact.

Best Regards,

Johannes Schlüter
5.3 Release Master

------------------------------------------------------------------------------
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: Identity Management vs. Users/Groups

2009-11-01T09:52:34Z

Dave Moore wrote:
> A bit late to the game...
> I echo Kevin, we can't confuse the users more with different names.
> Going for the 80% rule: what the heck is LDAP? Does it fit?

http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol

Most companies have an internal LDAP directory which we can use for
authentication. With the changes that Tim has made, we can now plug in
an ldap module to take advantage of that. The support for pluggable
authentication is in core, but the actual ldap module is off in the
contrib dir.

-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: Identity Management vs. Users/Groups

2009-10-30T23:54:44Z

A bit late to the game...
I echo Kevin, we can't confuse the users more with different names.
Going for the 80% rule: what the heck is LDAP? Does it fit?

Dave

At 09:53 AM 10/30/2009, Kevin Nehls wrote:

>On Fri, Oct 30, 2009 at 8:45 AM, Bharat Mediratta
><<mailto:bharat@...>bharat@...> wrote:
>Additionally, the names "Extensions" and "Plugins" are new. We call
>them "modules" both in the code and in the UI currently, so I'd expect
>that name to recur in the UI as well. I'm not averse to renaming
>modules to plugins or extensions. It would not be a cheap change, but
>it's doable and if you want to do that let's do it before 3.0. But I'd
>hate to see us confuse the issue with yet another name.
>
>
>Purely from a support standpoint; having the terms modules and
>plugins inter-mixed in G2 has been quite confusing to a fair number
>of people. It's really hard for non-native English speakers when we
>call something a module, they are looking for that term and can't find it.
>
>If we do make the change we need to make the change 100%., For
>example, if they are called 'plugins' the directory needs to be
>called plugins. It cannot just be a change in the UI as we did in
>G2. All documentation needs to be changed as well.
>
>Just my $0.02
>
>Kevin
>------------------------------------------------------------------------------
>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: Identity Management vs. Users/Groups

2009-10-30T13:59:49Z

I'll try to make those changes this weekend

----- Original Message -----
From: Chad Kieffer <chad@...>
Date: Friday, October 30, 2009 1:39 pm
Subject: Re: [Gallery-devel] Identity Management vs. Users/Groups
To: Tim Almdal <tnalmdal@...>
Cc: Bharat Mediratta <bharat@...>, Gallery development discussion list <gallery-devel@...>

> Works for me too.
>
> On Oct 30, 2009, at 10:47 AM, Tim Almdal <tnalmdal@...> wrote:
>
> > Works for me:
> >
> > Here's what I propose:
> > 1) Put "Identity providers" should go under Settings since
> the
> > provider you use is a core setting.
> >
> > 2) If there's no User/Group administration, that menu option
> should
> > go away. So it won't exist for LDAP, but it'll exist for core.
> >
> > ----- Original Message -----
> > From: Bharat Mediratta <bharat@...>
> > Date: Friday, October 30, 2009 8:46 am
> > Subject: Re: [Gallery-devel] Identity Management vs. Users/Groups
> > To: Chad Kieffer <chad@...>
> > Cc: Gallery development discussion list <gallery-
> devel@...
> > >
> >
> > > Chad Kieffer wrote:
> > > > On Oct 29, 2009, at 11:08 PM, Tim Almdal wrote:
> > > >
> > > >> Keep in mind, that if you install a identity provider
> that is
> > > not
> > > >> writable (i.e. ldap), then you won't see the User/Group sub
> > > menu, as
> > > >> there is no user management capability. So the high
> > > level menu needs
> > > >> to reflect that it might have nothing to with users and groups.
> > > >>
> > > >> I was going to to put the self registration module admin
> > > under there,
> > > >> but as an alternative:
> > > >> 1) Put the User/Group back as a high level menu (this is
> > > where it use
> > > >> to be)
> > > >> 2) Create a high level menu item ("Extensions" or "Plugins")
> > > I'm sure
> > > >> there is a better name. Under this menu we put modules and
> > > identity
> > > >> provider as they both are related to extending gallery.
> > > >> 3) User registration administration will go under settings.
> > > >
> > > > This sounds like a better way to go. Extensions seems to be
> > > the more
> > > > accurate label, but I wouldn't violently object to Plugins.
> > >
> > > This approach worries me a bit because if you're using LDAP then
> > > it
> > > always seems like you're using some funky UI to do normal
> > > stuff. Ie, I
> > > don't think that Gallery 3 ui should present itself as a core
> > > with a
> > > bunch of extensions. It should be a seamless whole.
> > >
> > > Additionally, the names "Extensions" and "Plugins" are
> > > new. We call
> > > them "modules" both in the code and in the UI currently, so I'd
> > > expect
> > > that name to recur in the UI as well. I'm not averse to
> > > renaming
> > > modules to plugins or extensions. It would not be a cheap
> > > change, but
> > > it's doable and if you want to do that let's do it before
> > > 3.0. But I'd
> > > hate to see us confuse the issue with yet another name.
> > >
> > > Here's what I propose:
> > > 1) Put "Identity providers" should go under Settings since the
> > > provider
> > > you use is a core setting.
> > >
> > > 2) If there's no User/Group administration, that menu option
> > > should go
> > > away. So it won't exist for LDAP, but it'll exist for core.
> > >
> > > -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 ]
> > >
> >
> > Website: http://www.timalmdal.com
> >
>

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: Identity Management vs. Users/Groups

2009-10-30T13:39:16Z

Works for me too.

On Oct 30, 2009, at 10:47 AM, Tim Almdal <tnalmdal@...> wrote:

> Works for me:
>
> Here's what I propose:
> 1) Put "Identity providers" should go under Settings since the
> provider you use is a core setting.
>
> 2) If there's no User/Group administration, that menu option should
> go away. So it won't exist for LDAP, but it'll exist for core.
>
> ----- Original Message -----
> From: Bharat Mediratta <bharat@...>
> Date: Friday, October 30, 2009 8:46 am
> Subject: Re: [Gallery-devel] Identity Management vs. Users/Groups
> To: Chad Kieffer <chad@...>
> Cc: Gallery development discussion list <gallery-devel@...
> >
>
> > Chad Kieffer wrote:
> > > On Oct 29, 2009, at 11:08 PM, Tim Almdal wrote:
> > >
> > >> Keep in mind, that if you install a identity provider that is
> > not
> > >> writable (i.e. ldap), then you won't see the User/Group sub
> > menu, as
> > >> there is no user management capability. So the high
> > level menu needs
> > >> to reflect that it might have nothing to with users and groups.
> > >>
> > >> I was going to to put the self registration module admin
> > under there,
> > >> but as an alternative:
> > >> 1) Put the User/Group back as a high level menu (this is
> > where it use
> > >> to be)
> > >> 2) Create a high level menu item ("Extensions" or "Plugins")
> > I'm sure
> > >> there is a better name. Under this menu we put modules and
> > identity
> > >> provider as they both are related to extending gallery.
> > >> 3) User registration administration will go under settings.
> > >
> > > This sounds like a better way to go. Extensions seems to be
> > the more
> > > accurate label, but I wouldn't violently object to Plugins.
> >
> > This approach worries me a bit because if you're using LDAP then
> > it
> > always seems like you're using some funky UI to do normal
> > stuff. Ie, I
> > don't think that Gallery 3 ui should present itself as a core
> > with a
> > bunch of extensions. It should be a seamless whole.
> >
> > Additionally, the names "Extensions" and "Plugins" are
> > new. We call
> > them "modules" both in the code and in the UI currently, so I'd
> > expect
> > that name to recur in the UI as well. I'm not averse to
> > renaming
> > modules to plugins or extensions. It would not be a cheap
> > change, but
> > it's doable and if you want to do that let's do it before
> > 3.0. But I'd
> > hate to see us confuse the issue with yet another name.
> >
> > Here's what I propose:
> > 1) Put "Identity providers" should go under Settings since the
> > provider
> > you use is a core setting.
> >
> > 2) If there's no User/Group administration, that menu option
> > should go
> > away. So it won't exist for LDAP, but it'll exist for core.
> >
> > -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 ]
> >
>
> Website: http://www.timalmdal.com
>

Re: Identity Management vs. Users/Groups

2009-10-30T09:47:43Z

Works for me:

Here's what I propose:

1) Put "Identity providers" should go under Settings since the provider you use is a core setting.

2) If there's no User/Group administration, that menu option should go away. So it won't exist for LDAP, but it'll exist for core.

----- Original Message -----
From: Bharat Mediratta <bharat@...>
Date: Friday, October 30, 2009 8:46 am
Subject: Re: [Gallery-devel] Identity Management vs. Users/Groups
To: Chad Kieffer <chad@...>
Cc: Gallery development discussion list <gallery-devel@...>

> Chad Kieffer wrote:
> > On Oct 29, 2009, at 11:08 PM, Tim Almdal wrote:
> >
> >> Keep in mind, that if you install a identity provider that is
> not
> >> writable (i.e. ldap), then you won't see the User/Group sub
> menu, as
> >> there is no user management capability. So the high
> level menu needs
> >> to reflect that it might have nothing to with users and groups.
> >>
> >> I was going to to put the self registration module admin
> under there,
> >> but as an alternative:
> >> 1) Put the User/Group back as a high level menu (this is
> where it use
> >> to be)
> >> 2) Create a high level menu item ("Extensions" or "Plugins")
> I'm sure
> >> there is a better name. Under this menu we put modules and
> identity
> >> provider as they both are related to extending gallery.
> >> 3) User registration administration will go under settings.
> >
> > This sounds like a better way to go. Extensions seems to be
> the more
> > accurate label, but I wouldn't violently object to Plugins.
>
> This approach worries me a bit because if you're using LDAP then
> it
> always seems like you're using some funky UI to do normal
> stuff. Ie, I
> don't think that Gallery 3 ui should present itself as a core
> with a
> bunch of extensions. It should be a seamless whole.
>
> Additionally, the names "Extensions" and "Plugins" are
> new. We call
> them "modules" both in the code and in the UI currently, so I'd
> expect
> that name to recur in the UI as well. I'm not averse to
> renaming
> modules to plugins or extensions. It would not be a cheap
> change, but
> it's doable and if you want to do that let's do it before
> 3.0. But I'd
> hate to see us confuse the issue with yet another name.
>
> Here's what I propose:
> 1) Put "Identity providers" should go under Settings since the
> provider
> you use is a core setting.
>
> 2) If there's no User/Group administration, that menu option
> should go
> away. So it won't exist for LDAP, but it'll exist for core.
>
> -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 ]
>

Website: http://www.timalmdal.com

Re: Identity Management vs. Users/Groups

2009-10-30T08:53:49Z

On Fri, Oct 30, 2009 at 8:45 AM, Bharat Mediratta <bharat@...> wrote:

Additionally, the names "Extensions" and "Plugins" are new. We call
them "modules" both in the code and in the UI currently, so I'd expect
that name to recur in the UI as well. I'm not averse to renaming
modules to plugins or extensions. It would not be a cheap change, but
it's doable and if you want to do that let's do it before 3.0. But I'd
hate to see us confuse the issue with yet another name.

Purely from a support standpoint; having the terms modules and plugins inter-mixed in G2 has been quite confusing to a fair number of people. It's really hard for non-native English speakers when we call something a module, they are looking for that term and can't find it.

If we do make the change we need to make the change 100%., For example, if they are called 'plugins' the directory needs to be called plugins. It cannot just be a change in the UI as we did in G2. All documentation needs to be changed as well.

Just my $0.02

Kevin

------------------------------------------------------------------------------
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: Identity Management vs. Users/Groups

2009-10-30T08:45:18Z

Chad Kieffer wrote:

> On Oct 29, 2009, at 11:08 PM, Tim Almdal wrote:
>
>> Keep in mind, that if you install a identity provider that is not
>> writable (i.e. ldap), then you won't see the User/Group sub menu, as
>> there is no user management capability. So the high level menu needs
>> to reflect that it might have nothing to with users and groups.
>>
>> I was going to to put the self registration module admin under there,
>> but as an alternative:
>> 1) Put the User/Group back as a high level menu (this is where it use
>> to be)
>> 2) Create a high level menu item ("Extensions" or "Plugins") I'm sure
>> there is a better name. Under this menu we put modules and identity
>> provider as they both are related to extending gallery.
>> 3) User registration administration will go under settings.
>
> This sounds like a better way to go. Extensions seems to be the more
> accurate label, but I wouldn't violently object to Plugins.

This approach worries me a bit because if you're using LDAP then it
always seems like you're using some funky UI to do normal stuff. Ie, I
don't think that Gallery 3 ui should present itself as a core with a
bunch of extensions. It should be a seamless whole.

Additionally, the names "Extensions" and "Plugins" are new. We call
them "modules" both in the code and in the UI currently, so I'd expect
that name to recur in the UI as well. I'm not averse to renaming
modules to plugins or extensions. It would not be a cheap change, but
it's doable and if you want to do that let's do it before 3.0. But I'd
hate to see us confuse the issue with yet another name.

Here's what I propose:
1) Put "Identity providers" should go under Settings since the provider
you use is a core setting.

2) If there's no User/Group administration, that menu option should go
away. So it won't exist for LDAP, but it'll exist for core.

-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: Identity Management vs. Users/Groups

2009-10-30T06:40:14Z

In the case of using the LDAP provider, would the restored Users/Groups admin be replaced by the LDAP provider admin UI? That seems usable and intuitive to me.

In the case of the LDAP provider there is no admin ui. The parameters are set via a config file and user/group management are set external to Gallery3

Why couldn't 'User registration' go under the restored Users/Groups?

Doesn't really matter, but I was thinking, that way, User/Group takes you directly to the User/Group admin screen no sub menu but doesn't make sense. What might be a better solution is we change the menu compression code so if there is only 1 sub-menu, it gets promoted to the higher level.

The other thought, is if we are creating a new "high level" menu called extensions, would it make sense to to move the theme choice menu item. This way all the extension related stuff is under one high level menu.

----- Original Message -----
From: Chad Kieffer <chad@...>
Date: Thursday, October 29, 2009 10:32 pm
Subject: Re: [Gallery-devel] Identity Management vs. Users/Groups
To: Gallery development discussion list <gallery-devel@...>

> On Oct 29, 2009, at 11:08 PM, Tim Almdal wrote:
>
> > Keep in mind, that if you install a identity provider that is
> not
> > writable (i.e. ldap), then you won't see the User/Group sub
> menu, as
> > there is no user management capability. So the high
> level menu
> > needs to reflect that it might have nothing to with users and
> groups.>
> > I was going to to put the self registration module admin
> under
> > there, but as an alternative:
> > 1) Put the User/Group back as a high level menu (this is where
> it
> > use to be)
> > 2) Create a high level menu item ("Extensions" or "Plugins")
> I'm
> > sure there is a better name. Under this menu we put modules
> and
> > identity provider as they both are related to extending gallery.
> > 3) User registration administration will go under settings.
>
> This sounds like a better way to go. Extensions seems to be the
> more
> accurate label, but I wouldn't violently object to Plugins.
>
> In the case of using the LDAP provider, would the restored
> Users/
> Groups admin be replaced by the LDAP provider admin UI? That
> seems
> usable and intuitive to me.
>
> Why couldn't 'User registration' go under the restored Users/Groups?
>
>
>
> > Chad Kieffer wrote:
> >>
> >> I know this has been discussed in previous threads,
> unfortunately I
> >> don't have a copy of the thread any longer so I'm just going
> to post
> >> this.
> >>
> >> I think the main "Identity Management" label in the admin
> menu should
> >> be reverted to "Users/Groups" or something similar. While the label
> >> now needs to represent a broader topic, Identity Management
> seems too
> >> broad and less recognizable. Users/Groups seems broad
> enough and
> >> perhaps it's okay to repeat it in the submenu.
> >>
> >> Just my $0.02.
> >>
> >> - Chad
> >>
> >> --------------------------------------------------------------
> ----------------
> >> 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 ]
> >>
> >>
> >> No virus found in this incoming message.
> >> Checked by AVG - www.avg.com
> >> Version: 8.5.423 / Virus Database: 270.14.39/2468 - Release
> Date:
> >> 10/29/09 19:49:00
> >>
> >>
>
>

Website: http://www.timalmdal.com

Re: Identity Management vs. Users/Groups

2009-10-29T22:31:39Z

On Oct 29, 2009, at 11:08 PM, Tim Almdal wrote:

Keep in mind, that if you install a identity provider that is not writable (i.e. ldap), then you won't see the User/Group sub menu, as there is no user management capability. So the high level menu needs to reflect that it might have nothing to with users and groups.

I was going to to put the self registration module admin under there, but as an alternative:
1) Put the User/Group back as a high level menu (this is where it use to be)
2) Create a high level menu item ("Extensions" or "Plugins") I'm sure there is a better name. Under this menu we put modules and identity provider as they both are related to extending gallery.
3) User registration administration will go under settings.

This sounds like a better way to go. Extensions seems to be the more accurate label, but I wouldn't violently object to Plugins.

In the case of using the LDAP provider, would the restored Users/Groups admin be replaced by the LDAP provider admin UI? That seems usable and intuitive to me.

Why couldn't 'User registration' go under the restored Users/Groups?

Chad Kieffer wrote:

I know this has been discussed in previous threads, unfortunately I  
don't have a copy of the thread any longer so I'm just going to post  
this.

I think the main "Identity Management" label in the admin menu should  
be reverted to "Users/Groups" or something similar. While the label  
now needs to represent a broader topic, Identity Management seems too  
broad and less recognizable.  Users/Groups seems broad enough and  
perhaps it's okay to repeat it in the submenu.

Just my $0.02.

- Chad

------------------------------------------------------------------------------
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 ]



No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.423 / Virus Database: 270.14.39/2468 - Release Date: 10/29/09 19:49:00

Re: Identity Management vs. Users/Groups

2009-10-29T22:08:22Z

Keep in mind, that if you install a identity provider that is not writable (i.e. ldap), then you won't see the User/Group sub menu, as there is no user management capability. So the high level menu needs to reflect that it might have nothing to with users and groups.

I was going to to put the self registration module admin under there, but as an alternative:
1) Put the User/Group back as a high level menu (this is where it use to be)
2) Create a high level menu item ("Extensions" or "Plugins") I'm sure there is a better name. Under this menu we put modules and identity provider as they both are related to extending gallery.
3) User registration administration will go under settings.

Tim

Chad Kieffer wrote:

I know this has been discussed in previous threads, unfortunately I  
don't have a copy of the thread any longer so I'm just going to post  
this.

I think the main "Identity Management" label in the admin menu should  
be reverted to "Users/Groups" or something similar. While the label  
now needs to represent a broader topic, Identity Management seems too  
broad and less recognizable.  Users/Groups seems broad enough and  
perhaps it's okay to repeat it in the submenu.

Just my $0.02.

- Chad

------------------------------------------------------------------------------
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 ]



No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.423 / Virus Database: 270.14.39/2468 - Release Date: 10/29/09 19:49:00

Identity Management vs. Users/Groups

2009-10-29T21:17:59Z

I know this has been discussed in previous threads, unfortunately I
don't have a copy of the thread any longer so I'm just going to post
this.

I think the main "Identity Management" label in the admin menu should
be reverted to "Users/Groups" or something similar. While the label
now needs to represent a broader topic, Identity Management seems too
broad and less recognizable. Users/Groups seems broad enough and
perhaps it's okay to repeat it in the submenu.

Just my $0.02.

- Chad

------------------------------------------------------------------------------
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

2009-10-28T08:57:50Z

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

  

Re: Heads... major refactor of user management just merged

2009-10-27T21:24:53Z

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

Re: Heads... major refactor of user management just merged

2009-10-27T16:31:18Z

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

2009-10-27T13:48:05Z

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 ]

Heads... major refactor of user management just merged

2009-10-27T08:25:56Z

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

Re: Ticket #588: Enforce at least 5 characterminimum for password

2009-10-26T17:29:14Z

Password rules rules would be a nice contributed module :)

On Oct 26, 2009, at 3:18 PM, Kevin Nehls wrote:

I thought we only decided to do this for the admin account when initially installing G3. Though that may be what we're already talking about or maybe that's how I recall it...

Kevin

On Mon, Oct 26, 2009 at 2:12 PM, Alec Myers <alec@...> wrote:
Personally I think even a minimum length is annoying. There are times when
you may (legitimately) not want any password at all.

----- Original Message -----
From: "Jake Conner" <jake@...>
To: "Bharat Mediratta" <bharat@...>
Cc: <gallery-devel@...>
Sent: Monday, October 26, 2009 8:10 PM
Subject: Re: [Gallery-devel] Ticket #588: Enforce at least 5
characterminimum for password

>I agree with Bharat - these rules are annoying. Minimum length maybe,
> but the content requirements are *really* annoying.
>
> Jake
>
> On Oct 26, 2009, at 2:55 PM, Bharat Mediratta wrote:
>
>> Tim Almdal wrote:
>>> Hi Andy, do you mind if I take and complete ticket #588. I found this
>>> regex, that forces a a input password to be at least 5 letter which
>>> must
>>> contain at least one Upper case letter, one lower case letter and
>>> one digit.
>>>
>>> #(?=[-_a-zA-Z0-9]*?[A-Z])(?=[-_a-zA-Z0-9]*?[a-z])(?=[-_a-zA-Z0-9]*?
>>> [0-9])[-_a-zA-Z0-9]{5,}#
>>
>> Ye gods. Do we really have to do this? Websites that force me to use
>> "strong" passwords drive me batty.
>>
>> -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 ]
>
>
> ------------------------------------------------------------------------------
> 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 ]

------------------------------------------------------------------------------
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: Ticket #588: Enforce at least 5 characterminimum for password

2009-10-26T14:37:16Z

On Mon October 26 2009 17:12:59 Alec Myers wrote:
> Personally I think even a minimum length is annoying. There are times when
> you may (legitimately) not want any password at all.

+1 for no rule enforcement at all - password strength is the user's business.

I do think strength-o-meter display is a mildly good idea but not worth a huge
effort.

------------------------------------------------------------------------------
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: Ticket #588: Enforce at least 5 characterminimum for password

2009-10-26T14:18:15Z

I thought we only decided to do this for the admin account when initially installing G3. Though that may be what we're already talking about or maybe that's how I recall it...

Kevin

On Mon, Oct 26, 2009 at 2:12 PM, Alec Myers <alec@...> wrote:

Personally I think even a minimum length is annoying. There are times when
you may (legitimately) not want any password at all.

----- Original Message -----
From: "Jake Conner" <jake@...>
To: "Bharat Mediratta" <bharat@...>
Cc: <gallery-devel@...>
Sent: Monday, October 26, 2009 8:10 PM
Subject: Re: [Gallery-devel] Ticket #588: Enforce at least 5
characterminimum for password

>I agree with Bharat - these rules are annoying. Minimum length maybe,
> but the content requirements are *really* annoying.
>
> Jake
>
> On Oct 26, 2009, at 2:55 PM, Bharat Mediratta wrote:
>
>> Tim Almdal wrote:
>>> Hi Andy, do you mind if I take and complete ticket #588. I found this
>>> regex, that forces a a input password to be at least 5 letter which
>>> must
>>> contain at least one Upper case letter, one lower case letter and
>>> one digit.
>>>
>>> #(?=[-_a-zA-Z0-9]*?[A-Z])(?=[-_a-zA-Z0-9]*?[a-z])(?=[-_a-zA-Z0-9]*?
>>> [0-9])[-_a-zA-Z0-9]{5,}#
>>
>> Ye gods. Do we really have to do this? Websites that force me to use
>> "strong" passwords drive me batty.
>>
>> -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 ]
>
>
> ------------------------------------------------------------------------------
> 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: Ticket #588: Enforce at least 5 characterminimum for password

2009-10-26T14:12:59Z

Personally I think even a minimum length is annoying. There are times when
you may (legitimately) not want any password at all.

----- Original Message -----
From: "Jake Conner" <jake@...>
To: "Bharat Mediratta" <bharat@...>
Cc: <gallery-devel@...>
Sent: Monday, October 26, 2009 8:10 PM
Subject: Re: [Gallery-devel] Ticket #588: Enforce at least 5
characterminimum for password

>I agree with Bharat - these rules are annoying. Minimum length maybe,
> but the content requirements are *really* annoying.
>
> Jake
>
> On Oct 26, 2009, at 2:55 PM, Bharat Mediratta wrote:
>
>> Tim Almdal wrote:
>>> Hi Andy, do you mind if I take and complete ticket #588. I found this
>>> regex, that forces a a input password to be at least 5 letter which
>>> must
>>> contain at least one Upper case letter, one lower case letter and
>>> one digit.
>>>
>>> #(?=[-_a-zA-Z0-9]*?[A-Z])(?=[-_a-zA-Z0-9]*?[a-z])(?=[-_a-zA-Z0-9]*?
>>> [0-9])[-_a-zA-Z0-9]{5,}#
>>
>> Ye gods. Do we really have to do this? Websites that force me to use
>> "strong" passwords drive me batty.
>>
>> -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 ]
>
>
> ------------------------------------------------------------------------------
> 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: Ticket #588: Enforce at least 5 character minimum for password

2009-10-26T14:05:49Z

i was planning on adding a estimated strength indicator (jquery implementation) but, having it match is as good thing as well

So min length is all i'll implement :-)

----- Original Message -----
From: Andy Staudacher <andy.st@...>
Date: Monday, October 26, 2009 2:00 pm
Subject: Re: [Gallery-devel] Ticket #588: Enforce at least 5 character minimum for password
To: Chad Kieffer <chad@...>
Cc: Bharat Mediratta <bharat@...>, Tim Almdal <tnalmdal@...>, "gallery-devel@..." <gallery-devel@...>

> +1 for enforcing a minimum length of 5 chars only.
> (
> As for password strength: If we ever do that, it should just be a
> recommendation, and not a requirement. I like the sign-up forms where
> there's an indicator next to the first password field to show
> the estimated
> strength of the password, and an indicator right next to the 2nd
> passwordfield showing whether it matches the first one or not.
> All in JavaScript,
> without server round trips.
> )
>
> - Andy
>
> On Mon, Oct 26, 2009 at 10:53 AM, Chad Kieffer
> <chad@...> wrote:
>
> > On Oct 26, 2009, at 1:55 PM, Bharat Mediratta
> <bharat@...> wrote:
> >
> > Tim Almdal wrote:
> >>
> >>> Hi Andy, do you mind if I take and complete ticket #588. I
> found this
> >>> regex, that forces a a input password to be at least 5
> letter which must
> >>> contain at least one Upper case letter, one lower case
> letter and one
> >>> digit.
> >>>
> >>>
> >>> #(?=[-_a-zA-Z0-9]*?[A-Z])(?=[-_a-zA-Z0-9]*?[a-z])(?=[-_a-zA-
> Z0-9]*?[0-9])[-_a-zA-Z0-9]{5,}#
> >>>
> >>
> >> Ye gods. Do we really have to do this? Websites
> that force me to use
> >> "strong" passwords drive me batty.
> >>
> >> -Bharat
> >>
> >
> > I think we agreed on just enforcing a minimum length, didn't we?
> >
> > - Chad
> >
> >
> >
> >>
> >> --------------------------------------------------------------
> ----------------
> >> 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 ]
> >>
> >
>

Website: http://www.timalmdal.com

Re: Ticket #588: Enforce at least 5 character minimum for password

2009-10-26T14:00:27Z

+1 for enforcing a minimum length of 5 chars only.

(

As for password strength: If we ever do that, it should just be a recommendation, and not a requirement. I like the sign-up forms where there's an indicator next to the first password field to show the estimated strength of the password, and an indicator right next to the 2nd password field showing whether it matches the first one or not. All in JavaScript, without server round trips.

)

- Andy

On Mon, Oct 26, 2009 at 10:53 AM, Chad Kieffer <chad@...> wrote:

On Oct 26, 2009, at 1:55 PM, Bharat Mediratta <bharat@...> wrote:

Tim Almdal wrote:

Hi Andy, do you mind if I take and complete ticket #588. I found this
regex, that forces a a input password to be at least 5 letter which must
contain at least one Upper case letter, one lower case letter and one digit.

#(?=[-_a-zA-Z0-9]*?[A-Z])(?=[-_a-zA-Z0-9]*?[a-z])(?=[-_a-zA-Z0-9]*?[0-9])[-_a-zA-Z0-9]{5,}#

Ye gods. Do we really have to do this? Websites that force me to use
"strong" passwords drive me batty.

-Bharat

I think we agreed on just enforcing a minimum length, didn't we?

- Chad

------------------------------------------------------------------------------
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: Ticket #588: Enforce at least 5 character minimum for password

2009-10-26T13:53:17Z

On Oct 26, 2009, at 1:55 PM, Bharat Mediratta <bharat@...>
wrote:

I think we agreed on just enforcing a minimum length, didn't we?

- Chad

>
> ---
> ---
> ---
> ---------------------------------------------------------------------
> 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: Ticket #588: Enforce at least 5 character minimum for password

2009-10-26T13:50:14Z

Do we already let users know if their password is weak, reasonable or
strong? I would not appose an *option* to allow enforcement of strong
passwords for the admin, but forcing strong passwords would probably
not appeal to most users.

AIM: fryfrog
WWW: http://www.fryfrog.com

On Mon, Oct 26, 2009 at 1:22 PM, Tim Almdal <tnalmdal@...> wrote:

> Don't matter to me. You suggested minimum 5 chars, Andy's stretch goal was
> require some variety. If we are not going to do it, lets close it and get
> it off the list.
> Tim
>
> ----- Original Message -----
> From: Bharat Mediratta <bharat@...>
> Date: Monday, October 26, 2009 12:56 pm
> Subject: Re: [Gallery-devel] Ticket #588: Enforce at least 5 character
> minimum for password
> To: Tim Almdal <tnalmdal@...>
> Cc: "Staudacher, Andy" <andy.st@...>,
> "gallery-devel@..." <gallery-devel@...>
>
>> Tim Almdal wrote:
>> > Hi Andy, do you mind if I take and complete ticket #588. I
>> found this
>> > regex, that forces a a input password to be at least 5 letter
>> which must
>> > contain at least one Upper case letter, one lower case letter
>> and one digit.
>> >
>> > #(?=[-_a-zA-Z0-9]*?[A-Z])(?=[-_a-zA-Z0-9]*?[a-z])(?=[-_a-zA-Z0-
>> 9]*?[0-9])[-_a-zA-Z0-9]{5,}#
>>
>> Ye gods. Do we really have to do this? Websites that
>> force me to use
>> "strong" passwords drive me batty.
>>
>> -Bharat
>>
>
> 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: Ticket #588: Enforce at least 5 character minimum for password

2009-10-26T13:22:38Z

Don't matter to me. You suggested minimum 5 chars, Andy's stretch goal was require some variety. If we are not going to do it, lets close it and get it off the list.

Tim

----- Original Message -----
From: Bharat Mediratta <bharat@...>
Date: Monday, October 26, 2009 12:56 pm
Subject: Re: [Gallery-devel] Ticket #588: Enforce at least 5 character minimum for password
To: Tim Almdal <tnalmdal@...>
Cc: "Staudacher, Andy" <andy.st@...>, "gallery-devel@..." <gallery-devel@...>

> Tim Almdal wrote:
> > Hi Andy, do you mind if I take and complete ticket #588. I
> found this
> > regex, that forces a a input password to be at least 5 letter
> which must
> > contain at least one Upper case letter, one lower case letter
> and one digit.
> >
> > #(?=[-_a-zA-Z0-9]*?[A-Z])(?=[-_a-zA-Z0-9]*?[a-z])(?=[-_a-zA-Z0-
> 9]*?[0-9])[-_a-zA-Z0-9]{5,}#
>
> Ye gods. Do we really have to do this? Websites that
> force me to use
> "strong" passwords drive me batty.
>
> -Bharat
>

Website: http://www.timalmdal.com

Re: Ticket #588: Enforce at least 5 character minimum for password

2009-10-26T13:10:19Z

I agree with Bharat - these rules are annoying. Minimum length maybe,
but the content requirements are *really* annoying.

Jake

On Oct 26, 2009, at 2:55 PM, Bharat Mediratta wrote:

> Tim Almdal wrote:
>> Hi Andy, do you mind if I take and complete ticket #588. I found this
>> regex, that forces a a input password to be at least 5 letter which
>> must
>> contain at least one Upper case letter, one lower case letter and
>> one digit.
>>
>> #(?=[-_a-zA-Z0-9]*?[A-Z])(?=[-_a-zA-Z0-9]*?[a-z])(?=[-_a-zA-Z0-9]*?
>> [0-9])[-_a-zA-Z0-9]{5,}#
>
> Ye gods. Do we really have to do this? Websites that force me to use
> "strong" passwords drive me batty.
>
> -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: Ticket #588: Enforce at least 5 character minimum for password

2009-10-26T12:55:59Z

Tim Almdal wrote:
> Hi Andy, do you mind if I take and complete ticket #588. I found this
> regex, that forces a a input password to be at least 5 letter which must
> contain at least one Upper case letter, one lower case letter and one digit.
>
> #(?=[-_a-zA-Z0-9]*?[A-Z])(?=[-_a-zA-Z0-9]*?[a-z])(?=[-_a-zA-Z0-9]*?[0-9])[-_a-zA-Z0-9]{5,}#

Ye gods. Do we really have to do this? Websites that force me to use
"strong" passwords drive me batty.

-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 ]

Ticket #588: Enforce at least 5 character minimum for password

2009-10-26T12:38:49Z

Hi Andy, do you mind if I take and complete ticket #588. I found this regex, that forces a a input password to be at least 5 letter which must contain at least one Upper case letter, one lower case letter and one digit.

#(?=[-_a-zA-Z0-9]*?[A-Z])(?=[-_a-zA-Z0-9]*?[a-z])(?=[-_a-zA-Z0-9]*?[0-9])[-_a-zA-Z0-9]{5,}#

Tim
Website: http://www.timalmdal.com

Re: gallery-contrib on sourceforge: files invisible?

2009-10-24T19:04:30Z

Ah ok - thanks.

----- Original Message -----
From: "Chris Kelly" <ckdake@...>
To: "Alec Myers" <alec@...>
Cc: <gallery-devel@...>
Sent: Sunday, October 25, 2009 1:24 AM
Subject: Re: [Gallery-devel] gallery-contrib on sourceforge: files
invisible?

> "Files" is for things that have been "released" through the sourceforge
> release manager. We don't release files there, so thats just going to be
> empty.
>
> -Chris
>
> On Oct 24, 2009, at 9:00 PM, Alec Myers wrote:
>
>> Is there something 'up' with gallery-contrib project on sourceforge? If
>> you
>> browse the files
>> https://sourceforge.net/projects/gallery-contrib/files/
>>
>> then you don't see the /trunk/ directory at all, and there's no
>> visibility
>> of any of the modules. You have to go to "develop" and then "SVN browse
>> code" to see the tree.
>>
>> Is this expected? Feels very counterintuitive to me. Is a new thing, or
>> have
>> I been asleep?
>>
>> Thanks all
>>
>> -Alec
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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: gallery-contrib on sourceforge: files invisible?

2009-10-24T18:24:06Z

"Files" is for things that have been "released" through the
sourceforge release manager. We don't release files there, so thats
just going to be empty.

-Chris

On Oct 24, 2009, at 9:00 PM, Alec Myers wrote:

> Is there something 'up' with gallery-contrib project on sourceforge?
> If you
> browse the files
> https://sourceforge.net/projects/gallery-contrib/files/
>
> then you don't see the /trunk/ directory at all, and there's no
> visibility
> of any of the modules. You have to go to "develop" and then "SVN
> browse
> code" to see the tree.
>
> Is this expected? Feels very counterintuitive to me. Is a new thing,
> or have
> I been asleep?
>
> Thanks all
>
> -Alec
>
>
>
> ------------------------------------------------------------------------------
> 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 ]

gallery-contrib on sourceforge: files invisible?

2009-10-24T18:00:56Z

Is there something 'up' with gallery-contrib project on sourceforge? If you
browse the files
https://sourceforge.net/projects/gallery-contrib/files/

then you don't see the /trunk/ directory at all, and there's no visibility
of any of the modules. You have to go to "develop" and then "SVN browse
code" to see the tree.

Is this expected? Feels very counterintuitive to me. Is a new thing, or have
I been asleep?

Thanks all

-Alec

------------------------------------------------------------------------------
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 ]