Hi,
I came across a scenario, where the code inside the diffrent objects (tables, forms, codeunits, reports) need to be scrambled/ encrypted. For example think of the following code :-
Customer.get(custno); where
Customer refers to a Record type vairable pointing to Customer table and
CustNo refers to cust. code.
Now we have to encrypt the code scriptlet in such a way that the functionality remains intact, but the meaning becomes un-decodable/un-readable/un-understandable.
For ex- the above code could be rounded to ''YURDM$ED.ROY(CSRTMY) ;
Is there any way to achive this?
Please suggest.
Subhasish Chakraborty,
Systems Analyst,
MBS Dynamics.
0
Comments
There is no sensible reason to do this. Best is that if you don't trust that people will steal your code, that you get out of the industry.
Systems Analyst,
MBS Dynamics.
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
RIS Plus, LLC
MVP - Business Apps
So what I'd do is to explain to the customer that the code is just like the data in their database: confidential, yes, to be protected, yes, but protected by usernames/passwords/permissions. They do not normally scramble their other confidential data like customer accounts, they restrict access to them.
Explain them that it's not not like any normal .NET application. It's data in the Object table in the database, compiled into a BLOB field, not different than any other confidential data in their database.
Yes I know often it's very hard to convince people of things like that, but this should not be an impossible case, "understand that it's just another kind of data in your database" is a fairly strong argument.
While it is not normal to protect or hide NAV code it is possible to do so. One of the partners has written an add-on to remove the source code from the complied objects (I think I came across it on Mibuso - Brught Consulting) This is possible because the binary version of the object and the text version of the object are stored in different fields.
If you choose to go this route it is imperative that keep the source protection outside of the development environment because once the code is removed it is lost forever.
The issue is whether it will work in 2009. I will not touch or implement any database that would have this modification
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
i'm curious
"Never memorize what you can easily find in a book".....Or Mibuso
My Blog
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
And what happens when the customer needs to debug themselves, or what happens when they change partner? Then what do they do?
To me this looks like a way to black mail clients into never being able to change partners, and is a very unscrupulous way to do business. And how will the client even know. They won’t find out till one day it breaks. This is totally unacceptable.
RIS Plus, LLC
MVP - Business Apps
Regarding the ethics around this - I feel it would be ethical if the customer was aware of it and they were not tied to you. In other words, the customer could still own the source code it just would not be in the production database. The original request was a customer not wanting people to be able to view their code. If this is the case, then I see this as a solution that could work. My personal opinion is that if a partner were to retain the source code to tie a customer to them then that would not be a good situation for the customer or the partner. The customer should want to stay with the partner.
Regarding the F9 compile - I will not work once the source code is removed. However, I feel that this should not be done in the production database.
Anyway, everyone is entitled to their own opinions and I really feel I've said enough on this topic.