Forums

The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums JavaScript Prevent direct url access for Ajax loaded file?

  • This topic is empty.
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #154488
    Rugg
    Participant

    Does anyone know a method for denying direct url access for Ajax loaded files?

    The following code uses Ajax to append an external html file to the <body></body> of the existing file. That works as it should, but how can I block users from accessing the external file directly in the url?

    $.get('sample.html').success(function(data) {
    
        $('body').append(data);
    
    });
    

    I’ve tried denying the file using .htaccess, but that also prevents the ajax from loading the file.

    Ideas are welcome, thank you.

    #154531
    __
    Participant

    Strictly speaking, you can’t: there is no way for your server to know if a request is being made via ajax or not.

    The best way to control access would be to send a token -a unique code of some sort- to the page, and send it back with the ajax request to authenticate it. This will require a server-side language (PHP, for example) to check if the request includes the token, and to just ignore it if it doesn’t.

    #154566
    __
    Participant

    I’m wondering if it can be adapted for static html files…

    if($_SERVER['HTTP_X_REQUESTED_WITH'] ...

    That will usually work, but it’s not sure. It’s not automatic – most ajax libraries (like jQuery) send that header, but some don’t. And there’s absolutely nothing preventing anyone from sending that header with any request, ajax or not, if they decide to.

    If this is a “convenience-not-security” situation, it would probably work out fine. But, no, you could not make it work without using PHP or mod_rewrite or some other server-side language.

    is there a way to append existing content to the body without requiring an ajax call to an external file?

    Sure (as long as you already have that content), it’s no different than your example.

    $('body').append('<all your html goes here>');

    #154572
    __
    Participant

    unfortunately there’s 200+ lines of html that need to be appended…which is why I decided to load an external file with ajax…unless there is another way

    no; if the content is not already on your page (somehow), then you don’t have much choice.

    Are you aware of any mod_rewrite solutions? Every one I’ve tried prevents the ajax from loading the file too.

    You’d have to check for the header before serving that page. Same idea as in PHP, just that mod_rewrite is harder to write. I’ll see if I can figure it out for you tomorrow.

    are you aware of a method that prevents the DOM from loading an element until a JS function allows for it? I came across a solution (below) for images, using a custom data attribute …

    I’m not sure what you mean by preventing “loading an element”—in your example, the <img> element is loaded into the DOM; it simply doesn’t download the picture because the URL is missing. It’ll be the same with other elements (except that -I imagine- putting 200 lines of HTML into a data-* attribute would be fairly difficult).

    Do you really need to keep it out of the DOM? If so, you’d have to build it as a document fragment in javascript, and attach it when you’re ready. On the other hand, if you just want to keep it hidden, you could simply use … hidden (or display:none, or whatever).

    #154627
    __
    Participant

    It will be once/if web components come around (i.e., putting the content into a <template>).

    A common workaround for now is to use

     <script type="text/template">html content</script>
    

    the script tag will still be in the DOM (which is good, so you can reference it via javascript), but the contents will be ignored as gibberish text. When you want it to appear, you pull the contents with innerHTML and append it to the DOM.

    #154639
    __
    Participant

    Most javascript templating libraries (underscore.js, for example) do it this way. Yes, it seems hacky, but it works everywhere, and it actually does validate.

    In your case, an example might look like this:

    For example:

    <h1>My Empty Page</h1>
    <script type="text/template" id="htmlContent">
        <article>
            <h1>This Will Show Up Later</h1>
            <p>Hello, World!</p>
        </article>
    </script>
    <a href=# id=load>Click Here</a> to load content.
    <p id=loadhere></p>
    document.getElementById( 'load' ).addEventListener( 'click',function(){
          var html = document.getElementById( 'htmlContent' ).innerHTML;
          document.getElementById( 'loadhere' ).innerHTML = html;
    },true );
    

    I don’t know if this is the “only way,” but it’s the most standard practice. As I said, it’s usually used for templating, rather than just storing static html for later, but it’s the same thing.

    #154661
    __
    Participant

    I’m not sure what you’re doing witrh the div#wrap… Is there some reason you couldn’t simply do

    $('body').append( content );
    

    ? It produces the same DOM. Or am I overlooking something?

    http://jsfiddle.net/traq/43Pr5/

    #154677
    __
    Participant

    that would appear to be a bug in jsfiddle.

    They’re expecting xhtml input in the [html] box*. The < they’re complaining about actually belongs to the closing script tag (using an xhtml-style image tag (i.e., <img />) prevents the message). You can (should) safely ignore this warning.

    * Yes, I’m calling this a bug. Non-self-closing <img> tags are perfectly valid; more so than <img/>, in fact (unless you really are serving application/xhtml+xml. But I can guess with near certainty that you’re not; and jsfiddle is definitely not).

    : )

    #154758
    __
    Participant

    ahh… I guess jsfiddle is not at fault. Interesting

Viewing 9 posts - 1 through 9 (of 9 total)
  • The forum ‘JavaScript’ is closed to new topics and replies.