DSXchange

We are having some first-time learning curve questions in providing a REST 2.0 ISD application (method GET, format JSON) for testing purposes. Just entering the service URL in the web browser works fine.

Is our service Cross-Domain Script Enabled? I couldn't find anything in the ISD documentation about this. All the search results in Knowledge Center relate to Information Analyzer. Best I could guess is that I assume it is... Developer reports this response from their AJAX function that calls our service:

{"httpStatus": 403, "msgId": "CDISF0003E", "msgSeverity": "Error", "msgText": "The IIS session token is invalid."}

Google and IBM Support Portal don't provide any results when searching on "CDISF0003E". It looks like a WAS error code to me. Maybe search is broken right now.

I found these entries in the SystemOut.log file on our server. I substituted in the ... parts.

Again, searching on the "00004c61" code gave no results.

[12/15/16 17:20:17:136 EST] 00004c61 SessionFactor E Possible Cross-Site Request Forgery Attack. Request URL: https://...server...:9443/wisd-rest2/...app.../...svc.../...op1... HTTP Referer Header: http://localhost:56093/Home/Index"

[12/15/16 17:20:17:136 EST] 00004c61 SessionFactor E com.ibm.iis.isf.security.impl.SessionFactory isXsrfSafe Possible Cross-Site Request Forgery Attack. Request URL: https://...server...:9443/wisd-rest2/...app.../...svc.../...op1... HTTP Referer Header: http://localhost:56093/Home/Index.

No idea...but I suspect it may be a WAS thing. Are you, by chance, trying to also make that REST call from inside of Information Server somewhere (like from IGC itself?)....

Ernie

I just now tried entering the service URL into a web browser running from on Info Server. That works fine, same as from the web browser on my PC. I'm just not clear at this point, with searches coming up empty, if this should be my headache or the developer's headache to resolve.

Hi qt_ky,

Check this Tech Note, might help to mitigate the issue, specially if your servers are behind a firewall:

http://www-01.ibm.com/support/docview.w ... wg21979949

Regards

Hi qt_ky,

Check this Tech Note, might help to mitigate the issue, specially if your servers are behind a firewall:

http://www-01.ibm.com/support/docview.w ... wg21979949

Regards

Thank you Julio for the tech note link. So, there is a way to disable such cross-domain script checking, but for security reasons it's a bad idea to turn this off permanently.

It's looking like this problem is related to a particular technology--the jquery ajax function ( http://api.jquery.com/jquery.ajax/ ). I just found out that the same developer is able to call the same service using a different programming language with no errors. I don't get it yet, but, we have a workaround! Thanks.