Encryption/Decryption: Controller or Model?
Moderator: General Moderators
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Encryption/Decryption: Controller or Model?
Hello, world!
I'm working on a script that employs RSA encryption for communication. I'd like to know, should encryption/decryption be at the controller level, or at the model level?
I'm working on a script that employs RSA encryption for communication. I'd like to know, should encryption/decryption be at the controller level, or at the model level?
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Encryption/Decryption: Controller or Model?
I'm thinking that decryption (for incoming data) should occur in the controller, and encryption (for outgoing data) should occur in the view.
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Re: Encryption/Decryption: Controller or Model?
Models represent data. You are manipulating data, therefore the logic belongs in the model. It doesn't make much sense to provide this functionality in either the controller and especially not the view since you are neither "controlling" the flow nor it is a presentation.
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Encryption/Decryption: Controller or Model?
But encryption is a form of view, isn't it? It takes the raw data, and encrypts it. And should the model really have to know that there's encryption happening?
Re: Encryption/Decryption: Controller or Model?
Now, I don't know your specific situation but to me it seems it could easily be logical to put different parts on different levels. Like encryptor/decryptor in the model layer, part that decides if encryption/decryption should be applied (based, perhaps, on some configuration) in controller layer (might be a subclassed request, or controller plugin), part that calls encryptor could be in the view layer (subclassed response, alternative view).
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Encryption/Decryption: Controller or Model?
In this case, I'm using public key to encrypt data to be sent to the server (a product key for registration), and using the private key on the server to sign data in response. Perhaps John's right, because it's such an integral part of the process?
Re: Encryption/Decryption: Controller or Model?
IMO it have to be in the Domain Service layer as it's not really part of the model (you'll hu ave to provide such capability to any of the models and if you change / add another encryptyon algorythm, you will have to change all models respectively), but still it does manipulate the data.
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Encryption/Decryption: Controller or Model?
I would create a component/library that handles the encryption/decryption in its entirety (the implementation), and then use that component in those models where needed. View is definitely not the right place and it's a out of the scope of the controller.
Re: Encryption/Decryption: Controller or Model?
Are we assuming that the encryption is only used to transport data from the app to the user/other system and vice-versa?
I ask, because if the app is some "data encrypting app" then it becomes part of the Domain of that app (and thus, the model).
I ask, because if the app is some "data encrypting app" then it becomes part of the Domain of that app (and thus, the model).
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Encryption/Decryption: Controller or Model?
@kai: seems like a good idea.
@Jenk: for incoming data, it's just to keep the data private. For outgoing data, it's for digital signing.
@Jenk: for incoming data, it's just to keep the data private. For outgoing data, it's for digital signing.