Re: [Catalyst] Catalyst and Taint?
On Tue, Jul 22, 2008 at 8:30 PM, Matt S Trout [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 10:08:11PM -0700, Chris Weyl wrote: Hey all -- A google of catalyst taint turns up this message: http://lists.scsys.co.uk/pipermail/catalyst/2005-December/004007.html It doesn't look like there has been a release of Module::Pluggable::Fast since then. Does anyone know where this patch lurks? :-) (Assuming, of course, that this is still the right path to work down.) We don't even use Module::Pluggable::Fast anymore. Catalyst went back to a refactored plain Module::Pluggable instead for 5.70+. Hopefully the patch claco sent back then got applied somewhere in the meantime. Before caring about a three year old message, first check the module it refers to is even involved anymore :) I'll keep that in mind :) According to CPAN, Module::Pluggable::Fast hasn't been updated since 16 Dec 2005, about 2 weeks before that email was sent If it was applied, I rather suspect it wasn't there. (and since you're the only person since to mention taint mode, I don't think most people care about it - I certainly don't see it being very useful for Catalyst code, maybe you could enlighten us as to why you do?) Taint mode would seem to be a good way to help protect against accidental exposures, especially in internet-facing apps. I was curious to see what would happen if I tried running an instance with -T... Admittedly, I'm more of a newbie Catalyst user than internals person by any measure, but is there something about Catalyst that renders taint unnecessary, or moot? ...or obsolete? ...or more of a pain than it's worth? -Chris -- Chris Weyl Ex astris, scientia ___ 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
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.
'binddn' and 'bindpw' are fully documented; if the docs can be improved, please
send a patch.
--
Peter Karman . [EMAIL PROTECTED] . http://peknet.com/
___
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
Peter Karman [EMAIL PROTECTED] wrote on 07/23/2008 08:29:42 AM:
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.
'binddn' and 'bindpw' are fully documented; if the docs can be
improved, please send a patch.
Peter,
From my perspective they are documented too well -- it took me a bit
to figure out how to do _anon_ binds. =)
-Wade
___
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
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.
'binddn' and 'bindpw' are fully documented; if the docs can be improved, please
send a patch.
I seem to recall trying that, but it's been long enough that I don't
recall the details of what went wrong.
The other reason I went off in my own direction is that I wanted to pull
role information from AD groups, and I couldn't see any way of making
that work with the stock ::LDAP modules. I will try to make some time
to revisit this stuff soon.
Bruce
___
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] Preventing simultaneous logins
I'm using Cat with a pretty standard configuration of :
Catalyst::Plugin::Authentication
Catalyst::Plugin::Session
Catalyst::Plugin::Session::State::Cookie
Catalyst::Plugin::Session::Store::FastMmap
to handle login and session management. My login code looks like this:
my $u = $params-{username};
if ($c-authenticate( { username = $u,
password = $params-{'password'}
} )){
my $user = $c-user;
$user-last_login(DateTime-now);
$user-update();
$c-response-redirect( $forward, 301);
} else {
# login failed
$c-stash-{login_failed} = 1;
}
What I'd like to do is check if this user is already logged in at some
other computer, and deny access if so. I guess that means :
1. checking whether there is an existing session associated this username
2. Being sure that the associated session is cleared when the user hits 'logout'
I did a quick search and didn't get anything on the list - any quick
clues about the easy way to do this, before I start digging into the
guts of the plugins to see how?
many thanks
Daniel
--
There's an infinite supply of time, we just don't have it all yet.
___
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
Bruce J Keeler [EMAIL PROTECTED] wrote on 07/23/2008 02:16:16 PM:
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.
'binddn' and 'bindpw' are fully documented; if the docs can be
improved, please send a patch.
I seem to recall trying that, but it's been long enough that I don't
recall the details of what went wrong.
The other reason I went off in my own direction is that I wanted to pull
role information from AD groups, and I couldn't see any way of making
that work with the stock ::LDAP modules. I will try to make some time
to revisit this stuff soon.
http://search.cpan.org/~karman/Catalyst-Authentication-Store-LDAP-0.1002
/lib/Catalyst/Authentication/Store/LDAP.pm#use_roles
___
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] Preventing simultaneous logins
* On Wed, Jul 23 2008, Daniel McBrearty wrote: What I'd like to do is check if this user is already logged in at some other computer, and deny access if so. I would probably store sessions in the database, and then store the session ID in the user table at login time (current_session) or something. Then when they log in again, you can join in the session row, check the expiration time in that row, and then allow/deny the login. You can also use that opportunity to delete the session from the database so that the other machine no longer has a valid session. I don't think the file-based session stores provide this much flexibility, but you could probably hack something similar if you really needed to. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ 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] Preventing simultaneous logins
On Wed, Jul 23, 2008 at 1:12 PM, Jonathan Rockway [EMAIL PROTECTED] wrote: * On Wed, Jul 23 2008, Daniel McBrearty wrote: What I'd like to do is check if this user is already logged in at some other computer, and deny access if so. I would probably store sessions in the database, and then store the session ID in the user table at login time (current_session) or something. Then when they log in again, you can join in the session row, check the expiration time in that row, and then allow/deny the login. You can also use that opportunity to delete the session from the database so that the other machine no longer has a valid session. I don't think the file-based session stores provide this much flexibility, but you could probably hack something similar if you really needed to. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ I agree this is the way to go, and it would be pretty easy to write a Credential that inherits from Password that does the additional check before succeeding. That way your controllers stay thin, and this feature is more easily tuned and configured. -J ___ 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] Preventing simultaneous logins
Daniel McBrearty [EMAIL PROTECTED] wrote on 07/23/2008 02:47:57
PM:
I'm using Cat with a pretty standard configuration of :
Catalyst::Plugin::Authentication
Catalyst::Plugin::Session
Catalyst::Plugin::Session::State::Cookie
Catalyst::Plugin::Session::Store::FastMmap
to handle login and session management. My login code looks like this:
my $u = $params-{username};
if ($c-authenticate( { username = $u,
password = $params-{'password'}
} )){
my $user = $c-user;
$user-last_login(DateTime-now);
$user-update();
$c-response-redirect( $forward, 301);
} else {
# login failed
$c-stash-{login_failed} = 1;
}
What I'd like to do is check if this user is already logged in at some
other computer, and deny access if so. I guess that means :
1. checking whether there is an existing session associated this username
2. Being sure that the associated session is cleared when the user
hits 'logout'
I did a quick search and didn't get anything on the list - any quick
clues about the easy way to do this, before I start digging into the
guts of the plugins to see how?
many thanks
Daniel,
This is actually a pretty hard problem -- there is no right answer.
What if the user clears her browser state while using the site? Leaves the
computer and browser on at work then tries to log in at home on a different
computer? I think you can gain most of the lockdown of 1 session per user
if you just track user activity over a X minute period. for instance every
time a user hits your app add a record that is attached to the user account
in the db (src ip, session number, other relevant info). Then do (either
inline or if it is too costly, via cron) a check on those entries that
looks for multiple IP/Sessions or whatever you define as multiple users
(given that http is stateless there really is no _safe_ definition). If
that process detects usage over your threshold, disable (temp or
permanent) the account. The same process can clean up entries that are
outside of the time window that you want to look at.
___
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] Preventing simultaneous logins
On Wed, Jul 23, 2008 at 09:47:57PM +0200, Daniel McBrearty wrote: And what happens if they never hit log out? Or if their browser crashes and then they try and log in again? If you really need this feature, try it the other way around: if someone logs in then you invalidate their first session. I used to work for a company that never deleted sessions - long history, and dumb assumptions about the reasons for keeping the records around... The suggestion mentioned above, deleting the first invalid session, doesn't solve the problem because it assumes EVERYONE will log back in. An expiration date should be set on any session. There are a number of options you can use to extend this expiration date, but the question posed is what to do with sessions where someone doesn't logout. Simple, each night you have a job run that does some database maintenance - simply delete the expired session records. ___ 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] Preventing simultaneous logins
On 23 Jul 2008, at 21:20, [EMAIL PROTECTED] wrote: This is actually a pretty hard problem -- there is no right answer. What if the user clears her browser state while using the site? Leaves the computer and browser on at work then tries to log in at home on a different computer? I agree that it's a hard problem if you do it the original way round that was suggested. However all apps which do that (Facebook as an example) - logging into a new session kills your old one, and this is pretty easy to do (given that you force users to have a cookie and etc). I think you can gain most of the lockdown of 1 session per user if you just track user activity over a X minute period. for instance every time a user hits your app add a record that is attached to the user account in the db (src ip, session number, other relevant info). Then do (either inline or if it is too costly, via cron) a check on those entries that looks for multiple IP/Sessions or whatever you define as multiple users (given that http is stateless there really is no _safe_ definition). If that process detects usage over your threshold, disable (temp or permanent) the account. The same process can clean up entries that are outside of the time window that you want to look at. If you in any way expect your site to scale to high volume, I'd highly recommend avoiding any approach like this. Your 'hit logging' table is going to be really really slow (and have massive contention) if you're doing high volume. Also - these lookups for multiple IPs you're talking about, they're not going to be indexed, right? (Adding a *single* index on a table will reduce your max insert speed by 40-60%). Even if you're cleaning out rows pretty regularly, you're going to seriously grind the IO on the DB system, and the general IO subsystem on your database server (not to mention any replication / binlogs / hot backups etc that you need), is going to be doing significantly more work than it needs to, meaning that the general amount of headroom you have in the system will be that much reduced... Your session storage could be criticized for the same reasons, but is actually significantly less work for the DB (updating, not inserting and deleting - 1/2 the IO and no index overhead as you're re-writing without changing keys), and can _trivially_ be pushed into memcache at a later date when you need to. The approach recommended above requires a relational model, and so moving it to memcache wouldn't work... All of that said, unless you're looking to scale to multiple Mb/s of traffic, then I'm probably being too paranoid - as jay said already, 'right' here is use-case specific :) Cheers t0m ___ 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] Preventing simultaneous logins
indeed, it is use case dependent. The use case here is a common one, free content, paid content, you don't want users giving their creds to all their friends and using it simultaneously. (It is at best a first order solution, obviously if it becomes obvious that a fair percentage are using the system 24/7, something better is needed (say, bw capping). Not to hard to do, if needed.) As for the other points : 1. hadn't considered people closing the browser, without logging out - thanks. I guess a short session time is needed - say 10 minutes. The idea of pinging using javascript is quite neat, but I dislike the idea of making the server handle say 2 unproductive req's per minute per logged in user. I'd even rather something as ugly a js popup saying If you close without logging out ... when the user closes while logged in to that, I think. 2. the issue of someone leaving work with their browser left logged in is pretty insoluble (after all the browser could well be left open, so you still rely on session timeout). If they do it, they have to wait the 10 minutes, or go back to that computer and log out. K-I-S-S ... If you do all that, so that logout will always happen, couldn't you then solve it like this? (There may be a big fat hole in this ... this is hardly my specialist area ...): 1. On successful login (ie good U/P), get last session key for that user which you left in the db last time. 2. Look in the store for that key, see if it has timed out 3. If so, actually log in and write the new key to the db. 4. Otherwise, fail and leave the db alone. 5. On a real actual logout, nullify the key in the db and take it out the session store. That has only one db write per login (and I store last_login time anyhow, so no real increase), and the session store stays out of the db. Regarding volume, well, it's hardly an issue today, but you never know ... thanks for the excellent quality of feedback Daniel -- There's an infinite supply of time, we just don't have it all yet. ___ 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] auto re-load of application yaml config file?
On Jul 23, 2008, at 4:32 AM, Matt S Trout wrote:
On Tue, Jul 22, 2008 at 12:53:10PM +0200, Marc Sebastian Pelzer wrote:
Hello,
I'm running a Catalyst application under mod_perl and wonder if there
is a Plugin available that detects changes on the main
application .yml config file and does a automatic re-load if needed?
It not - what would be the most elegant (and less I/O intensive) way
of doing this? Would it be enough to do a
__PACKAGE__-config( 'Plugin::ConfigLoader' = { file =
'my_config.yml' } );
in my Root controller when I detect a change?
Nope. apache2ctl restart, minimum.
You may find external FastCGI and a handler swap is a better approach.
Or mod_perl backends (old and new) and a decent load balancer like
perlbal.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
___
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] Preventing simultaneous logins
On Wed, Jul 23, 2008 at 09:47:57PM +0200, Daniel McBrearty wrote:
I'm using Cat with a pretty standard configuration of :
Catalyst::Plugin::Authentication
Catalyst::Plugin::Session
Catalyst::Plugin::Session::State::Cookie
Catalyst::Plugin::Session::Store::FastMmap
to handle login and session management. My login code looks like this:
my $u = $params-{username};
if ($c-authenticate( { username = $u,
password = $params-{'password'}
} )){
my $user = $c-user;
$user-last_login(DateTime-now);
$user-update();
$c-response-redirect( $forward, 301);
} else {
# login failed
$c-stash-{login_failed} = 1;
}
What I'd like to do is check if this user is already logged in at some
other computer, and deny access if so. I guess that means :
1. checking whether there is an existing session associated this username
Session::PerUser ?
2. Being sure that the associated session is cleared when the user hits
'logout'
after logout = { shift-delete_session };
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Directorhttp://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
___
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 and Taint?
On Tue, Jul 22, 2008 at 11:45:09PM -0700, Chris Weyl wrote: On Tue, Jul 22, 2008 at 8:30 PM, Matt S Trout [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 10:08:11PM -0700, Chris Weyl wrote: Hey all -- A google of catalyst taint turns up this message: http://lists.scsys.co.uk/pipermail/catalyst/2005-December/004007.html It doesn't look like there has been a release of Module::Pluggable::Fast since then. Does anyone know where this patch lurks? :-) (Assuming, of course, that this is still the right path to work down.) We don't even use Module::Pluggable::Fast anymore. Catalyst went back to a refactored plain Module::Pluggable instead for 5.70+. Hopefully the patch claco sent back then got applied somewhere in the meantime. Before caring about a three year old message, first check the module it refers to is even involved anymore :) I'll keep that in mind :) According to CPAN, Module::Pluggable::Fast hasn't been updated since 16 Dec 2005, about 2 weeks before that email was sent If it was applied, I rather suspect it wasn't there. Yeah, thought so. And it's fucking horrible code, so when sri abandoned it none of us wanted to maintain it. So I talked muttley into refactoring Module::Pluggable for us instead :) (and since you're the only person since to mention taint mode, I don't think most people care about it - I certainly don't see it being very useful for Catalyst code, maybe you could enlighten us as to why you do?) Taint mode would seem to be a good way to help protect against accidental exposures, especially in internet-facing apps. I was curious to see what would happen if I tried running an instance with -T... Admittedly, I'm more of a newbie Catalyst user than internals person by any measure, but is there something about Catalyst that renders taint unnecessary, or moot? ...or obsolete? ...or more of a pain than it's worth? Taint mode just separates stuff that came from outside the app and stuff from inside the app. The thing is, by the time you get to a $c-req object parsing has happened so it probably won't be tainted anyway. But you -do- still need to validate it. So the only thing I can see taint mode providing is a false sense of security. But probably is not the same as definitely and if that turns out to be wrong my entire argument is bollocks. Bear this in mind :) -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ 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
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) ?
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Directorhttp://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
___
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] auto re-load of application yaml config file?
On Wed, Jul 23, 2008 at 11:26:18PM +0100, Pedro Melo wrote:
On Jul 23, 2008, at 4:32 AM, Matt S Trout wrote:
On Tue, Jul 22, 2008 at 12:53:10PM +0200, Marc Sebastian Pelzer wrote:
Hello,
I'm running a Catalyst application under mod_perl and wonder if there
is a Plugin available that detects changes on the main
application .yml config file and does a automatic re-load if needed?
It not - what would be the most elegant (and less I/O intensive) way
of doing this? Would it be enough to do a
__PACKAGE__-config( 'Plugin::ConfigLoader' = { file =
'my_config.yml' } );
in my Root controller when I detect a change?
Nope. apache2ctl restart, minimum.
You may find external FastCGI and a handler swap is a better approach.
Or mod_perl backends (old and new) and a decent load balancer like
perlbal.
Same approach. Different technologies.
I find getting two FastCGI handlers running much less of a pain in the
arse than getting two mod_perl instances running - the distro stuff tends
to get in the way and even once I've beaten it out of the way it's much
more work than FCGI.
But sure, either is good. Choose your poison according to your own tastes :)
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Directorhttp://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
___
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/
