237
Hi,

For now the only possibility to debug the code is to set the showMyCode property to true in the manifest file of our app. In combination with this setting we can add the [NonDebuggable] attribute in parts of the code we don't want to be seen by the debugger.
Problem is with showMycCode = true the source code of my app can be downloaded by anyone who has access to the environment in the Extensions page.
So to debug our app in a customer environment we have to give the hability to anyone having access to this environment to download the entire source code of our app.

It would be great to be able to debug the code without giving the possibility to download the app full code in order to protect our IP.

For now "solutions" is to have at least two apps: one with showmycode = false that is downloaded in customer environments, another with showmycode = true that is downloaded in customer environment for "special requests" in order to be able to debug it. This is not good "solution" - we have to maintain two solution whereas they contain the same code just to be able to give support to our customer and keep an eye on our Intellectual Property.

Related Yammer topics:
https://www.yammer.com/dynamicsnavdev/threads/911247691218944
https://www.yammer.com/dynamicsnavdev/threads/1041696414400512

Thanks to think about any improvement that can protect our IP and giving a correct support customers in the same time.
Category: Development
STATUS DETAILS
Completed
Ideas Administrator

Thanks for logging an idea on this and voting
 
We shipped this as part of 2021 Wave 2
 
More granular static app.json settings for IP access through flags in the new "resourceExposurePolicy"
- allowDebugbing: Control source access during debug. Note that it would be possible to mine IP across debug sessions
- allowDownloadingSource: Control access to downloading .app with source from tenant
- includeSourceInSymbols: Control whether symbols contain source when downloaded from server during development
Ability to dynamically set above flags per AAD tenants through placing .json configuration file on KeyVault resource defined in app.json
- This allows locking down the app in various of above dimensions and unlock (temporary) for specific AAD tenants
- Obsoleting showMyCode app.json property
- Obsolete warning if used
We will error if both showMyCode and resourceExposurePolicy properties are used at the same time
 
 
Regards,
Business Central R&D team
 

Comments

J

I think it should be a combination of things. BTW debugging becomes critical, because of the multitude of Apps we deliver to a tenant together with 3rd party partner apps and keeping up-to-date with BC upgrades/updates. We find it very difficult to go through a proper analysis without full debugging. In most cases it’s not even clear which extension is causing the issue. We currently create a sandbox from production, set ShowMyCode to True on all Apps (at least the ones from ourselves…) and then start debugging… if the customer data grows fast this can even become a challenge…

…and also do not forget the customer wants/needs and the ‘tenant owner’ situation. Is it an ISV based customer (CSP tier 1), a VAR based customer (CSP tier 2) or is it the customer itself…

The ‘owner’ and access:

1. whether the ‘debugger person’ has access to the tenant determines the rights that the tenant owner grants i.e. per tenant

2. whether the ‘debugger person’ has access to debug the code determine the rights that an ISV grants, i.e. per App (id)

3. whether the ‘debugger person’ has access to debug the code determine the rights that an VAR grants on PTE Apps or on-top-of specific country or market specific Apps or horizontals, i.e. per App (id)

4. to debug you need rights 1 and 2 (and possibly 3)

So in effect the VAR and/or ISV needs to be able to troubleshoot tenants. The ISV could grant VAR partners access. And the other way around for PTE Apps or country/market specific Apps or horizontals. This should not be compile-time only but should be possible on demand as well e.g. by using dynamic settings.

WDYT? Keep me posted please on your thoughts and directions. Thanks in advance!

I really appreciate opening up this topic!

Category: Development

J

I would prefer a setting that blocks download of code and debug of downloaded symbols, but allows debug with the original source files.

Category: Development

J

I prefer being able to define what partner can debug the app. I think this is closest to OnPrem where we as ISV can setup this via corresponding configuration of license.

Category: Development

J

This is now one of the top voted ideas - will this be considered?

Category: Development

J

Peter Borring had a good idea in the secon Yammer thread mentioned in this idea:
More granular "ShowMyCode", adding an Option "AllowDebugging". That would allow debugging, but no downloading of code. Add to that the already existing possibility to place critical methods under "NonDebuggable" and we could have decent protection without a secret key. Hopefully cheaper to implement for MS, so more likely to actually happen :-)

Category: Development

J

This will give partner more peace of mind to bring their IP's on Business Central. MS should give this idea highest priority.

The idea of having some kind of key in launch.json to debug will be icing on the cake.

Category: Development

J

I'd prefer the way that in the launch.json we have some kind of secret key, so that only we're able to debug our app

Category: Development