Welcome to Tech Mastery, your expert source for insights into technology and digital strategy. Explore topics like Adobe Experience Manager, AWS, Azure, generative AI, and advanced marketing strategies. Delve into MACH architecture, Jamstack, modern software practices, DevOps, and SEO. Our blog is ideal for tech professionals and enthusiasts eager to stay ahead in digital innovations, from Content Management to Digital Asset Management and beyond.
I encountered the following error while using Ollama JavaScript on my local system.
ReferenceError: XMLHttpRequest is not defined
at \Development\ollama\js\node_modules\whatwg-fetch\dist\fetch.umd.js:540:17
at new Promise (<anonymous>)
at fetch (\Development\ollama\js\node_modules\whatwg-fetch\dist\fetch.umd.js:533:12)
at file:////Development/ollama/js/node_modules/ollama/dist/utils.js:77:28
at Generator.next (<anonymous>)
at file:////Development/ollama/js/node_modules/ollama/dist/utils.js:7:71
at new Promise (<anonymous>)
at __awaiter (file:////Development/ollama/js/node_modules/ollama/dist/utils.js:3:12)
at Module.post (file:////Development/ollama/js/node_modules/ollama/dist/utils.js:72:53)
at Ollama.<anonymous> (file:////Development/ollama/js/node_modules/ollama/dist/index.js:59:42)
The actual issue was with the node and npm versions, please ensure the latest node/npm version is installed on your system before running the Ollama JS in your local system.
I was managing Node.js using NVM, and the issue only occurred with versions 20.11.0 and above, while earlier versions worked perfectly. The PATH setup appeared to be correct. Ultimately, I resolved the issue by directly downloading and installing Node.js on the system.
In this post, let us explore some of the security-related setup/configurations available on AEM as a Cloud platform to protect the platform.
Traffic Filter Rules:
Traffic filter rules can be used to block or allow requests at the CDN layer (Fastly). These traffic filter rules are available to all AEM as Cloud Service Sites and Forms customers OOTB.
The traffic filter rules can be used for multiple scenarios.
Rate Limit the requests based on client IPS’s.
Block traffic based on IP addresses, Request Path, Query String, method, domain, reqHeader, reqCookie, postParam, etc.
Black traffic from specific countries.
The traffic rules can be targeted to the Author or Publish tier or both together. You can also apply various operations — like equals, doesNotEquals, in, matches, etc. The CDN responds with a 406 return code if a rule is matched and blocked.
The traffic rules can be managed through a YAML file and deployed separately through the Cloud Manager Config pipeline to Non-prod and prod environments. Create a YAML file(cdn.yaml) specific to Dev environments and Stage/Prod environments, separate into different folders, e.g., Config-Dev/cdn.yaml and Config-Prod/cdn.yaml; the config files can be managed through a separate repository or within a Dispatcher module repository, crate config pipeline specific to dev and stage/prod environments and point to the corresponding config folder along with repository, branches and other configurations.
A WAF helps protect web applications by filtering and monitoring HTTP traffic between a web application and the Internet. It typically protects web applications from attacks such as DDOS, cross-site forgery, cross-site scripting (XSS), file inclusion, and SQL injection. A shield is placed between the web application and the Internet by deploying a WAF in front of a web application. The WAF operates through a set of rules that aim to protect against vulnerabilities in the application by filtering out malicious traffic.
The WAF rules/flags, e.g., XSS, SQLI, LOG4J-JNDI, can be enabled along with the other traffic filter rules explained above. The WAF rules can be enabled through the same cdn.yaml file and the Config pipeline.
The WAF traffic filter rules require either an Enhanced Security license or a WAF-DDoS Protection license.
Mod_security is an Apache module that helps protect your website from various attacks. Mod_security acts as a Web Application Firewall (WAF) that filters and blocks known malicious HTTP requests. Blocked HTTP requests include many, but not all, forms of Brute Force, Cross-Site Scripting (XSS), Remote File Inclusion (RFI), Remote Execution, and SQL injection (SQLi) attacks. By default, the mod security module is enabled on AEM as a Cloud Dispatcher (Apache), but the required rules and configurations can be enabled based on your needs.
IP allowlisting is a way of giving trusted individuals access to the business network. With an IP allow list, the network administrator can allow specific IP addresses to access your files, applications, and software remotely.
AEM as a cloud service is, by default, accessible via the internet. While security is handled through user authentication and authorization, IP allow-listing is a way to limit access only to trusted IP addresses. Cloud Manager’s IP allowlists can be used to limit and control access only to such trusted IP addresses.
Cloud Manager users with appropriate permissions can create allowlists of trusted IP addresses from which their site’s users can access their AEM domains. After adding IP allowlists — Enter an IP or IP CIDR block that can be applied/unapplied multiple times as a unit or entity to an author and/or publisher service in an environment. For instance, this would be helpful if you wish to allow access to your Author environment from your company’s network, VPN, or VDI but block external access.
CDN uses the IP Allowlists defined in Cloud Manager to block the incoming requests for a specific environment/tier. The IP Allow lists defined in Cloud Manager take precedence over Traffic Filters Rules.
Advanced Networking:
AEM as a Cloud Service provides advanced networking features that allow for precise management of connections to and from AEM as a Cloud Service program.
AEM as a Cloud supports various networking configurations, including — Flexible Port egress, Dedicated egress IP address, and VPN.
Virtual Private Network (VPN) allows an AEM as a Cloud Service customer to connect the AEM environments within a Cloud Manager Program to an existing, supported VPN. This allows secure and controlled connections between AEM as a Cloud Service and services within the customer’s network.
Flexible port egress allows for custom, specific port forwarding rules to be attached to AEM as a Cloud Service, allowing connections from AEM to external services to be made.
The dedicated egress IP address allows requests from AEM as a Cloud Service to use a dedicated IP address, allowing the external services to filter incoming requests by this IP address.
The request can also be restricted at the dispatcher layer by the /filter section to specify the HTTP requests the Dispatcher accepts. All other requests are sent back to the web server with a 404 error code (page not found). If no /filter section exists, all requests are accepted.
The /filter section consists of a series of rules that either deny or allow access to content according to patterns in the request-line part of the HTTP request. Use an allowlist strategy for your /filter section:
HIPPA (Health Insurance Portability and Accountability Act) Compliance:
HIPAA compliance ensures the protection and confidential handling of patient health information, adhering to strict standards set by the Health Insurance Portability and Accountability Act.
Adobe provides healthcare customers with services that are ready to accept PHI, referring to these services as HIPAA-Ready Services. These HIPAA-Ready Services have additional features and functionalities that allow both customers, Covered Entities or Business Associates, and Adobe to comply with their respective HIPAA obligations.
The Adobe Experience Manager (AEM) as a Cloud Service is part of the HIPPA-ready service provided by Adobe.
Additional licensing is associated with enabling the HIPPA-ready service for the AEM as a Cloud service.
Mutual Transport Layer Security (mTLS) authentication from AEM:
AEM supports integrating with the external APIs that require mTLS authentication. The mTLS or two-way TLS authentication enhances the security of the TLS protocol by requiring both the client and the server to authenticate each other. This authentication is done by using digital certificates. It is commonly used in scenarios where strong security and identity verification are critical.
AEM’s Developer Console grants access to Service Credentials, which are production-ready service-to-service access tokens used to facilitate external applications, systems, and services to interact with AEM Author or Publish services over HTTP programmatically. Also, Local Development Access Token can be used by developers building integrations that require programmatic access to AEM as a cloud service needs a simple, quick way to obtain temporary access tokens for AEM to facilitate local development activities. To satisfy this need, AEM’s Developer Console allows developers to self-generate temporary access tokens that can be used to access AEM programmatically.
All data in transit between AEM as a Cloud Service and external components is conducted over secure, encrypted connections using TLS 1.2 or greater. The cloud service provider encrypts all data at rest.
AEM as a Cloud Service also has a FIPS-approved crypto library and support for encryption keys to crypt all the critical data present in the cloud repository.
In AEM as a Cloud service, the environment-specific configurations can be enabled using the Cloud manager environment variable. Two value types can be enabled — secret values and standard variables. The secret values can be centrally managed through Cloud Manager UI rather than managed through the code base to improve security; the secret variables can be referred to OSGI services, JAVA code, etc.
The AEM as a Cloud Service security model includes tenant and node-level isolation for all services. Each AEM as a Cloud Service tenant exists within its own isolated namespaces, including its own networking policies, computing, and storage.
AEM as a Cloud Service integrates Adobe Identity Management Service (IMS) for user verification. Various other Adobe products, including the Adobe Admin Console, also utilize this IMS authentication method. For AEM Authors in AEM as a cloud service, Adobe IMS authentication is activated, a change from previous AEM versions where identity and access management (IAM) settings had to be implemented individually on each AEM author server. With AEM in the cloud, single sign-on (SSO) configurations for AEM Authors and user and group management are centrally handled through the Adobe Admin Console using Adobe IMS.
Security headers are HTTP response headers that define whether a set of security precautions should be activated or deactivated on the web browser. The security headers can be enabled through the Dispatcher (Apache) layer also; if required, some of the security headers can be directly enabled through the AEM publisher,
Cross-site scripting (XSS) allows attackers to inject code into web pages viewed by other users. Malicious web users can exploit this security vulnerability to bypass access controls.
AEM applies the principle of filtering all user-supplied content upon output. Preventing XSS is given the highest priority during both development and testing.
It is important that you adapt this configuration to your own security needs by overlaying the configuration file. The official AntiSamy documentation provides you with all the information you need to implement your security requirements.
Protect against Cross-Site Request Forgery Attacks
Cross-site request forgery (CSRF) is a web vulnerability that lets a malicious hacker trick the victim into submitting a request that allows the attacker to perform state-changing actions on behalf of the victim.
AEM uses CSRF tokens, and the Sling Referrer Filter — Adobe Experience Manager’s Referrer Filter enables access from third-party hosts to protect the websites from CSRF attacks.
In summary, security is essential in the cybersecurity landscape for any platform or website. It is imperative that every platform implements necessary measures to safeguard both the platform and user data. As a cloud service, AEM offers multiple layers of security configurations to protect the platform, enabling these configurations as needed.