in reply to Class::DBI - performing action on column before it is used or saved

Take a look a the TRIGGERS section of Class::DBI. You seem to want to set before_create, before_set_$column, and select.

Personally, I solved a similar problem (specifically, saving passwords with SHA1 and a salt value) by overriding create. Then methods called check_passwd and new_passwd were created for checking passwords and getting a new password, respectivily. With SHA1, it's hard to get the orginal text back, so there was no point in trying to override password to get the plaintext version back. Instead, the methods provided would do everything you'd want a password object to do, which ends up being a better OO design anyway, since there is more encapsulation.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Re: Class::DBI - performing action on column before it is used or saved
by duct_tape (Hermit) on Dec 19, 2003 at 21:01 UTC

    Instead of using the before_set_$column trigger, I found before_update to be what I needed. However, this still doesn't solve the problem 100%, as the search methods don't work with the triggers. :(

    I suppose I could create a method like decrypted_password in my class to deal with this. I was just hoping I could make it more transparent.

    Thanks for the reply. :) I will do some more thinking on the subject.

[reply]

      It's actually better if you don't decrypt the password at all. Instead, encrypt the password you got from the user exactly the same as the one in the database was and compare them.

      Never having passwords (or other secure data) in memory is a Holy Grail that isn't always possible, but it's a good goal.

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

[reply]
[d/l]

        I agree, however this isn't for use in checking a password that a user supplied. It's for listing passwords that are stored in the database for an application that manages host information. Which is why I am using Blowfish to encrypt them instead of doing a SHA1 or MD5 hash.

        Also in this database are IP addresses that have been stored in a packed() format (by a previous developer). So my question also applies to them, and is not just strictly for the passwords.

        IE:
        The ip needs to be unpacked when it is read from the database, and then packed again before it is stored. So that I can keep my CDBI code transparent to the fact that this stuff is going on behind the scenes:

        # to find the row that has this ip.
my $obj = MyModule->search(ip => "127.0.0.1");

# or to print out the ip
print $obj->ip;

# or to update the ip...
$obj->ip("192.168.0.1");
$obj->update();

        [download]

        I suppose I can always make methods like decode_ip, encode_ip, encrypt_password, etc... I just thought it'd be good to have it part of my CDBI class to make sure that the data gets written into the database in the correctly (ie: no passwords accidentally stored unecrypted because of a forgotten method call)

[reply]
[d/l]

In Section Seekers of Perl Wisdom