XmlHttpRequest

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Gaz

    XmlHttpRequest

    In Internet Explorer 6 I'm having a problem with the httprequest
    object. I use it to call a webservice and display the result in the
    readystate event handler. This works the first time I call it but
    subsequently the readystate event handler function is never called, or
    the event itself is never fired.

    The same code works fine in Firefox. Changed it around a lot to no
    effect Can anyone help?

    I'm not supposed to create a new XmlHttpRequest object every time I
    want to call a remote procedure am I?

    Hope you don't mind the long post but here's the code it's simple
    enough:

    <!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN">
    <html>
    <head>
    <title> New Document </title>

    </head>

    <script type="text/javascript">

    //initiates the XMLHttpRequest object
    //as found here: http://www.webpasties.com/xmlHttpRequest
    function getHTTPObject() {
    var xmlhttp;
    /*@cc_on
    @if (@_jscript_vers ion >= 5)
    try {
    xmlhttp = new ActiveXObject(" Msxml2.XMLHTTP" );
    } catch (e) {
    try {
    xmlhttp = new ActiveXObject(" Microsoft.XMLHT TP");
    } catch (E) {
    xmlhttp = false;
    }
    }
    @else
    xmlhttp = false;
    @end @*/
    if (!xmlhttp && typeof XMLHttpRequest != 'undefined')
    {
    try {
    xmlhttp = new XMLHttpRequest( );
    } catch (e) {
    xmlhttp = false;
    }
    }
    alert("instanti ated");
    return xmlhttp;
    }

    var Request = getHTTPObject() ;

    function GetTreeOutput()
    {
    try
    {
    if( Request != null)
    {
    if (Request.readyS tate == 4 || Request.readySt ate == 0)
    {
    var sUrl = "http://itsopt-15/webgame/Service1.asmx/HelloWorld";

    Request.onready statechange = GetTreeOutput_R esponse;

    Request.open("P OST", sUrl, true);

    Request.send(nu ll);
    }
    }
    else
    {
    }
    }
    catch( e)
    {
    }
    }

    function GetTreeOutput_R esponse()
    {
    try
    {
    if( Request.readySt ate == 4)
    {
    if( Request.status == 200)
    {
    document.getEle mentById( "test").innerHT ML = Request.respons eText;
    }
    else
    {
    }
    }
    }
    catch(e)
    {
    }
    }
    </script>

    <body>

    <input type="button" value="One" onclick="javasc ript:GetTreeOut put();"
    />
    <input type="button" value="two" onclick="javasc ript:GetTreeOut put();"
    />
    <input type="button" value="Three"
    onclick="javasc ript:GetTreeOut put();" />

    <div id="test" style="border: 1px solid Black; background-color: #ddf;
    color: #003;">
    </div>

    </body>
    </html>
  • Martin Honnen

    #2
    Re: XmlHttpRequest



    Gaz wrote:

    [color=blue]
    > var sUrl = "http://itsopt-15/webgame/Service1.asmx/HelloWorld";
    >
    > Request.onready statechange = GetTreeOutput_R esponse;
    >
    > Request.open("P OST", sUrl, true);
    >[/color]

    Try whether setting onreadystatecha nge after the open call improves things.


    --

    Martin Honnen

    Comment

    • oopaevah@yahoo.co.uk

      #3
      Re: XmlHttpRequest


      Thanks that was the problem.. Cheers.

      Comment

      • Daniel Kabs

        #4
        Re: XmlHttpRequest

        Hello Gaz,

        thanks for that helpful code snippet.

        A small nitpicking though:

        Gaz wrote:[color=blue]
        > <input type="button" value="One" onclick="javasc ript:GetTreeOut put();"/>[/color]

        I think, you should leave the "javascript :" from the onlick handler. It is
        not needed or rather is is incorrect to place it there because only
        javascript code is allowed, as I know.

        Cheers
        Daniel Kabs
        Germany

        Comment

        • Daniel Kabs

          #5
          Re: XmlHttpRequest

          Hello Martin,
          [color=blue][color=green]
          >> var sUrl = "http://itsopt-15/webgame/Service1.asmx/HelloWorld";
          >> Request.onready statechange = GetTreeOutput_R esponse;
          >> Request.open("P OST", sUrl, true);[/color][/color]

          If I change the request URL to a different host than the one I fetched the
          HTML page from, sending the request
          - Mozilla throws a "Permission denied" exception
          - Internet Explorer asks me if I want to retrieve data from a foreign host.

          How can I work around this?

          Cheers
          Daniel Kabs
          Germany


          Comment

          • Daniel Kabs

            #6
            Re: XmlHttpRequest

            Gaz wrote:[color=blue]
            > try {
            > xmlhttp = new XMLHttpRequest( );
            > } catch (e) {
            > xmlhttp = false;
            > }[/color]

            In my opinion, setting xmlhttp to "false" is not a good idea, because if you
            *get* the Request Object, IE can not compare it with false:
            alert(Request == false)
            gives an error "object does not support..."

            So I'd set xmlhttp to "null" to flag an error condition (that also goes well
            together with your test in GetTreeOutput() "if( Request != null)").

            Cheers
            Daniel Kabs
            Germany

            Comment

            • Martin Honnen

              #7
              Re: XmlHttpRequest



              Daniel Kabs wrote:
              [color=blue]
              > Hello Martin,
              >
              >[color=green][color=darkred]
              >>>var sUrl = "http://itsopt-15/webgame/Service1.asmx/HelloWorld";
              >>>Request.onre adystatechange = GetTreeOutput_R esponse;
              >>>Request.open ("POST", sUrl, true);[/color][/color]
              >
              >
              > If I change the request URL to a different host than the one I fetched the
              > HTML page from, sending the request
              > - Mozilla throws a "Permission denied" exception
              > - Internet Explorer asks me if I want to retrieve data from a foreign host.
              >
              > How can I work around this?[/color]

              That is not code I have posted. You are seeing the results of the same
              origin policy as it is applied to fetching XML data, with normal
              settings your code loaded via HTTP is not allowed to load data from a
              different server.
              IE with its security zone model might allow it if the zone is configured
              to ask whether the request is allowed, if you want to change that for IE
              you can I think even configure it to allow to access data across domains
              but that is a security risk in general.
              With Mozilla in a HTTP context you would need signed script, if you load
              the page with the script making the request locally from the file system
              you can have the script request the privilege from the user e.g.
              if (typeof netscape != 'undefined' && typeof netscape.securi ty !=
              'undefined') {

              netscape.securi ty.PrivilegeMan ager.enablePriv ilege('Universa lBrowserRead');
              httpRequest.ope n(...);
              httpRequest.sen d(...)
              }
              --

              Martin Honnen

              Comment

              • Daniel Kabs

                #8
                Re: XmlHttpRequest

                Hello!

                Martin Honnen wrote:[color=blue]
                > That is not code I have posted.[/color]

                I know, but I thought you might shed light on that question and you did :-)
                [color=blue]
                > You are seeing the results of the same
                > origin policy as it is applied to fetching XML data, with normal
                > settings your code loaded via HTTP is not allowed to load data from a
                > different server.[/color]

                I don't see any problem, why it could be a security risk to allow scripts to
                access data across domains. Quite the contrary, I think scripts should be
                allowed to gather data from different hosts, e.g. the web server, database
                server, and so on.

                What did I miss here?

                Cheers
                Daniel


                Comment

                • Martin Honnen

                  #9
                  Re: XmlHttpRequest



                  Daniel Kabs wrote:

                  [color=blue]
                  > Martin Honnen wrote:
                  >[color=green]
                  >>You are seeing the results of the same
                  >>origin policy as it is applied to fetching XML data, with normal
                  >>settings your code loaded via HTTP is not allowed to load data from a
                  >>different server.[/color]
                  >
                  >
                  > I don't see any problem, why it could be a security risk to allow scripts to
                  > access data across domains. Quite the contrary, I think scripts should be
                  > allowed to gather data from different hosts, e.g. the web server, database
                  > server, and so on.[/color]

                  It can surely be desirable and not be a security risk if a certain
                  script can access data from certain different servers but in general if
                  example.com for instance uses XML data and an XSLT stylesheet to output
                  its data to its users then it could be a security risk if a script from
                  the unrelated example.org is simply able to present the data on its own
                  site perhaps spoofing example.com.
                  The same origin policy in client-side scripting certainly for some
                  people prevents uses which are not doing any harm but if you want to be
                  able to prevent abuse then you have to make a compromise and that is in
                  this case a rather rigid policy as a browser can usually not decide
                  whether example.com and example.org would agree on data exchange between
                  the sites.
                  Mozilla for web services has tried to suggest a new model where any site
                  can publish a file which declares which hosts have what access but this
                  has not really find wide spread application as far as I know:
                  <http://lxr.mozilla.org/mozilla/source/extensions/webservices/docs/New_Security_Mo del.html>

                  --

                  Martin Honnen

                  Comment

                  • Lasse Reichstein Nielsen

                    #10
                    Re: XmlHttpRequest

                    Daniel Kabs <daniel.kabs@gm x.de> writes:
                    [color=blue]
                    > Gaz wrote:[color=green]
                    >> <input type="button" value="One" onclick="javasc ript:GetTreeOut put();"/>[/color]
                    >
                    > I think, you should leave the "javascript :" from the onlick handler. It is
                    > not needed or rather is is incorrect to place it there because only
                    > javascript code is allowed, as I know.[/color]

                    I agree on leaving it out, but coincidentally, it is not incorrect to place
                    it there, merely irrelevant. The Javascript parser accepts it as a label
                    with the name "javascript ", as can be seen by this test code:

                    onclick="javasc ript:while(true ){ break javascript; }alert('Done'); "

                    Since the label is not used, it is simply wasted space and download
                    size, and should be removed.

                    /L
                    --
                    Lasse Reichstein Nielsen - lrn@hotpop.com
                    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
                    'Faith without judgement merely degrades the spirit divine.'

                    Comment

                    • Matt Kruse

                      #11
                      Re: XmlHttpRequest

                      Daniel Kabs wrote:[color=blue]
                      > I don't see any problem, why it could be a security risk to allow
                      > scripts to access data across domains.[/color]

                      XmlHttpRequests are sent just as if the user requested the URL, sending
                      cookies and everything.

                      I could write a page which invisibly requested pages from ebay, paypal, etc
                      where your stored cookie might allow you to skip the login process. I could
                      then parse the results and potentially gain access to private information.

                      Script should never be allowed to silently take actions on behalf of the
                      user, except in communication back to the same server that the user is
                      already accessing.

                      --
                      Matt Kruse



                      Comment

                      • Thomas 'PointedEars' Lahn

                        #12
                        Re: XmlHttpRequest

                        Lasse Reichstein Nielsen wrote:
                        [color=blue]
                        > Daniel Kabs <daniel.kabs@gm x.de> writes:[color=green]
                        >> Gaz wrote:[color=darkred]
                        >>> <input type="button" value="One" onclick="javasc ript:GetTreeOut put();"/>[/color]
                        >> I think, you should leave the "javascript :" from the onlick handler. It
                        >> is not needed or rather is is incorrect to place it there because only
                        >> javascript code is allowed, as I know.[/color]
                        >
                        > I agree on leaving it out, but coincidentally, it is not incorrect to
                        > place it there, merely irrelevant. The Javascript parser accepts it as a
                        > label with the name "javascript ", [...][/color]

                        _JavaScript 1.2+_[1] parsers do so, other parsers will behave
                        differently, e.g., however proprietary and (thus?) incompatible
                        the approach, the Microsoft Script Engine will parse it as a
                        selection of the script language and of the script parser to
                        be used. Some parsers (particularly those implementing only
                        JavaScript 1.0 or 1.1) may even show a script error. An
                        ECMAScript 3 compliant parser will accept it as label only.


                        PointedEars
                        ___________
                        [1] note the character case

                        Comment

                        • Daniel Kabs

                          #13
                          Re: XmlHttpRequest

                          Hello!

                          Matt Kruse wrote:[color=blue]
                          > XmlHttpRequests are sent just as if the user requested the URL, sending
                          > cookies and everything.[/color]

                          Thanks for the information, I did not consider cookies and that stuff.
                          [color=blue]
                          > I could write a page which invisibly requested pages from ebay, paypal,
                          > etc where your stored cookie might allow you to skip the login process. I
                          > could then parse the results and potentially gain access to private
                          > information.[/color]

                          Is that approach limited to scripts, only?

                          I could write a page that embedds an <img> tag and craft the src attribute
                          to contain the form values for bidding on a certain ebay auction. The
                          browser sends the HTTP request and the ebay server processes the GET
                          request as if the user requested the URL, isn't it? Of course, the user
                          will never see the resulting page but the request might be enough to
                          trigger an action to the users's disadvantage.

                          Cheers
                          Daniel



                          Comment

                          • Daniel Kabs

                            #14
                            Re: XmlHttpRequest

                            Hallo!

                            Martin Honnen wrote:[color=blue]
                            > It can surely be desirable and not be a security risk if a certain
                            > script can access data from certain different servers but in general if
                            > example.com for instance uses XML data and an XSLT stylesheet to output
                            > its data to its users then it could be a security risk if a script from
                            > the unrelated example.org is simply able to present the data on its own
                            > site perhaps spoofing example.com.[/color]

                            This "security risk" is not so different from embedding pages using iframes.
                            If example.com page outputs HTML (which is more prevalent than XML/XSLT),
                            everybody can embedd example.com on their own pages using iframes.

                            I reckon, using a cunningly designed parent page you could add your own
                            submit buttons underneath the iframe and deceive the user to click them,
                            sending a request that's completely under the control of example.org.
                            [color=blue]
                            > The same origin policy in client-side scripting certainly for some
                            > people prevents uses which are not doing any harm but if you want to be
                            > able to prevent abuse then you have to make a compromise and that is in
                            > this case a rather rigid policy as a browser can usually not decide
                            > whether example.com and example.org would agree on data exchange between
                            > the sites.[/color]

                            So the same-origin policy denies access to the iframe or scripts? I think,
                            that did not prevent anything as we have learned in the recent years
                            (phishing,...). The "bad guys" just copy the page and store it on their own
                            server.

                            The point is to divert the users to example.org in the first place. If you
                            manage that, no client-side same-origin policy can save you.
                            [color=blue]
                            > Mozilla for web services has tried to suggest a new model where any site
                            > can publish a file which declares which hosts have what access but this
                            > has not really find wide spread application as far as I know:
                            >[/color]
                            <http://lxr.mozilla.org/mozilla/source/extensions/webservices/docs/New_Security_Mo del.html>

                            If IE does not support it...


                            Cheers
                            Daniel

                            Comment

                            • Jim Ley

                              #15
                              Re: XmlHttpRequest

                              On Mon, 04 Apr 2005 10:00:49 +0200, Daniel Kabs <daniel.kabs@gm x.de>
                              wrote:
                              [color=blue]
                              >Hallo!
                              >
                              >Martin Honnen wrote:[color=green]
                              >> It can surely be desirable and not be a security risk if a certain
                              >> script can access data from certain different servers but in general if
                              >> example.com for instance uses XML data and an XSLT stylesheet to output
                              >> its data to its users then it could be a security risk if a script from
                              >> the unrelated example.org is simply able to present the data on its own
                              >> site perhaps spoofing example.com.[/color]
                              >
                              >This "security risk" is not so different from embedding pages using iframes.
                              >If example.com page outputs HTML (which is more prevalent than XML/XSLT),
                              >everybody can embedd example.com on their own pages using iframes.[/color]

                              no, this is completely wrong, the security risk is much, much higher,
                              these embedding or image src techniques are one way, you can't read
                              what you get back. This severely limits what you can do.
                              [color=blue]
                              >I reckon, using a cunningly designed parent page you could add your own
                              >submit buttons underneath the iframe and deceive the user to click them,
                              >sending a request that's completely under the control of example.org.[/color]

                              So it would submit, none of the fields would be sent from the field
                              the user entered in the other form.
                              [color=blue]
                              >So the same-origin policy denies access to the iframe or scripts? I think,
                              >that did not prevent anything as we have learned in the recent years
                              >(phishing,...) . The "bad guys" just copy the page and store it on their own
                              >server.[/color]

                              Yes, which is a completely different thing to xmlhttprequest. cross
                              domain xmlhttprequest would make phishing a very diffent activity, you
                              could just do live man in middle attacks from inside the users
                              browser, not a good idea!

                              Jim.

                              Comment

                              Working...