I was asked during an interview to write a piece of code to highlight the url if the content of the url contains a certain keyword. I honestly do not know how I can do that with JavaScript...
I think you can firstly fetch content using ajax, search for keyword,
then highlight the url if necessary.
But this comes with limitation:
The url you want to highlight should allow cross-site ajax fetching.
performance will not be so good, since you need to fetch each url if there are many.
If the targeting url is client-side rendering, fetching its html simply won't see the content since its not render yet.
Normally we won't solve this using front-end approach, but using search-engine indexing method instead.
Related
I am developing my first website. At this time i am generating a new html design that would be a ticket.
From my main page, i will load this html when the user clicks the "See ticket" button. This html has a table which is filled on document.ready with javascript. The data used is a JSON created in the main page.
I coded a working solution using localStorage. The problem is that the next step is to convert that HTML website to PDF and the software i am using does not work properly with localStorage, so i need to pass the JSON from main page to the ticket page. I can't neither use URL encoding cause string could be sometimes longer than 2000 characters and it is not productive.
So i thought that maybe i could do and $.get call from the ticket.html to index.html and get the needed JSON. Is this approach correct, or is there any better solution?
Regards
As suggested earlier comments, you need to use serverside code to accept post params and you need to do a ajax post to send the data. This is very good approach. I have one more idea for implementing this.
Let say you open ticket.html in a window.open. And have a JS function ( say GetValue) in index.html, that returns JSON . So you need to get JSON in ticket.html.
You need to define a JS function in ticket.html , using windown.opener.GetValue() , you can get JSON value.
Hope, i am in same direction, which you need. If not, please clarify.
Other way, would be use iFrame and use message communication to pass large data between them, you are interested in this, please read this - https://developer.mozilla.org/en-US/docs/Web/API/Window.postMessage
I have a web page with some user content displayed on initial page load. There's a button that can trigger further page loads (somewhat like Twitter's infinite scrolling). The Django template that renders the original page is also used to render content for infinite scroll (partial view). The server sends formatted HTML via AJAX that can be easily inserted into my existing page like this:
$(new-Html).insertAfter($('existing-content'))
With this option, I can reuse the existing template to render my content. Is it worth the convenience and can I assume that escaping at Django's end covers me from XSS? It's this jQuery ticket that worries me. It can be dangerous stuffing all that HTML into a selector $(..)
Or, should I use JSON as response type and carefully craft all user content as text nodes with jQuery? This is a lot more work & error prone since I'll be duplicating the template rendering to a large extent. Even though this route appears a lot more safer, it's difficult to maintain two redundant rendering methods, one via template, other via JS.
update : I considered using innerHTML as suggested in one of the comments but not sure about that either : http://www.slideshare.net/x00mario/the-innerhtml-apocalypse (Mario Heiderich on mXSS)
The Django template that renders the original page is also used to render content for infinite scroll (partial view).
Therefore you are safe. If all you are doing is rendering content that you have control of and already trust for your initial page load, then there will be nothing malicious in the page source to be rendered. In this case as you are loading form a trusted source, if there was any malicious code rendered that would cause XSS then this would be an issue with the AJAX service that supplies the source, not the JQuery that renders it.
The ticket you refer to is regarding XSS WITH $(LOCATION.HASH) AND $(#<TAG>) which is different to what you are doing (and has also been marked as fixed).
Update
Use this line before passing the HTML into the jQuery it will remove any scripts (including onmouseover etc.) that are included in the HTML:
var cleansed = str.replace(/<script\b[^<]*(?:(?!<\/script>)<[^<]*)*<\/script>/gmi, "");
cleansed = cleansed.replace(/\bon\w+\s*=[\s\S]*?>/gmi, ">");
I still say that the jQuery/Django method is the ideal method. The above line will clean the content of scripts before you add it to the DOM.
Previous
Django should escape anything it's passing into that line of jQuery. So long as you aren't using an eval() statement anywhere in there, cross-site scripting shouldn't be a concern. I'd say it's more practical to continue the way you're going.
In its content attribute the blogger API returns an ugly blob of HTML. I would like to convert this HTML string data into a dom that I can parse. What is the best way to parse this text in order that I can re-render within a js widget I'm building for another website?
I'd rather not write my own parser that reverse engineers the HTML encoding that Google put into place. I'm ideally looking for a library which undoes the HTML escaping and then turns it into a dom which I can inspect with JQuery.
Apparently this question was based on some slightly false premises. I have since managed to successfully embed blogs in my website. I have been using AngularJS, which apparently escapes HTML by default before embedding it into the dom. This caused some heavy confusion from my side. The response from google is not escaped.
This means parsing it as a dom is simply a matter of calling jquery.parseHtml(). See: http://api.jquery.com/jquery.parsehtml/
Once this is done, whatever jquery transformations need to be made can be made using angularJS's JQLite by calling angular.element('').
Finally, the object can be bound to the document.
Alternatively, the raw content of the list of blog posts can be injected as an html string the regular angular way using something like this:
$scope.frontPagePosts = posts.map(function(post){
post.content = $sce.trustAsHtml(post.content);
return post;
});
Currently I am creating a website which is completely JS driven. I don't use any HTML pages at all (except index page). Every query returns JSON and then I generate HTML inside JavaScript and insert into the DOM. Are there any disadvantages of doing this instead of creating HTML file with layout structure, then loading this file into the DOM and changing elements with new data from JSON?
EDIT:
All of my pages are loaded with AJAX calls. But I have a structure like this:
<nav></nav>
<div id="content"></div>
<footer></footer>
Basically, I never change nav or footer elements, they are only loaded once, when loading index.html file. Then on every page click I send an AJAX call to the server, it returns data in JSON and I generate HTML code with jQuery and insert like this $('#content').html(content);
Creating separate HTML files, and then for example using $('#someID').html(newContent) to change every element with JSON data, will use even more code and I will need 1 more request to server to load this file, so I thought I could just generate it in browser.
EDIT2:
SEO is not very important, because my website requires logging in so I will create all meta tags in index.html file.
In general, it's a nice way of doing things. I assume that you're updating the page with AJAX each time (although you didn't say that).
There are some things to look out for. If you always have the same URL, then your users can't come back to the same page. And they can't send links to their friends. To deal with this, you can use history.pushState() to update the URL without reloading the page.
Also, if you're sending more than one request per page and you don't have an HTML structure waiting for them, you may get them back in a different order each time. It's not a problem, just something to be aware of.
Returning HTML from the AJAX is a bad idea. It means that when you want to change the layout of the page, you need to edit all of your files. If you're returning JSON, it's much easier to make changes in one place.
One thing that definitly matters :
How long will it take you to develop a new system that will send data as JSON + code the JS required to inject it as HTML into the page ?
How long will it take to just return HTML ? And how long if you can re-use some of your already existing server-side code ?
and check how much is the server side interrection of your pages...
also some advantages of creating pure HTML :
1) It's simple markup, and often just as compact or actually more compact than JSON.
2) It's less error prone cause all you're getting is markup, and no code.
3) It will be faster to program in most cases cause you won't have to write code separately for the client end.
4) The HTML is the content, the JavaScript is the behavior. You're mixing both for absolutely no compelling reason.
in javascript or nay other scripting language .. if you encountered a problem in between the rest of the code will not work
and also it is easier to debug in pure html pages
my opinion ... use scriptiong code wherever necessary .. rest of the code you can do in html ...
it will save the triptime of going to server then fetch the data and then displaying it again.
Keep point No. 4 in your mind while coding.
I think that you can consider 3 methods:
Sending only JSON to the client and rendering according to a template (i.e.
handlerbar.js)
Creating the pages from the server-side, usually faster rendering also you can cache the page.
Or a mixture of this would be to generate partial views from the server and sending them to the client, for example it's like having a handlebar template on the client and applying the data from the JSON, but only having the same template on the server-side and rendering it on the server and sending it to the client in the final format, on the client you can just replace the partial views.
Also some things to think about determined by the use case of the applicaton, is that if you are targeting SEO you should consider ColBeseder advice, of if you are targeting mobile users, probably you would better go with the JSON only response, as this is a more lightweight response.
EDIT:
According to what you said you are creating a single page application, if this is correct, then probably you can go with either the JSON or a partial views like AngularJS has. But if your server-side logic is written to handle only JSON response, then probably you could better use a template engine on the client like handlerbar.js, underscore, or jquery templates, and you can define reusable portions of your HTML and apply to it the data from the JSON.
If you cared about SEO you'd want the HTML there at page load, which is closer to your second strategy than your first.
Update May 2014: Google claims to be getting better at executing Javascript: http://googlewebmastercentral.blogspot.com/2014/05/understanding-web-pages-better.html Still unclear what works and what does not.
Further updates probably belong here: Do Google or other search engines execute JavaScript?
I load in HTML pages via Ajax. These files have no <title><head><body> tags, etc. Just a few divs inside them.
At the moment, I place links to these ajax pages in my href for browsers with JS disabled:
Honda
The javascript has return false so the user is never taken to that page physically if their browser supports javascript.
My concern is people potentially right-clicking and sending these links to other people. Which would look bad since it is unstyled, etc. I'm tempted to remove the href link because of this.
Are there alternatives to obfuscating the links? It goes against my ideals on best practices to remove the link entirely from the href.
It goes against my ideals on best practices to remove the link entirely from the href.
I strive to follow best practices as well, but what you're doing is actually worse than not including an href at all.
The href attribute should only be used for URLs that users can visit directly. Using it to hold a URL for Ajax use is common (Stack Overflow does it), but it's a misuse of the href attribute.
If possible, href should point to a full page which contains the content that would be loaded by Ajax. If you can't provide that then either remove href or set it to something like "#".
You don't need to obfuscate it and I also don't think you need to remove it. If you are using a server side language you can check for the
X-Requested-With: XMLHttpRequest
HTTP Header in each page. If it isn't set it has not been requested with Ajax. Then you can redirect the user to the right page.
One solution that would work well, but includes some work, would be to create degradation pages for the content. You could create copies of the pages that were complete HTML documents, and use their URL in the links, e.g.:
Honda
When you fetch the content using AJAX, you would replace the view in the URL with ajax.
This way the pages will also be indexed by web crawlers.
Maybe you could use the data tag to store/retrieve your value in a div with a mocklink style. FIDDLE
Something like this.
<div class="mockLink" data-link="/test/link/honda.html">Honda</div>
CSS
div.mockLink{color:blue; text-decoration:underline}
div.mockLink:hover{cursor:pointer;}
JS
$('div.mockLink').click(function(){
alert($(this).data('link')) ;
//do AJAX
});