Im not going to lie, Code Apps are now my favourite thing about the Power Platform (well maybe not, my heart still belongs to Power Automate, but man its close).
The reason I love it is because I always wanted to be a ProCode developer, but I never had the time or skill. I could just about build something with vanilla JavaScript, but libraries/frameworks lie Next.js, Vue and Angular, I didn't have the time. And although Code Apps are React based, with a little creativity you can build vanilla JavaScript apps instead (Power Apps - A Cooler Way to use Code Apps.
Now the truth is they are not right for everyone, and vibe coding them is still a little more painful then fun, but they are definitely cool and something you should be looking at.
So this blog is all about getting setup to build them, I don't think they are ready for citizen developers, but have potential for professional Power Platform developers.
- Environment Setup
- Content Security Policy
- Code Storage
- Code Reviews
1. Environment Setup
This one is quick and easy. For once Microsoft did the right thing and left something new as off by default. To turn on Code Apps in an environment goto PPAC, select your chosen environment and select features.
Then with a little scrolling you should see the option to turn it on.
2. Content Security Policy
This is one you might not know about, but is super important.
The DLP policy is the main way we secure the Power Platform, it's a whitelist for:
- Connectors
- Custom Connector Urls
- HTTP Action Urls
and the good news is they work across Code Apps. As Code Apps should use the SDK to create connections just like a Canvas App.
But as we have said, Code Apps are React apps, which are JavaScript apps. So we can use simple JavaScript to call API's instead of connectors.
const response = await fetch(
`https://restcountries.com/v3.1/name/${encodeURIComponent(name)}?fullText=true`,
{ signal: currentAbort.signal }
);
if (!response.ok) throw new Error(`HTTP ${response.status}`);
const data = await response.json();
if (data && data.length > 0) {
renderCountryDetail(data[0]);
} else {
showError(`No details found for "${name}".`);
}
Example fetch api call
So how do we stop this, well good news Microsoft has thought of that. And by thought of that I mean use the existing PCF controls that allow you to edit the CPS (Content Policy Security), and guess what by default it is fully locked down (2 for 2 Microsoft, so proud of you).
The CPS can be found in PPAC environment settings, but instead of features its under Privacy + Security, scroll to bottom right and you will see it.
There are settings for Model Drive, Canvas, and App. We want App as that is for Code App.
As you can see by default it isn't on, and is blocking everything.
You can simply turn it off, but I strongly recommend against that even for innovation environments.
There are a lot of settings you can play with:
But the most useful ones are:
- Use default frame-ancestors - sites where the app can be embedded
- Use default connect-src - this is for those fetch API calls I mentioned
- Use default script-src - use code hosted in a different location
- Use default style-src - use css hosted in a different location
- Use default img-src - use images hosted in a different location
And the 3 to be really careful with are:
Use default frame-ancestors
Cam allow any site to pretend to be the app, allowing the users can be clickjacked.
*Use default connect-src *
This is your dlp policy, so it exposes data exfiltration.
Use default script-src
This allows remote code execution, as you are running someone else JavaScript code in your app.
The image one is less of a risk but one you will probably hit, there are still small risks (data leakage, copyright, etc), so keep a whitelist is still recommended.
I don't recommend messing with the other settings (I personally would only stick with img-src and a little but with connect-src to start with).
In a counter intuitive way turning them off doesn't actually turn them off, it just switches to a whitelist, which by default is empty (3 for 3!). So you need to actively add your source.
You don't need to use wildcards (*) for all endpoints, only for subdomains. Which means you can enable for everything (not recommended) by using just a wildcard.
| Example | Needed in connect-src |
|---|---|
| https://restcountries.com/v3.1/name/peru | https://restcountries.com |
| https://restcountries.com/v3.1/all | https://restcountries.com |
| https://api.restcountries.com/... | https://api.restcountries.com |
| Multiple subdomains | https://*.restcountries.com |
| Any URL anywhere | * (not recommended) |
And you should be all ready. Just a quick call out, CPS runs when the browser hits the site, so updates don't always appear without closing and opening the browser.
More info can be found here MS Learn CPS.
Though I think it's important to say, connectors are by far the better way to go, if you need to call an external API you should be using custom connectors. Just some of the benefits include:
- DLP is across tenant and environments so easier to manage
- Stops you having to deal with storing secrets
- It handles the risky stuff like auth
So if you are going to use it, is probably only good for unauthenticated API's.
3. Code Storage
Code Apps are stored in the Power Platform as simple HTML, JavaScript, CSS files (like Canvas Apps they are not actually stored in Dataverse, there is just a reference table - {{dataverseURL}}/api/data/v9.2/canvasapps?$filter=canvasapptype eq 4).
But it means you cant edit/build in the Power Platform, you have to build it code editing tools like VS Code. So if you want to edit it you have to export it in a solution, and this leads to the big problem, when building in React the code is transpiled to JavaScript, which is a one way process. So you can't edit it, which means you need to store the code somewhere else.
Quick all out, I mentioned I build in vanilla JavaScript, and one of the benefits to this is it's not transpiled, so as long as you don't minify the files you can export the solution and edit the files. Check out codeapp.js to find out more.
code app using codeapp.js
The best place to store your code is probably GitHub, its free, works great with VS Code/most code editors, and has features like version control/multi dev. But it's just code in files, so you can store it anywhere, the most important thing is to set up a central location and ensure its used, as else once its lost you cannot get it back.
4. Code Reviews
Not really part of the environment setup, but something I wanted to call out because it needs to be part of you deployment process between environments. As Code Apps use standard code it means that your normal code review process wont work, tools like appreview-pro don't support them (yet 😎), on top of that there are more risks/vulnerabilities.
But on the flip side it's just code, and this is a tried and tested path, so there are already lots of tools for code scanning/reviewing, just use your organizations preferred tool.
But that then leads to the broken line of trust, as what is deployed is transpiled, how do you review it? I recommend that your deployment pipeline changes, and you do not follow the standard Dev - Test - Prod, you need to deploy from your repo to Test - Prod, and that needs to be done by someone who is not the developer, and after they have completed the code review / scan.
And that's it, you should have the foundation to build safe Code Apps, but as I said I still don't think they are right for everyone, but they definitely are something you should explore/have in your toolbox, and are definitely cool 😎
If you want to use the demo app I created that uses https://restcountries.com/ api you can download it from my repo here: https://github.com/wyattdave/Power-Platform. Its built with https://codeappjs.com so you can read all of the code too.
Top comments (0)