How to check JSON object or JS object is empty?

if (!Object.keys(jsonObj).length === 0) {

    console.log("JSON object have some keys and values");

} else {

    console.log("JSON object is empty");

}

Here jsonObj is JSON or JavaScript object.

Refused to load the script

Content-security-policy deny the script from third-party system, but few third-party application and system needs to be allow so that we can use their libraries in our web application. In this case since the content security policy blocked all script hence our application is unable to load any library from cdn.tiny.cloud host. Lets see the error ans solution in detail.

Error

Refused to load the script 'https://cdn.tiny.cloud/1/rashidjorvee/tinymce/6/tinymce.min.js' because it violates the following Content Security Policy directive: "script-src blob: data: 'unsafe-inline' 'unsafe-eval' 'self' rashidjorvee.com adobeaemcloud.com". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

Solution 

Using dispatcher config we can solve this by adding content-security-policy and allow that domain.


<IfModule mod_headers.c>
    Header add X-Vhost "publish"
    Header always set X-XSS-Protection "1; mode=block"
    Header always set content-security-policy "script-src blob: data: 'unsafe-inline' 'unsafe-eval' 'self' *.tiny.cloud *.adobeaemcloud.com
</IfModule>

AEM Environment Variables | AEM as Cloud Service

The Adobe I/O CLI plays an integral role in development on AEM as a Cloud Service as it provides developers the ability to manage Cloud Manager environment & pipeline variables from the CLI

Pipeline Variables

Your build process may depend upon specific configuration variables which would be inappropriate to place in the git repository or you may need to vary them between pipeline executions using the same branch.

Cloud Manager allows for these variables to be configured through the Cloud Manager API or Cloud Manager CLI on a per-pipeline basis. Variables may be stored as either plain text or encrypted at rest. In either case, variables are made available inside the build environment as an environment variable which can then be referenced from inside the pom.xml file or other build scripts.

Uses example

• Used to vary behavior of build process
• Accessible inside the build process
• Dev minification is set differently on Dev vs Stage or Prod
• Disable caching on Dev

Standard Environment Variables

Changing application behavior based on standard environment variables

Uses example:

• Provided to the runtime environment
• Used in OSGi configuration
• Store passwords outside of version control, instead use a reference.
• Connect your AEM application with different external endpoints

Types of environment variables

1. Inline values. e.g. { "keyName" : "jorvee" }
2. Environment specific values. e.g. { "endpoint" : "$[env:JORVEE_ENDPOINT]" }
3. Environment secrets. e.g. { "authToken" : "$[secret:J_AUTH_TOKEN]" }

Variable naming conventions

• Variable names must observe the following conventions.
• Variables may only contain alphanumeric characters and the underscore (_).
• The names should be all upper-case.
• There is a limit of 200 variables per pipeline.
• Each name must be less than 100 characters.
• Each string variable value must be less than 2048 characters.
• Each secretString type variable value must be less than 500 characters.

References:

•  AEM environment variables