Update 24C
Revision History
This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:
| Date | Module | Feature | Notes |
|---|---|---|---|
| 28 JUN 2024 | Created initial document. |
The table includes a chronological listing of document changes.
Overview
HAVE AN IDEA?
We’re here and we’re listening. If you have a suggestion on how to make our cloud services even better then go ahead and tell us. There are several ways to submit your ideas, for example, through the Ideas Lab on Oracle Customer Connect. Wherever you see this icon after the feature name it means we delivered one of your ideas.
GIVE US FEEDBACK
We welcome your comments and suggestions to improve the content. Please send us your feedback at oracle_fusion_applications_help_ww_grp@oracle.com.
DISCLAIMER
The information contained in this document may include statements about Oracle’s product development plans. Many factors can materially affect Oracle’s product development plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle.
This information may not be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates. Oracle specifically disclaims any liability with respect to this information. Refer to the Legal Notices and Terms of Use for further information.
Feature Summary
Column Definitions:
Features Delivered Enabled
Report = New or modified, Oracle-delivered, ready to run reports.
UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.
UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.
Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.
| Ready for Use by End Users Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features. |
Action is Needed BEFORE Use by End Users Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing. |
|||||
|---|---|---|---|---|---|---|
| Feature |
Report |
UI or |
UI or |
|
||
Error Log Retrieval for Webhook and Email Configuration Errors |
||||||
B2C Commerce
Admin
Error Log Retrieval for Webhook and Email Configuration Errors
With 24C, Merchants will be able to access error logs related to mis-configurations for functional webhooks and email templates. These error logs are stored in log files that roll over every day. Commerce Cloud stores 30 days’ worth of these logs files. The logs can be accessed through the existing Admin logging API(/ccadmin/v1/logging?type=merchantErrors). The Admin API logging endpoint executes concurrent REST requests to retrieve errors from each registered storefront server. The Admin API endpoint collates the results from the store requests and returns them as one JSON object. The API supports the below query parameters:
| Parameter |
Format |
Default |
Description |
| since |
ISO 8601 timestamp format OR millisecond value |
null |
The date and time to start searching from. |
| until |
ISO 8601 timestamp format OR millisecond value |
null |
The date and time to search to. |
| includeArchives |
boolean |
false |
Controls whether the search includes archived log files. |
| numArchiveFiles |
int |
7 |
Searches the most recent N archived log files. A value of 0 searches all archived log files. |
| queryText |
String |
null |
Limits the results to log entries containing the supplied query text. |
| localLogs |
boolean |
false |
It returns errors from the local log file on the administration server, without calling out to the storefront servers. You can use it to retrieve errors thrown by the storefront preview, admin and agent servers. |
- Merchants can quickly identify, and address issues related to webhooks, email templates leads to faster troubleshooting and resolution of technical issues, reducing downtime and improving overall system reliability.
- Avoids the need to log an SR to troubleshoot webhook and email mis-configurations.
Steps to Enable
You don't need to do anything to enable this feature.
Tips And Considerations
- Error logs from Admin and Agent servers can be retrieved by setting the localLogs query parameter.
- Logs can be filtered using the query parameters queryText, since and until for further drill-down. Sample usages can be found below
Sample 1:
Request: GET /ccadmin/v1/logging?type=merchantErrors&queryText=webhookError
Response:
["store1": ["**** log\tThu Apr 02 07:25:08 UTC 2024\t1709807455748\t---\twebhookError : {webhookTargetId=production-calculateShipping, message=Invalid response code of 404 received for webhook calculateShipping, webhookTargetUrl=http://testurl/ccstore/v1/testExternalShippingMethods/getTwoValidItems "]}]
Sample 2:
Request: GET /ccadmin/v1/logging?type=merchantErrors&queryText=emailTemplateError
Response:
["store1": ["**** log\tWed Apr 02 07:21:08 UTC 2024\t1708500068558\t---\temailTemplateError : {emailNotificationType=Forgotten Password, siteId=siteUS, message=Syntax error in template \"forgot_password_v2/html_body.ftl\" in line 1, column 75: Lexical error: encountered \"$\" (36), after \"#\""]}]
Platform
PCI 4.0 Compliance
The 24C release of Oracle Commerce includes support for the following DSS PCI 4.0 requirements for Storefront Classic (SF), Open Storefront Framework (OSF), and Agent Console:
Requirement 6.4.3 - All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
- A method is implemented to confirm each script is authorized.
- A method is implemented to assure the integrity of each script.
- An inventory of all scripts is maintained with written justification as to why each is necessary.
Requirement 11.6.1 - A change - and tamper - detection mechanism is deployed as follows:
- To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.
- The mechanism is configured to evaluate the received HTTP header and payment page.
- The mechanism functions are performed as follows:
- At least once every seven days OR
- Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1)
Implementation
After enabling this feature, the Commerce Storefronts (SF and OSF) and Agent Console will return a Content-Security-Policy (CSP) response header that either contains the list of allowed domains to control what scripts, styles, and images are allowed to be included, or a nonce-source matching the nonce value of an inline script. e.g. Content-Security-Policy: style-src 'self' 'unsafe-inline';img-src 'self' data:;script-src 'self' 'nonce-K81Z1OZuvJ2o9vxeQkal4gXj5X3HqLRpxo90pprLOsLVSFkpQawbHe8G+dZzV2fr' *.oraclecloud.com;
Oracle Commerce will add the following Content-Security-Policy (CSP) directives out of the box to make sure all JS / images / CSS / external connect requests are authorized.
| Content |
CSP Directive |
Default Commerce Directive Value |
Comments |
|---|---|---|---|
| Script included via script tag |
script-src |
'self' |
The 'self' directive value allows the inclusion of all JS files from the same domain. This blocks JS files if they are not from the same domain. Content-Security-Policy: script-src 'self' <script src="/client.js"/> |
| Inline script |
script-src |
'nonce-<RANDOM HASH>' |
A random nonce value is automatically included for inline scripts. Nonce values are dynamic and random for every HTTP request. Content-Security-Policy: script-src 'nonce-K81Z1OZuvJ2o9vxeQk' <script nonce="K81Z1OZuvJ2o9vxeQk"> window.state={'clientRepository':{}} </script> |
| External script |
script-src |
The domain name of the external script source |
The domain of the externally hosted script is added to the CSP header as a script-src value when configured in the Page Tags section of the Admin UI. Another option is to generate an integrity hash for the included script file and add this to the CSP header. Content-Security-Policy: script-src '*.someotherdomain.com' <script src="www.someotherdomain.com/script.js"> Content-Security-Policy: script-src ' C6RzsynM9kWDrMNeT87bh' <script src="https://someotherdomain.com/script.js" integrity="sha384-C6RzsynM9kWDrMNeT87bh"/> |
| XHR requests |
connect-src |
'self' |
The 'self' directive value allows all XHR requests to the same domain. Content-Security-Policy: connect-src 'self' |
| External XHR requests |
connect-src |
None |
For XHR requests to external domains, the domains must be specified by the customer to be added to the CSP header. Content-Security-Policy: connect-src '*.someotherdomain.com' |
| CSS styles |
style-src |
'self' |
The 'self' directive value allows inclusion of all CSS files from the same domain. Content-Security-Policy: style-src 'self' |
| External CSS styles |
style-src |
None |
For externally hosted CSS files, the external domain must be specified by the customer to be added to the CSP header. Content-Security-Policy: style-src '*.someotherdomain.com' |
| CSS inline styles |
style-src |
'unsafe-inline' |
The unsafe-inline' directive value allows inclusion of inline styles. Content-Security-Policy: style-src 'unsafe-inline' <style>h1 {color:red}</style> |
| Images |
img-src |
'self' |
The 'self' directive value allows the inclusion of all image files from the same domain. Content-Security-Policy: img-src 'self' |
| Images in base64 encoded format |
img-src |
data: |
The 'data:' directive value allows inclusion of all images encoded in base64 format. Content-Security-Policy: img-src data: |
| External images |
img-src |
None |
For externally hosted image files, the external domain must be specified by the customer to be added to the CSP header. Content-Security-Policy: img-src '*.someotherdomain.com' |
| Reporting |
report-uri |
Storefront -/ccstoreui/v1/logging/logCSPErrors Agent- /ccagent/v1/logging/logCSPErrors |
Merchants are to provide URL to report violations of the Content Security Policy. Default values are for internal monitoring purposes. |
The following instructions apply to Storefront Classic, Open Storefront Framework, and Agent Console:
- Enabling the PCI compliance setting will automatically update the CSP header with OOTB default values. Any customization to the CSP response header will continue to behave as before.
- When the PCI compliance setting is enabled, the CSP header for each site will include domains from all OOTB services. As there is no site context for Agent, the CSP header for the Agent Console will have domains from all OOTB services.
- All other externally hosted resources (Javascript, images, CSS, external XHR requests) and configured site/app (Agent) integrations will have to be updated manually as described in section External Source CSP Configuration of this document.
- When a Page Tags setting or a service is disabled or deleted, the response header will not have the corresponding URL in the CSP.
- Disabling the PCI 4.0 compliance setting will not calculate the OOTB default value for the CSP header from all sites/app (Agent). The customized CSP, if present, will continue to exist for the sites.
- Reporting for CSP violations is supported via the 'report-uri' directive. Merchants must configure report-uri to use their endpoint for logging CSP violations for their sites/app (Agent) to meet the change and tamper detection requirement. Please refer to the section External Source CSP Configuration of this document.
The following instructions apply only to Storefront Classic:
- Response headers will have a CSP with a nonce value for script-src, script-src-elem, and script-src-attr directives, if present, to allow OOTB inline JS/styling.
- The CSP header will automatically include domains from script tags defined in the Page Tags setting of the Admin UI, if a src attribute is present. If the src attribute is missing, then the script tag will render with an automatically generated nonce attribute when a page document is generated.
- For hard-coded script, style, and img tags in widgets that include externally hosted files, customers are responsible for configuring the CSP manually with the external domains. See External Source CSP Configuration.
- Customers who have customized the OOTB index.jsp must merge their changes with the latest version on index.jsp included with 24C.
External Source CSP Configuration
If externally hosted JS, CSS, image, etc. files are used in custom widgets or plugins, the external domains of those files should be added manually to the CSP header. These can be configured via the updateResponseHeaders (/ccadmin/v1/merchant/responseHeaders) API for Storefront Classic and OSF. For Agent, these can be configured via the updateAgentResponseHeaders (/ccagent/v1/merchant/agentResponseHeaders) API. Please note that updateAgentResponseHeaders does not have a site context. Please refer to the REST API documentation for Oracle Commerce for more information.
For externally hosted JS files, an integrity hash value can be optionally added to the CSP.
PCI 4.0 introduces several new features designed to help organizations better protect cardholder data in the face of evolving threats.
Steps to Enable
To enable this feature, set enablePciCompliance to true from the updateCloudConfiguration (/ccadmin/v1/merchant/updateCloudConfiguration) API. Please refer to the REST API documentation for Oracle Commerce for more information. This is sufficient to enable PCI compliance in both Storefront Classic and Agent.
To enable the PCI 4.0 compliance on Open Storefront Framework(OSF), the following additional step needs to be performed:
- Update package.json of the OSF application (e.g: core-commerce-reference-store/package.json) with the following configurations under "occ".
"occ": {
"pci": {
"enableSRI": true,
"enableSRIForExtensions": true
}
}
| Setting |
Description |
|---|---|
| enableSRI |
This setting enables the CSP header in the OSF application’s server-side rendering (SSR) response. |
| enableSRIForExtensions (Optional) |
This setting enables OSF to read <script> tags from the following locations:
OSF parses the script tag src values to get the domains of the JS files and automatically updates the "Content-Security-Policy" header. OSF generates a unique nonce value in the CSP header for HTTP requests and gets appended to inline "<script>" tags which allows the scripts to be loaded by the browser. |
Key Resources
Please refer to these external links on more information on PCI standards and Content Security Policy