Re: [Catalyst] Debian recommendation

2009-10-27 Thread Buchan Milne
On Friday, 16 October 2009 13:20:12 Octavian Râşniţă wrote:
 Hi,

 I've seen a recommendation on this list for Debian for running perl apps,
 and recently I started to use this distro.

 I've seen that I can install perl modules very hard under Debian if I use
 the CPAN shell.
 For example if I run

 $ cpan
 cpan install Class::MOP

 it gives an Unknown error and it doesn't want to install and the same
 with Catalyst::Runtime.

 But if I do then

 cpan look ModuleName
 $ perl Makefile.PL
 $ make
 $ make test
 $make install

 I can install the modules without problem (usually).
 However, I need to manually install each dependency.

 I've seen this strange thing under 2 Debian systems so I think it is not a
 Debian bug.

 Does this happen to you? If yes, how do you solve it?

I note that both Mandriva (which has had it for a few years) and Fedora now 
have working Catalyst packages. Mandriva also has a CPANPLUS backend (which is 
being actively used for packaging new CPAN modules, however other tools - 
written in perl - are used for updating all packages).

I am prepared to package other Catalyst modules for Mandriva on request.

Regards,
Buchan


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Catalyst::Authentication::Credential::LDAP

2008-08-07 Thread Buchan Milne
On Thursday 24 July 2008 04:38:30 Matt S Trout wrote:
 On Wed, Jul 23, 2008 at 08:29:42AM -0500, Peter Karman wrote:
  On 07/22/2008 10:37 PM, Matt S Trout wrote:
   On Wed, Jun 25, 2008 at 11:27:13AM -0700, Bruce J Keeler wrote:
   Also, somewhat apropos, I have a
   C::A::{Store,Credential}::ActiveDirectory  that I based on the LDAP
   stuff.  The LDAP modules didn't work for me because they want to bind
   anonymously and retrieve the crypted password, whereas AD just wants
   to authenticate with a bind.
  
   So, having established this isn't true.
  
   Could you perhaps instead post a message asking why your config of the
   main LDAP store didn't work so we can figure out what configuration
   problem you had and document it?
 
  likely he is missing a 'binddn' and 'bindpw' config setting. The initial
  bind() will try anonymously if those are not set. What I usually do for
  Active Directory is create a user specifically for use with Net::LDAP
  (and by extension, C::A::Store::LDAP), and then do all my initial binds
  with that user/pass.

 Hmmm. Should there be an alternative option where (if the user DN is
 deterministic from the username) it skips the first part and just
 tries the bind with $generated_dn and $supplied_password (where
 $generated_dn is the result of a subref/sprintf pattern/whatever
 supplied in config) ?

A directory isn't an RDBMS; one should never assume that the naming attribute 
is the same attribute used for the username. One should avoid generating DNs 
in anything but code that initially provisions the entry.

Regards,
Buchan

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] Model::LDAP vs Authentication::Credential::LDAP

2008-08-07 Thread Buchan Milne
We are using Catalyst for an internal infrastructure management application. 
Some of the data we want to manage lives in LDAP, and we already use LDAP for 
authentication and roles in our application.

However, I would like to have the LDAP server do it's job in authorizing 
access to some of this data, and I would also like to have LDAP-side auditing 
(as direct LDAP access has to be available, doing it application-side would 
miss any direct modifications).

So, I would prefer to have my Model::LDAP models (re-)bind as the 
authenticated user.

So far I have stored the cleartext password in the session, after encrypting 
it with the session key. Now, I would like to find some way of providing the 
credentials to the model.

I wrote a connection_class for my models, but it seems that the 
connection_class doesn't have access to the context, so I can't retrieve $c-
user-ldap_entry-dn or $c-sessionid().

Is there really no way to do this at present (without dumping Model::LDAP and 
doing everything via Net::LDAP directly)?

Regards,
Buchan

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] Password policy support for Catalyst::Authentication::Store::LDAP

2008-06-20 Thread Buchan Milne
In our internal management web app (which has only been feasible due to 
Catalyst), we authenticate against our OpenLDAP (2.3) infrastructure.

Due to various security requirements (SAOX etc.), we are required to have 
password expiration etc. So, we implemented password policies a while back 
using OpenLDAP's slapo-ppolicy overlay 
(http://www.openldap.org/software/man.cgi?query=slapo-ppolicysektion=5apropos=0manpath=OpenLDAP+2.3-Release)

Net::LDAP recently added support for the Password Policy control, so at least 
this is now feasible (without hacking Net::LDAP, which is where I got stuck 
on the previous attempt).

I think I may be able to provide a patch for Authentication::Store::LDAP, 
however, the first problem is that Catalyst::Authentication (like many other 
authentication frameworks) assumes the result of an authentication will 
always only be a boolean, and thus doesn't make provision for situations such 
as:
-The account is locked out (the password may have been correct, but the user 
can't authenticate)
-The password was reset and needs to be changed (so, authenticate them but 
allow for a means to send them to a password changing facility)
-The password will expire soon
etc.

I wouldn't like to try and propose a solution for Catalyst::Authentication 
(yet), but I can try and provide input on any proposed solution.

Regards,
Buchan

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Password policy support for Catalyst::Authentication::Store::LDAP

2008-06-20 Thread Buchan Milne
On Friday 20 June 2008 12:20:49 Gavin Henry wrote:
 2008/6/20 Buchan Milne [EMAIL PROTECTED]:
  In our internal management web app (which has only been feasible due to
  Catalyst), we authenticate against our OpenLDAP (2.3) infrastructure.
 
  Due to various security requirements (SAOX etc.), we are required to have
  password expiration etc. So, we implemented password policies a while
  back using OpenLDAP's slapo-ppolicy overlay
  (http://www.openldap.org/software/man.cgi?query=slapo-ppolicysektion=5a
 propos=0manpath=OpenLDAP+2.3-Release)
 
  Net::LDAP recently added support for the Password Policy control, so at
  least this is now feasible (without hacking Net::LDAP, which is where I
  got stuck on the previous attempt).
 
  I think I may be able to provide a patch for Authentication::Store::LDAP,
  however, the first problem is that Catalyst::Authentication (like many
  other authentication frameworks) assumes the result of an authentication
  will always only be a boolean, and thus doesn't make provision for
  situations such as:
  -The account is locked out (the password may have been correct, but the
  user can't authenticate)
  -The password was reset and needs to be changed (so, authenticate them
  but allow for a means to send them to a password changing facility)
  -The password will expire soon
  etc.
 
  I wouldn't like to try and propose a solution for
  Catalyst::Authentication (yet), but I can try and provide input on any
  proposed solution.

 Can't you still return a true/false and then provide/use an error
 method which will then contain the reason for failure, which include
 the response from ppolicy?

In theory, yes (from Store::LDAP), but I want to get something back from 
login(), which just checks the boolean it gets back from the store (I think, 
don't have anything in front of me now).

Regards,
Buchan

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/