Add JSONP support to the modConnectorResponse #12420
Conversation
When returning an array from a processor->process function, the modConnectorResponse can turn that into a nice JSON response. With this patch, it can also support JSONP by looking at a "callback" get parameter, and returning the json wrapped in that.
|
👍 |
|
@Mark-H I am a bit concerned about the security implications here, probably because I do not understand the problem this solves in the first place. Can you provide some example of the issue this addresses? As is, I want to reject this, but I'd like to better understand the risk versus benefit here before I make any decision. |
|
Re: |
|
The problem this solves is being able of talking to a connector/processor from another domain which isn't possible with "normal" AJAX because of the cross origin request limitation in browsers. With CORS headers this can sometimes be fixed but for the project I looked into this I don't think that was an option.. though I don't recall exactly why not now. I think it had something to do with an ad server of sorts. Because JSONP requests are basically script tags that are injected into the page, they can be used across domains without requiring CORS-related changes on the server. In terms of security, to the best of my knowledge after spending a fair bit of time searching the web, this does not expose anything new. The direct returning of There are discussions online about sanitising the callback function to only support alphanumerical characters, but in the way I understand those, that does not add any actual security because the client provided it, and if the client can provide a malicious string as callback, it can do much worse things. This change also does not affect anything server-side like authentication and the |
|
Fair enough @Mark-H and thanks for the additional explanation — that makes me feel more comfortable with the change. |
When returning an array from a processor->process function, the modConnectorResponse can turn that into a nice JSON response. With this patch, it can also support JSONP by looking at a "callback" get parameter, and returning the json wrapped in that.
This makes it easier to use the connector/processor approach for cross-site stuff, while also allowing the $modx->runProcessor response (modProcessorResponse) to remain useful from within snippets or stuff like that. The approach to JSONP prior to this patch would be to prepare the specific JSONP format in the process() function of the processor, after which you'll need to strip it out again if you want to re-use the processor through $modx->runProcessor(), which sucks.
I have some slight concerns if there may be security implications by adding this, discussed below, but all considered I think it is a safe addition.
$_GET['callback']without sanitisation - that could potentially be used to inject arbitrary javascript into the response, but given that javascript would be executed on the requester, any hypothetical attacker would already have access to run arbitrary code or XSS on that requester. Also, sanitisation could break a legitimate callback, so some comments you see online are that you should just make sure it is valid, and return a 400 Bad Request if it isn't.