Home › Forums › JavaScript › Prevent direct url access for Ajax loaded file?
- This topic is empty.
-
AuthorPosts
-
October 29, 2013 at 11:22 am #154488RuggParticipant
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.
October 29, 2013 at 4:05 pm #154531__ParticipantStrictly 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.
October 29, 2013 at 10:35 pm #154566__ParticipantI’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>');
October 30, 2013 at 12:29 am #154572__Participantunfortunately 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 adata-*
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
(ordisplay:none
, or whatever).October 30, 2013 at 10:55 am #154627__ParticipantIt 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.October 30, 2013 at 12:21 pm #154639__ParticipantMost 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:
<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.
October 30, 2013 at 3:02 pm #154661__ParticipantI’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?
October 30, 2013 at 5:49 pm #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 servingapplication/xhtml+xml
. But I can guess with near certainty that you’re not; and jsfiddle is definitely not).: )
October 31, 2013 at 10:40 am #154758__Participantahh… I guess jsfiddle is not at fault. Interesting
-
AuthorPosts
- The forum ‘JavaScript’ is closed to new topics and replies.