Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Patch file allows wrapping of JSON in a callback function, making it true JSON/P server
Comment | File | Size | Author |
---|---|---|---|
#28 | json_server2.module.patch | 8.04 KB | primerg |
#28 | json_server2.module.txt | 7.38 KB | primerg |
#25 | json_server.module.patch | 7.47 KB | primerg |
#25 | json_server.module.txt | 6.82 KB | primerg |
#22 | json_server-jsonp-support-3.patch | 4.94 KB | nicholasThompson |
Comments
Comment #1
bbttxu CreditAttribution: bbttxu commentedComment #2
andremolnar CreditAttribution: andremolnar commentedI'm not opposed to the change, but I don't
think this functionality should be enabled by default.
What would you say to having this be:
a) off by default with an admin option to turn it on
Admins that know they want this on will turn it on and understand what
they are getting themselves into. If the admin wants to be malicious,
they have to jump through one more hoop before unleashing a plague on
the users of their service.
b) more validation of the value of the callback parameter
Not that it really really really matters since the requester is
obviously in control of the page already, but what if they formed their
request like this:
var hello = function(data,response) {
console.log(data);console.log(response) };
$.get('http://example.com/something.php',
{'id':18,'callback':'alert("I like cheese");hello'}, null, 'jsonp' );
c) allow the admin to specify what the name of the expected parameter is
when a client sends a request with a 'callback' (with a default name of
callback).
This is kind of sort of security through obfuscation where the client
would need to know the name of the param to make a successful jsonp
request (instead of just being able to guess that passing
'callback':'somefunction' works, the would need to know that
'custom-method-name':'somefunction' is what they need to do).
Comment #3
abritez CreditAttribution: abritez commented..subscribing
Comment #4
abritez CreditAttribution: abritez commentedhas anyone had luck getting this to work? Not having much luck here. Not sure if i am missing anything. Would you happen to have a simple example calling system.connect? Using json_server 6.x-1.x-dev w/ the latest Services 6.x-0.15
Thanks for any help on this
Alex
Comment #5
andremolnar CreditAttribution: andremolnar commentedJust updating the status on this- the existing patch does not address everything in #2
Comment #6
nickvidal CreditAttribution: nickvidal commented@andremolnar
I disagree. I don't believe you understand how JSONP works. There is no security problem by letting the client define the callback. In fact, that's what JSONP is all about. And this is how it's done by everybody, including Yahoo, etc.
The modification is quite simple, actually, and a client can consume pure JSON simply by not setting the callback. Please see the modifications here:
http://drupal.org/node/624898
Comment #7
andremolnar CreditAttribution: andremolnar commented@nickvidal
I think maybe you misread my comments.
The client obviously needs to define the callback function name. I was saying the server admin should have the option of saying what the name of the expected parameter is for the server to respond.
The name 'callback' is a sensible default
$.get('http://example.com/something.php', {'id':18,'callback':'hello'}, null, 'jsonp' );
But lets say the site admin only wants to send back a JSONp respone to the word 'foo' and not the word 'callback'. The above call wouldn't work, but the one below would.
$.get('http://example.com/something.php', {'id':18,'foo':'hello'}, null, 'jsonp' );
I'm just saying that we add that administrative option to the module. Was hoping someone would roll a patch with that.
andre
Comment #8
nickvidal CreditAttribution: nickvidal commentedThat would make things just more confusing. Indeed I misread your comment because I didn't even think that someone would suggest this. The 'method' and 'callback' are pretty standard names. That solves issue (c).
As for issue (a), again: the client can consume pure JSON simply by not setting the callback.
As for issue (b), it really doesn't matter...
Please look at the simple changes to the json_server.module attached.
Comment #9
yajnin CreditAttribution: yajnin commentedWhat was the outcome of this discussion? +1 JSON/P
Comment #10
yajnin CreditAttribution: yajnin commentedDeleted my comment as it didn't make sense. Not even to me a few weeks later :P
Comment #11
yajnin CreditAttribution: yajnin commentedJSONP + JSON Server Reference Information
====================================
Please refer to other discussions and JSONP examples:
Updates on this topic
++++++++++++++++
See Issues threads for further discussion regarding inclusion of JSONP in JSON Server
- - > http://drupal.org/node/624898
- - > http://drupal.org/node/598358
+
See tips for getting JSONP working with JSON Server 6.x-2.0-alpha1 (below)
- - > http://drupal.org/node/624898#comment-2858192
+
See more discussion from people using it (as well as general JavaScript info, as well as MooTools info)
"JavaScript and Services: JSON Server + JSON + JSONP // + MooTools // Discussions"
- - JSONP info begins about half-way down
- - > http://groups.drupal.org/node/24372
+
See an example of using JSONP (with MooTools) for node.save, node.update
http://drupal.org/node/774116
Comment #12
voxpelli CreditAttribution: voxpelli commentedI'm very much in support of andremolnar on this one - the points made in #2 are all valid and should be fixed in the patch.
It is a potential security issue to have JSONP-support for an API - you need to be more careful with which resources you expose when it's active.
I marked #624898: GET/POST + JSON/JSONP as a duplicate of this issue since they was both dealing with the same issue.
Comment #13
voxpelli CreditAttribution: voxpelli commentedComment #14
yajnin CreditAttribution: yajnin commentedIn my use case, the risk is a non issue as I'm in control of the domains. The need is valid.
Beyond my use case, I completely agree with #2 and #12. It should be optional. And in the defense of those who need it, you shouldn't need to hack for this option.
Comment #15
yajnin CreditAttribution: yajnin commentedHey everyone,
On the topic of the OP, JSONP, I'm sharing information, but with security warnings:
JavaScript - JSON Server & Request.JSONP (MooTools Example)
http://drupal.org/node/791922
If people take the warning seriously, here is where I direct them to:
JSON Server & Request.JSON (MooTools Example)
http://drupal.org/node/522942
// ## General Info, Re Patches
Was just helping out a guy using Flash, and thought I'd plug converting over to JavaScript. I've been throwing down resources for JS, because, well, it kicks ass.
Once I get through the next little bit of work ninjay-side, I'll look at sharing some patches for review. For this module and Services.
In the meantime, I'd appreciate if everyone can start looking at some of these docs I'm writing for Services.
http://drupal.org/node/762088
//
As Apple, Google and Microsoft have all but made Flash look like a long-term loser... I think we JavaScripters can raise Services and Drupal's profile with some easy service wrapper apps.
I've been working with Drupal for the past 5 or so years and on the fringe of services for a year +. I've been pretty focused now for about 6 or 7 months. And these days, it is my everyday.
I'll be releasing some MooTools modules to the wild that will work directly with Services and JSON Server. It'd make life easier for many people wanting Flash-like capability with plain old JavaScript. It's essentially a branded framework, as part of the Drupal community. I would eventually like to release it for jQuery as well. It's been built to make porting it really easy.
In the meantime, if I can get some official support on JSONP, and if I can help in any way, please let me know.
Cheers
Comment #16
yajnin CreditAttribution: yajnin commentedThoughts re Approach, Permissions
// JSON Server
// Perhaps JSONP should become a separate module, under the same dev banner as JSON Server?
// // JSON P Server
// Services
// // In an ideal world this would have top-down support from the Services team
// // and other Services modules
Thoughts?
Comment #17
sanduhrsBased on #624898: GET/POST + JSON/JSONP
Attached is a patch that that in response to #2 implements:
a) Additional settings on admin/build/services/settings to let admin activate JSONP support
b) Validates the callback parameter to be [alnum]
c) Additional settings on admin/build/services/settings to let admin define a name for the callback parameter
Probably needs some more elaboration:
b) Should provide a descriptive error message, instead of falling back to standard JSON.
c) Callback parameter name should be validated
Is this the way to go?
Comment #18
sanduhrsSorry, too fast–see corrected patch.
Comment #19
sanduhrsSmall update.
Comment #20
skyredwangIt looks like someone has already forked this project and added JSONP support. http://drupal.org/project/jsonp_server
Comment #21
nicholasThompson@skyredwang: they forked it back in April, but there is still no code for it.
Gonna test this patch now...
Comment #22
nicholasThompsonThe patch seems to work very well. Attached is basically the same patch with a minor tweak to the admin form (like making the descriptions more helpful).
I personally think this is RTBC. The idea of whitelisting the callback values sounds like a good "phase 2" addon, but on the other hand I dont see what it would achieve. Requesting the URL (even with a whitelisted callback) will still respond with the data which could then manually be processed. I can't see what it protects you against.
Comment #23
voxpelli CreditAttribution: voxpelli commentedI haven't checked that the rest of the patch is okay - but I did notice some things that I think should be looked at.
Why the name change?
By not requiring POST-requests anymore you're opening up a big XSS-vulnerability when any write operations are allowed to a service.
You need to add a separate choice for whether GET-requests should be allowed or not.
Why is there no longer a drupal_parse_json() here?
If the callback is invalid return a HTTP-error instead of JSON. The clients know how to handle javascript and http-errors but probably not json.
Add a warning of the possible XSS-vulnerabilities that comes with JSONP - eg. that other sites can read personal data regarding the logged in user if a service that enables that has been activated.
It's called JSONP and nothing else. Every other spelling should be replaced with JSONP.
Remove these variables on uninstall.
Powered by Dreditor.
Comment #24
jazzdrive3 CreditAttribution: jazzdrive3 commentedSo can key authentication still be used with jsonp? How would this be done?
I assume it's something like what is done here: http://blog.soniccode.com/php/drupal-connected-iphone-application-using-...
But I really don't understand the whole key authentication stuff. Like, why is the nonce just a random number? The rabbit whole goes deep indeed...
Thanks!
Comment #25
primerg CreditAttribution: primerg commentedI am using this module for a jsonp call and I used the patches above but I encountered some error. This patch is adss fixes on those issues and also I tried to add voxpelli's comments.
Attached is the actual modified module and the patch.
primerg
Comment #26
gddI haven't looked at the patch carefully but please keep the security considerations in mind
http://www.metaltoad.com/blog/using-jsonp-safely
Comment #27
primerg CreditAttribution: primerg commentedthanks heyrocker for the note. I'll be update this with the security fix.
thanks.
Comment #28
primerg CreditAttribution: primerg commentedAdded security fix. Please review.
Comment #29
voxpelli CreditAttribution: voxpelli commentedBrief review that's not at all complete.
If JSONP can't return javascript it should return a http-code error code instead - never JSON.
Why only for JSONP?
This has nothing to do with JSONP - it's an alternate approach to cross-domain JSON calls which would be used instead of JSONP.
Also: You've got some trailing white spaces
Powered by Dreditor.
Comment #30
primerg CreditAttribution: primerg commentedIf JSONP can't return javascript it should return a http-code error code instead - never JSON.
-- i figured that might be an issue
Why only for JSONP?
-- never tested in json calls. it can be called for both if needed
This has nothing to do with JSONP - it's an alternate approach to cross-domain JSON calls which would be used instead of JSONP.
-- this was part of numerous testing that i did. but yeah, there is nothing special on those calls in terms of access control
Also: You've got some trailing white spaces
-- anything i should worry about trailing white spaces?
Comment #31
小文 CreditAttribution: 小文 commentedin 7.0 services module ,I find this url is ok! like this:http://[yousiteurl]/[yourendpoint]/[yourpath].jsonp?callback=[yourcustomfunction]