Using the XML API with Enhanced Security

With the release of Adobe Connect 9.0.4 and beyond (view KB here), we have introduced the Enhanced Security feature (documentation) and it is ON by default on our hosted system.  If you are an Adobe Connect Hosted customer, you can toggle the Enhanced Security feature on or off (if you are an Administrator) by logging into your Adobe Connect Hosted account and navigating to: Administration > More Settings.  You will see the following Security Settings:

If you have ‘Enable Enhanced Security’ checked (and you save the settings), your account will now issue TWO session cookies to a user when they authenticate.  This is crucial to understand and plan for if you are using the XML API to integrate with another system.  Also, if you are a partner or developer who has built an application that integrates with Adobe Connect, you will need to rework your application to account for the possibility of this feature being ON or OFF.

From my experience, it is best to simply code the application to look for the second session cookie all the time (after initially authenticating the user) rather than try to check for the feature being on or off.

Typically in Adobe Connect Hosted accounts before this feature was implemented (and with this setting OFF), your application would first make a ‘common-info’ call as below, to obtain a session cookie before logging a user in:

https://myaccountURL/api/xml?action=common-info

<results>
<status code=”ok”/>
<common locale=”en” time-zone-id=”35″ time-zone-java-id=”US/Eastern”>
<cookie>naXbreezecookie123456789</cookie>
<date>2013-12-02T19:50:38.983-05:00</date>
<host>https://myaccountURL</host>
<local-host>connecthost01</local-host>
<admin-host>naXcps.adobeconnect.com</admin-host>
<url>/api/xml?action=common-info</url>
<version>9.1.2</version>
<tos-version>7.5</tos-version>
<product-notification>true</product-notification>
<account account-id=”12345678″/>
<user user-id=”45678901″ type=”user”>
<name>Jim Johnson</name>
<login>Jim</login>
</user>
<user-agent>
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36
</user-agent>
<mobile-app-package>air.com.adobe.connectpro</mobile-app-package>
</common>
<reg-user>
<is-reg-user>false</is-reg-user>
</reg-user>
</results>

Then you would log the user in:

https://myaccountURL/api/xml?action=login&login=Jim&password=XXXXXXX&session=naXbreezecookie123456789

<results>
<status code=”ok”/>
</results>

That would normally be it.

Then, all subsequent calls, you would normally just append that same session cookie as the ‘session’ parameter and you’d be all set.  However, with Enhanced Security ON, that session cookie you obtained from the first common-info call will NOT work in calls after the login call authenticates the user.  Once the login API is called, you MUST call common-info one more time immediately after the OK response comes back from the login call.  When you run common-info again, you will notice you will get a DIFFERENT session cookie value.  That second cookie value is the session you need to include in your subsequent calls going forward.  If you do not use that second value in your API call, and instead include the value from the first common-info call result, you will get the following error response:

<results>
<status code=”no-access” subcode=”no-login“/>
</results>

So in summary:

Before Enhanced Security the workflow was:

1) common-info API to get cookie session value
2) login API using the cookie session value
3) continue on making API calls with that same session cookie throughout the user session

After Enhanced Security (post 9.0.4):

1) common-info API to get cookie session value
2) login API using the cookie session value
3) common-info API again a second time to get the final cookie session value to use going forward in all other calls
4) continue on making API calls with that NEW session cookie throughout the user session

Again, it is best to code your application to always look for a session cookie again AFTER logging a user in.  That way, even if you are still using the same session (say if the account had Enhanced Security set to OFF), your application will still work fine and in the cases where the account does have Enhanced Security turned ON, it will still continue to work as expected.