Why is it happening?

Blackbaud must adhere to updated PCI compliance (version 3, section 6.5.10) standards.

Who will it affect?

·         Clients or partners who rely on session information in the URL for functionality in any website, web app or mobile app.

·         Most common use case would be clients or partners who created, or had outside agencies create web sites or hybrid mobile apps which rely on URL session information to establish sessions on those sites. This would most commonly be achieved through the use of luminateExtend javascript library to interact with our APIs, use of S29:SESSION_ID stag to build custom URLs that include session information, or if a client is using our SSO API with the SDP SSO_ENABLED SDP set to ‘False’(not common use of this SDP).

·         Clients or partners who have implemented a project using the luminateExtend javascript library to interact with our APIs.

·         Blackbaud is reaching out individually to clients and partners who we have identified as potentially being affected though we recommend clients or partners who have custom web or mobile apps to review how they establish sessions between Luminate Online and those sites as soon as possible.

·         In addition to removing session specific data from the URL, a new URL parameter will be added called "NONCE_TOKEN" This is a secure one-time use token that will appear when establishing a user's session on the secure channel (https).

 

·         Previously, calling GetSSOAuthToken with a session cookie would result in no harm however going forward calling it with a session cookie now will invalidate the session as an unavoidable side-effect of our changes. If functionality you have was dependent on this, though would be an unlikely use-case to do so, then that functionality will need to be changed before sessions changes are enabled

 

How do I tell if my site has custom code that is affected?

Blackbaud cannot determine all uses of this functionality on your site because it is possible to host API code anywhere outside of Luminate Online.  If you have had custom development of content on your Luminate Online site, you can consult with the developer to see if they used the luminateExtend library or if their code uses the session data in the URL.  If you aren’t sure if you’ve had custom code developed on your site to take advantage of this, you may see this change causing custom API logins or pages that load information via from a constituent’s record to not work properly.  

Example of session information that will be removed from URLs:

https://secure2.convio.net/{SHORTNAME.EN_US}/site/Donation2;jsessionid=9D37D077649DB8FE3AED56F32D935D5B.app203a?1234.donation=form1&df_id=1234

https://secure2.convio.net/{SHORTNAME.EN_US}/site/SSurvey;jsessionid=B79009CC46BBCAA4FF3470BB11781F73.app274b?ACTION_REQUIRED=URI_ACTION_USER_REQUESTS&SURVEY_ID=1234


What will it not affect?

·         This will not affect already published links with session information in the URL (typically an accidental implementation by an admin). These links will continue to direct people to the same locations without disruption however any session information in an existing URL will no longer be active and no future urls will contain session information after the 15.5 May release. Sessions have always had a temporary lifespan where they remained active so this will most likely not affect many, if any, use cases.  

·         LO to LCMS integration will continue to function normally.  


What action do we have to take?

  • Going forward, only the use of the Luminate authentication token is needed to establish a session for use on any websites, web apps or hybrid mobile apps. Any web site or mobile app which previously used both the authentication token and a cookie to establish a session will need to be modified to only use the authentication token. How to do this is currently available via the API documentation [http://open.convio.com/api/#single_sign_on_api ]
  • Anyone who uses the luminateExtend javascript library will need to update to a new version that is now available here  

 

When does this need to be complete by?

·         The removal of session information was completed with the 17.1 release in January 2017.  The final deadline will be the 17.3 release in March 2017 for all sites to have any functionality updated and the enablement of this feature complete.


What happens if a client can’t complete changes by the 15.5 release?

·         If a partner or client feels they can’t make all the changes necessary by the 15.5 release we ask that they create a case with Support to request getting updated in a later wave.