On Mon, Oct 27, 2008 at 11:57:00PM -0600, Jason Kuri wrote:
You can get clear passwords with no warnings by dropping SimpleDB for
configuration purposes and using a 'standard' auth config that looks
like this:
Which hides the badness.
Frankly I'd like to see -all- of authentication warn on
* On Mon, Oct 27 2008, Thomas L. Shinnick wrote:
If I explicitly override the default, by explicitly requesting 'clear',
because
my requirements explicitly need this ability, then I must change the code to
get rid of the warning? Ahh, but it's for the 'simple', who must be guided,
and can't
I think a good approach is to have safer more secure defaults, and
if users explicitly turn those off then have relevant warnings on by
default, and if users really know what they're doing then they can
explicitly turn those off.
For example, users can have an explicit
Matt S Trout wrote:
On Mon, Oct 27, 2008 at 03:51:49PM -0700, Darren Duncan wrote:
Zbigniew Lukasiak wrote:
* Your passwords are stored in the 'password' field in your users
table and are not encrypted.
This is always a bad idea. If someone ever gets direct database access,
they now know
From: Simon Wilcox [EMAIL PROTECTED]
Matt S Trout wrote:
On Mon, Oct 27, 2008 at 03:51:49PM -0700, Darren Duncan wrote:
Zbigniew Lukasiak wrote:
* Your passwords are stored in the 'password' field in your users
table and are not encrypted.
This is always a bad idea. If someone ever gets
Zbigniew Lukasiak wrote:
* Your passwords are stored in the 'password' field in your users
table and are not encrypted.
This is always a bad idea. If someone ever gets direct database access, they
now know each user's mindset as to how they choose passwords, and can
subsequently login
On Mon, Oct 27, 2008 at 03:51:49PM -0700, Darren Duncan wrote:
Zbigniew Lukasiak wrote:
* Your passwords are stored in the 'password' field in your users
table and are not encrypted.
This is always a bad idea. If someone ever gets direct database access,
they now know each user's
I made the default 'clear', as the tutorial uses 'clear' and it is the
least likely to cause failure of auth for those just coming to
catalyst / going through the tutorials. The password_type config
option allows changing it to something more reasonable for production
use.
Matt and I discussed
At 07:13 PM 10/27/2008, Jason Kuri wrote:
I made the default 'clear', as the tutorial uses 'clear' and it is the
least likely to cause failure of auth for those just coming to
catalyst / going through the tutorials. The password_type config
option allows changing it to something more reasonable
If I explicitly override the default, by explicitly requesting
'clear', because my requirements explicitly need this ability, then
I must change the code to get rid of the warning? Ahh, but it's for
the 'simple', who must be guided, and can't be bothered to read the
warnings in the text so
Jason Kuri wrote:
If I explicitly override the default, by explicitly requesting
'clear', because my requirements explicitly need this ability, then
I must change the code to get rid of the warning? Ahh, but it's for
the 'simple', who must be guided, and can't be bothered to read the
warnings
Hey all,
Catalyst authentication configuration just got a whole lot easier.
I just released two updates to CPAN that will make Auth configuration
much much easier for the 'average' case where you have user data
stored in an SQL database and you are using passwords for
authentication.
Now, the
12 matches
Mail list logo
