SitePoint Sponsor

User Tag List

Results 1 to 25 of 33

Hybrid View

  1. #1
    ********* Articles ArticleBot's Avatar
    Join Date
    Apr 2001
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Article Discussion

    This is an article discussion thread for discussing the SitePoint article, "Take Command with AJAX"

  2. #2
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok, I haven't really read the article, but I noticed the following:
    Code:
    if (return_xml) {
        eval(callback_function + '(http_request.responseXML)');
    } else {
        eval(callback_function + '(http_request.responseText)');
    }
    Why use eval? Eval is evil. The following works fine as well:
    Code:
    if(return_xml)
    {
    	callback_function(http_request.responseXML);
    }
    else
    {
    	callback_function(http_request.responseText);
    }
    That if the callback_function argument is a function and not a string:
    Code:
    makeHttpRequest('test.html', function(oRequest)
    {
    	alert(oRequest);
    });

  3. #3
    Grumpy Mole Man Skunk's Avatar
    Join Date
    Jan 2001
    Location
    Lawrence, Kansas
    Posts
    2,067
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I found it interesting how your code got more, rather than less, complicated as the article progressed. Less code is always better! There's absolutely no reason to use complex DOM manipulation code when innerHTML can achieve exactly the same result. Likewise, why send XML with repsponseXML when plain responseText is good enough?

    If you want an academic excuse for using innerHTML when it isn't part of a W3C standard (even though every browser under the sun supports it), here's the one I use: A web browser's principle activity is taking strings of HTML and turning them in to DOM trees. It's utterly ludicrous for that basic ability not to be exposed to developers. innerHTML exposes it.

  4. #4
    SitePoint Addict dek's Avatar
    Join Date
    Oct 2004
    Location
    UK
    Posts
    352
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Skunk
    I found it interesting how your code got more, rather than less, complicated as the article progressed. Less code is always better! There's absolutely no reason to use complex DOM manipulation code when innerHTML can achieve exactly the same result. Likewise, why send XML with repsponseXML when plain responseText is good enough?

    If you want an academic excuse for using innerHTML when it isn't part of a W3C standard (even though every browser under the sun supports it), here's the one I use: A web browser's principle activity is taking strings of HTML and turning them in to DOM trees. It's utterly ludicrous for that basic ability not to be exposed to developers. innerHTML exposes it.
    I agree that innerHTML is a great thing to have around, and I do make use of it fairly often - usually to put simple strings into elements though, and not for structure building.

    With a little judicious coding it is possible to construct full DOM element hierarchies without using innerHTML, and with very compact and neat code. I find it much tidier than using innerHTML, and not a great deal more verbose. It's just a matter of how you tackle the problem.
    Only dead fish go with the flow

  5. #5
    Grumpy Mole Man Skunk's Avatar
    Join Date
    Jan 2001
    Location
    Lawrence, Kansas
    Posts
    2,067
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've just figured out what it is that made me so uncomfortable about this idea: it's a CSRF (Cross Site Request Forgery) attack waiting to happen.

    Let's say you do set up the script without the in_array check behind an authentication system (cookies, sessions or HTTP auth). I can still delete everything on your site. All I have to do is guess the location of your exec.php script and create a page on my own site (or a public forum or what have you) containing the following HTML:

    <img src="http://yoursite.com/exec.php?command=rm -rf /">

    If I can trick you in to visiting that page while your browser is logged in to your command application I can delete every writable file on your server!

    Defending against this attack is surprisingly tricky - just using POST instead of GET (which you should be doing anyway for an application that causes changes to the state of the data on your server) isn't enough. You need some kind of token based scheme that confirms that the GET or POST request to your PHP script originated with your Ajax code. A referral check will just about do the job, but a token scheme is far more robust.

    Here's a good overview of CSRF and potential solutions: http://www.squarefree.com/securityti...pers.html#CSRF

  6. #6
    SitePoint Addict Sojan80's Avatar
    Join Date
    May 2002
    Location
    Central WI, US
    Posts
    262
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I am having a problem getting my AJAX to work in Safari using some of what is covered in the article. I've posted a problem description here http://www.sitepoint.com/forums/show...06#post2746506

  7. #7
    SitePoint Guru mattymcg's Avatar
    Join Date
    Oct 2005
    Location
    Melbourne, Australia
    Posts
    574
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks fredda. Sorry about that—the examples should all be fixed now.
    I design beautiful, usable interfaces. Oh, and I wrote a kids' book.
    Follow me on Twitter.
    Read my blog.
    Buy my book, Charlie Weatherburn and the Flying Machine.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •