1. technology and computing
2. programming languages
3. javascript

Spring 2015 Release
Developer Summary
Presenters
Tony McKenzie
Bob Shawgo
Narasimhulu Golla Dan Wilks
David Bell
CONFIDENTIAL |
1
Welcome
Today we will cover changes in the Spring 2015 release (May 15th) which are important for developers who are writing custom code to work within Intacct.
Topics we will cover:

Security enhancements

Platform enhancements

Resources for more information
CONFIDENTIAL |
2
Keeping in touch…
We recommend all developers create an account at our Developer Community site: https://developer.intacct.com.
Please be sure to enable ‘Notice’ notifications which we’ll use to communicate updates and future events for developers.
CONFIDENTIAL |
3
SECURITY ENHANCEMENTS
CONFIDENTIAL |
4
Session Management

We have added a second layer of session management in the form of a dynamic session cookie.
– The first is the session ID in visible in the Intacct URL.
– Both the session ID URL and cookie must be present to validate the current session.

You are required to be in a fully authenticated session when requesting any Intacct resource.
Impact: Low

Users who log into the Intacct user interface will have no impact.

Code which attempts to create a session ID through Intacct APIs, then use this ID to construct an URL to interact with the Intacct UI will likely fail.
– This approach will no longer be supported.
CONFIDENTIAL |
5
Cross site scripting (XSS)

Script entered into data fields is a potential risk to users. Intacct employs several techniques to eliminate the risk while supporting custom code.

All data sent from the server to the browser for display will be encoded.
Special Character

Encoded Value
Browser Display
&
&
&
<
lt;
<
>
&gt;
>
“
&quot;
“
‘
&#x27;
‘
In rich text areas (those which display a formatting toolbar), script is cleansed in such a way to not allow execution.
Impact: Medium

Script data entered in text and rich text areas will display normally, but will not execute.

To implement executable JavaScript & HTML code within Intacct, use the Script element in the page editor.
CONFIDENTIAL |
6
Content Security Policy (CSP)

The content security policy is another layer of defense against XSS.

It applies to all external resources requested on a page through the Platform page editor. 
Anytime you set a request for an external resource through a Script element in the page editor, you need to add that element’s URL to a whitelist, thus creating a (CSP). 
This allows Intacct to verify that using or displaying the external resource was intentional.
Impact: Medium

External resources loaded from within Intacct will need to have their URI whitelisted in future releases.
– In the May release, your browser will log external resources in the browser’s console to aid in identifying those resources which need be whitelisted – In the August release, this content will be blocked if not whitelisted
CONFIDENTIAL |
7
How to whitelist external URI
CONFIDENTIAL |
8
Application framing

To prevent “clickjacking” by framing the Intacct application in an iframe, Intacct sets the HTTP header x‐frame‐options to “deny.” 
This will prevent other web pages from displaying the Intacct application in an iframe. 
This change has no impact on Intacct’s ability to frame other sites using Smart Link fetch and Platform integrated link fields.
Impact: Low

If you are currently framing Intacct, it is recommended that you replace iframes with links that open Intacct in a new browser window or tab.

Framing Intacct will no longer be supported.
CONFIDENTIAL |
9
Cross Site Request Forgery (CSRF)

CSRF is an attack through a link on an e‐mail, blog, or instant message. It performs unwanted actions in the user’s browser on a trusted site to which the user is currently authenticated.

Intacct protects against CSRF with a dynamic token which is valid per user click. This ensures that the user clicking the page link or button is the user who loaded the page and the action is intended by the user.

This token can prevent the use of custom buttons you have created to save or submit an Intacct form. Impact: Medium

If you have implemented UI customizations which replace or intercept Intacct actions, such as the ‘Save’ button on forms these may no longer work.
– Intacct has other mechanisms such as Smart Events and Platform Triggers that can safely perform these actions for you.
CONFIDENTIAL |
10
Confidential information in URLs

The Intacct login page does not allow the storage of passwords with a browser bookmark.

Users need to manually enter a valid password to login.
Impact: Low

If you are using a third‐party SSO (single sign‐on) solution, please be sure you are using Intacct’s SAML SSO feature to for single sign‐on capabilities.

Intacct recommends you do not store confidential information in your bookmarks.
CONFIDENTIAL |
11
To learn more…
For more information on these changes and other best practices, please refer to:
https://developer.intacct.com/wiki/security
CONFIDENTIAL |
12
ADDITIONAL RELEASE NOTES
CONFIDENTIAL |
13
Notable changes for developers in Spring 2015
Record URLS

RECORD_URL can now be used as a merge field
Intacct Platform

Application installs that contain smart links for http triggers with invalid URLs will fail.

A ‘Reply To’ field has been added to email actions.

Date based merge fields now support both user preference and ISO formats.
– Example: {!oil_rig.start_date#iso!} returns ‘2015‐04‐07T00:00:00Z’

You can no longer import into auto‐number fields, these are system assigned.
CONFIDENTIAL |
14
Getting ready for release

Please verify your applications and customization are not impacted by these changes.

Start to whitelist external resources now in preparation for our Summer release

Contact us at [email protected] if:
– You do not have a preview environment to test these changes
– You encountered an issue with one of these changes and need assistance.
CONFIDENTIAL |
15
THANK YOU
CONFIDENTIAL |
18