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.

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.

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

You definately want to use the 'has_a' relationship for this.

* Using a has_a relationship for 'password' and a custom EncryptedPassword class. I can't get this to work properly though. When using create() the class is 'inflated' using the plaintext password, otherwise it is called with the encrypted password and I am not sure how to tell how the constructor for the custom class was called.

The trick with using a 'has_a' object with the 'create' method is that Class::DBI will expect you to pass an object for the 'password' column when calling 'create'. Since you are passing a string, it thinks it needs to inflate your string first which means it tries to decrypt the string you have passed in.

If you want to be able to provide a plain text string to 'create' and still use the has_a relationship with the password field, then you will have to write an 'inflate' method that can distinguish between the plaintext and encrypted formats and 'do the right thing' (ie if it sees plaintext, leave it alone, and if it sees encrypted data, decrypt it.

See this node for some info on how you can do this with Dates. It doesn't apply directly, but it might give you some more insight...

Good luck in learning about Class::DBI. You won't regret the move

- Cees

I haven't tried them yet, but according to the doc's Class::DBI has an "add_trigger" method where you specify the trigger point and then give a coderef to execute. Surely this would do wyat you want?

jdtoronto

Yes they do! Apparently I was replying to your question while you were replying to mine. :)

I have been playing with the triggers and they work for the most part. The main problem I am having with them in this situation is that they are not called in the search methods of CDBI. So for instance I can't do something like this:

my $obj MyModule->search(password => 'blahblah');
[download]

Because the trigger for 'select' hasn't been called so it is literally checking the string 'blahblah' against the encrypted password in the database. :/

No guarentees that this is the best solution (in fact I kinda doubt it), but.. I would probably look at using before_create & before_update triggers, TEMP column, and overriding the search method. Beware though, there may still be issues with this method when another class interacts with this one automatically through relationships (I haven't dug deep enough to work out all the bits yet...)

__PACKAGE__->columns( TEMP => qw/ password / );
__PACKAGE__->add_trigger(before_create => sub {
                 my ($self, %args) = @_;
                 $self->{enc_pass} = $self->encrypt_password($self->{p
+assword});
             });

__PACKAGE__->add_trigger(before_update => sub {
                 my ($self, %args) = @_;
                 $self->enc_pass = $self->encrypt_password( $self->pas
+sword );
             });

sub search{
  my ($self, %query) = @_;
  my @results = $self->SUPER::search( %query );
  foreach my $result(@results){
     $result->password( $self->decrypt_password( $result->encpass ) );
  }
}
[download]

$object->password should be used to get/set the plaintext password, while in the database it is encrypted an stored as enc_pass.