request problem (translating from jQuery to Mootools)

[hartum]

Hi everyone

I am translating a script from jQuery to mootools, the script in jQuery is this:

$.ajax({
            url:'http://10.1.1.94:8080/ui-web-logger/rest/events/load',
            type: "PUT",
            data: $.toJSON(jSonObject),
            contentType: "application/json",
            crosssDomain: true
        });

And It is working fine, but when I tried to translate into mootools in this way:

var myRequest = new Request({
            url:'http://10.1.1.94:8080/ui-web-logger/rest/events/load',
            emulation: false,
            method: 'PUT',
            data: JSON.encode(jSonObject),
            headers: {'Content-Type': 'application/json'},
        }).put();

It does not work, what I miss in translation? I tried with jSONP too but it does not accept PUT method.

Could you help me please? Thank you very much.

*I could write it into jsFiddle if you prefer

[Arian Stolwijk]

Probably because you're doing a cross-domain request.

--
 
---
You received this message because you are subscribed to the Google Groups "MooTools Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mootools-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[hartum]

that's what I thought but the request is coming.

So far the only difference is that the request in jQuery is sent like "PU"T but in mootools is sent like "EMULATION".

The info is taken from browser console network.

anyway, is it possible to send a request JSONP with PUT method?

[Arian Stolwijk]

oh, you can set the "emulation" option to false.

JSONP can't do any of that, because it's basically injects <script> elements.

[Sanford Whiteman]

Hartum, something else to keep in mind: JSONP implies GET, and GET should be implemented as a safe method (safe == not substantively altering server state -- think updates to transactional databases).

This guideline should be followed _whether or not_ you are sending stuff like '&simulate_method=PUT' to clue in your back end, because it's not enough to clue in your back end, you also have to take into account a front end like a spider/accelerator/proxy/inspector that could silently replay GET requests (which are actually PUTs) and cause harm.

In other words, gatewaying updates over JSONP is possible but should be avoided; it should be for queries only. (True, redoing an emulated PUT is less harmful than repeating a POST, since PUT should be implemented as idempotent so you can't get duplicates. Still, plenty of havoc can ensue.) YMMV depending on how much you control the ecosystem.

-- S.

[Lee]

Whilst this is all true, it should be negated by your access
authentication and authorisation schema: no bot should have permission
to change anything, because no non-authorised user has permission to
change anything.

[Sanford Whiteman]

> Whilst this is all true, it should be negated by your access
> authentication and authorisation schema: no bot should have permission
> to change anything, because no non-authorised user has permission to
> change anything.

I consider HTTP method safety, method idempotence, and change
authorization to be orthogonal to each other. For example, anonymous
comments and polls, etc. all break method safety, and by definition do
not require authorization and so could easily (and wrongly) be
gatewayed via a GET.

Additionally, to work around 3rd-party cookie issues, you might try
embedding auth credentials in the GET request anyway, which means it's
replayable without user interaction

True, form-based auth w/session cookies and basic/digest auth wouldn't
be available to some random crawler, but the question isn't limited to
outside bots. If you review the Google Web Accelerator debacle you can
see that user-operated proxies/prefetchers/etc. and even debugging
inspectors should be under scrutiny as they will impersonate a
logged-in user. Then there's users e-mailing clickable links that
change data... yeah, I may sound paranoid but this is just a no-go
area for me.

-- S.

[hartum]

thank you very much to all for responding, and sorry for not writing before (I had problems with my car and I could not go to work yesterday :-P)

I saw that parameter "crossdomain:true" in jQuery script causes confusion.
Forget this parameter, today I can assure is not a crossdomain request, so no need for JSONP request.

I solve the problem by now with raw javascript:
(this code is a method in a bigger Class)

    loadXMLDoc: function(MyUrl, MyData){
        var xmlhttp;
        if (window.XMLHttpRequest){
            xmlhttp=new XMLHttpRequest();
        }else{
            xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
        }
        xmlhttp.onreadystatechange=function(){
            if (xmlhttp.readyState==4 && xmlhttp.status==200){}
        }
        xmlhttp.open("PUT",MyUrl,true);
        xmlhttp.setRequestHeader("Content-type","application/json");
        xmlhttp.send(MyData);
    }


I obviously prefer a more elegant solution based on mootools, but this code saved my day.
The thing is, how I can move this piece of code to mootools syntax?


thank you very much again for your previous answers.

Regards.

[Lee]

I used to say what you say, but I've become pragmatic, for purely
financial reasons. OTOH, I avoid JSONP like the plague for all the
reasons you've mentioned.... :)