Behavior (same approach, different code and strategy for execution)
that has more features than this Behavior awhile back; unfortunately I
ran in to a stumbling block. Although it is able to automatically
encrypt/decrypt data on the fly so it's seamless to the developer
(developer does not need to worry about manually decrypting the data
in the controller, or encrypting to match on find calls), it only is
capable of on-the-fly decrypting for the *current* model. I was
unable to determine how to extend it to related models of a find()
query/call.
Another issue with this is that it's expensive. If you decide you
want to do a recursive model call, assuming I was able to
automatically decrypt all fields of related tables, I believe each
separate model would have to be instantiated at least once to get the
proper configuration for that particular model's encryption settings
(as they can all be set independently, just like the Cryptable
Behavior). So even if I was able to figure out a way to automatically
decrypt related fields (it is possible), it would be a costly call as
you not only have to run the mcrypt function call on each find call,
you'd have to instantiate any related models within the find(), AND
run the mcrypt on them as well. All of that can add up pretty fast if
you go crazy on which models you want to encrypt.
That being said, my behavior is incomplete; it only works on a single
model, and if you request that model's encrypted field(s) from another
model, it will show up encrypted, not decrypted (i.e.: User.username
is encrypted --> you wanted to get the username associated with a
Post.author_id field, it would possibly return "re97gur!#$%Wds"
instead of "Bob").
So, yes it's possible. However, you're bound to have a huge task
ahead of you, not only in terms of coding time, but in optimizing your
queries and caching.
I eventually will have to complete my behavior, and I will release it
on the Bakery, but I have ZERO timeframe for completion. It is not a
priority of mine at the moment.
On Dec 19, 5:03 am, Marco <marco.perg...@gmail.com> wrote:
> I think you can take a look at this behaviour:
>
> http://bakery.cakephp.org/articles/view/cryptable-behavior
>
> I didn't try it but I use something similar. You need the mcrypt
> library installed on your server.
>
> On Dec 18, 3:52 pm, WhyNotSmile <sharongilmor...@googlemail.com>
> wrote:
>
>
>
> > I am doing this for a client. He has access to the database through
> > his control panel of his web host. I want it to be encrypted so he
> > can't read the data. It's not that I don't want him to see it, but
> > that there is data which clients might not want him to see. I also
> > have access to the database, and they might not want me to see it
> > either. So, basically, when you go to PHPadmin, it should be
> > encrypted. Does that make sense?
>
> > Also, if anyone was to hack into the database somehow, I don't want
> > them to be able to read the data.
>
> > Thanks,
> > Sharon
>
> > On Dec 18, 2:04 pm, robustsolution <i...@robustsolution.net> wrote:
>
> > > of course you are talking about two-way encryption not hashing (one
> > > way).
>
> > > by the way what do you mean by the database owner?
>
> > > either the guy have a full access to the database or a custom access.
>
> > > if you are the one who has full access, give him a mysql account with
> > > custom access to all tables except the tables that have sensitive
> > > info.
>
> > > otherwise an alternative solution should be required here.- Hide quoted text -
>
> - Show quoted text -
Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions.
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
No comments:
Post a Comment