Hi I am making a chrome extension. Where I save a page to the database as a string and then open it later as a dataURI scheme like:
d = 'data:text/html;charset=utf-8'+encodeURI('HTML TEXT')
location.reload(d);
The problem with this is that the page, say its name is http://X/, in which I executed the above command loses the javascript files in its head.
I considered using the document.write(d), if d has a string appeneded to it with the <head>...</head> of http://X/.
But this opens a big vulnerability problem for XSS. At this point I am trying to think of white listing tags when I save the original page... is there another way?
I'm not sure what you mean by http://X/, but if want copied website to retain its origin (i.e. have code you give run exactly as if it were downloaded from http://X/), then I'm afraid it's not possible with standard DOM methods (it would be a security vulnerability that bypasses same-origin security policy).
If you want to run 3rd party sourcecode safely, then use this:
<iframe sandbox src="data:…"></iframe>
You could modify the source and insert <base href="http://X/"> in there to make relative URLs work properly.
Related
Is it possible to embed HTML within a URL and then render that HTML in the browser itself?
In theory, what 'm thinking of works similarly to an URL like below:
http://"<h1>Hello World</h1>"
this would show a page with "Hello World" wrapped in a <h1> tag.
Of course, I understand that the above does not work in the real world for a wide range of reasons. Is there however a a way in which I can encode data within a URL and show render that data as HTML within the browser?
I understand that you could easily set up a webserver to do this, but I am interested in a solution which would work natively without any dependencies.
It's Data URL. Data URLs, URLs prefixed with the data: scheme, allow content creators to embed small files inline in documents. They were formerly known as "data URIs" until that name was retired by the WHATWG.
Data URLs are treated as unique opaque origins by modern browsers, rather than inheriting the origin of the settings object responsible for the navigation.
Syntax:
data:[<mediatype>][;base64],<data>
The HTML:
Test
This is what a data url does.
Go to welcome page
I was sent a hyperlink to a Tableau Public link by a client. When I tried opening it, I got a 404 exception. I wrote back to the client but was told by the same that the link was working fine. I visited his profile page and was able to open the presentation there, but the URL that ended up working was slightly different than the one behind the original, non-functioning link.
Here's the anonymized URL behind the original link
https://public.tableau.com/profile/[client_name]%23!/vizhome/Project-AirportDelay/FlightPerformancesinUSA?publish=yes
And here's the URL via the profile page:
https://public.tableau.com/profile/[client_name]#!/vizhome/Project-AirportDelay/FlightPerformancesinUSA
The only differences I see are ?publish=yes and %23!. I tried appending the former, ?publish=yes, to the working URL, and it was still functional. So I suspect that it has to do with the other difference %23! vs. #!. Could the first work because he is opening it from his computer where he is likely logged onto Tableau Public? What's the difference between these syntax? Any ideas about why the original hyperlink might not be functional?
For obvious privacy reasons, I can't provide the whole URL.
It looks like the basic URL pattern for passing filters ?publish=yes
and
%23 is the URL encoded representation of #
The first # after the authority component starts the fragment component. If the # should be part of the path component or the query component, it has to be percent-encoded as %23.
As # is a reserved character, these URIs aren’t equivalent:
http://example.com/foo#bar
http://example.com/foo%23bar
There are countless ways how a URI reference could become erroneous. The culprit is often a software, like a word processor, where someone pastes the correct URI, and the software incorrectly percent-encodes it (maybe assuming that the user didn’t paste the real/correct URI).
Copy-pasting the URI from the browser address bar into a plain text document should always work correctly.
I have an email digest that is sent daily to users of my website and contains links to things on the site so that they can easily get right in and start interacting from their email. Trouble is, if they click more than one link, they're going to be opening more than one browser and the non-technical user might not catch that and end up having to close a bunch of tabs/browsers when they're done on the site. I want all the links in the email digest to be opened in the same window/tab.
I know that if you have an href you can set target=my_window and the links will open in that window. I'm wondering if there's a URL parameter that can be used instead of editing the a tag.
No. I don’t know of any browser (or other user agent) that associates any special behaviours with link query strings. The query string is for the server receiving the HTTP request to deal with.
As you say in your question, the target attribute is the method for controlling (or at least suggesting) what window the link should open in.
Can you use the window.open method?
Reference: window.open(url, name, features, replace);
It allows a browser window to be named, and thus reused when clicking on new links that are formatted to work with the window.open syntax.
Example: link
Status Update: Note you can search for many window.open(); Online Generators to help build the look of the opened window. It's important to test the desired look in all browsers, as the Address Bar in each browser is rendered differently.
The short answer is no. This behavior you are talking about is strictly client side, controlled by the browser. The application running on the web server is responsible for reacting to the query string.
Do you not have control over the template of the e-mails that are sent? It should be trivial to add the target to the appropriate anchors.
You can use PHP to catch custom URL parameters.
Say you have a link like:
www.yoursite.com/somepage.php?title=Some Page Title Here
The paramater string in the URL starts with ?something=somevalue and can be chained with the & symbol (e.g. ?something=somevalue&somethingelse=someothervalue) etc.
You can then ad this PHP to the top of your page:
<?php $title = $_GET['title']; ?>
Then for your title tag put the following:
<title><?php echo $title; ?></title>
You would add another variable with the value of the param for each param you want to pass in to the page. But for what you're trying to do, the above code will work.
I'm trying to add localization support to a Google Chrome Web App and, while it is easy to define strings for manifest and CSS files, it is somewhat more difficult for HTML pages.
In the manifest and in CSS files I can simply define localization strings like so:
__MSG_name__
but this doesn't work with HTML pages.
I can make a JavaScript function to fire onload that does the job like so:
document.title = chrome.i18n.getMessage("name");
document.querySelector("span.name").innerHTML = chrome.i18n.getMessage("name");
but this seems awfully ineffecient. Furthermore, I would like to be able to specify the page metadata; application-name and description, pulling the values from the localization files. What would be the best way of doing all this?
Thanks for your help.
Please refer to this documentation:
http://code.google.com/chrome/extensions/i18n.html
If you want to add localized content within HTML, you would need to do it via JavaScript as you mentioned before. That is the only way you can do it.
chrome.i18n.getMessage("name")
It isn't inefficient to do that, you can place your JavaScript at the end of the document (right before the end body tag) and it will fill up the text with respect to the locale.
Dunno if i understand exactly what you are trying to do but you could dynamically retrieve the LANG attribute (using .getAttribute("lang") or .lang) of the targeted tag and serve accordingly the proper values.
So I'm working on a web app, and I want to filter search results.
A nice restful implementation might look like this:
1. mysite.com/clothes/men/hats+scarfs
But lets say we want to ajax up the filtering, like the cool kids, and we want to retain deep linking, we might use the anchor tag and parse that with Javascript to show the correct listings:
2. mysite.com/clothes#/men/hats+scarfs
However, if someone clicks the first link with JS enabled, and then changes filters, we might get:
3. mysite.com/clothes/men/hats+scarfs#/women/shoes
Urk.
Similarly, if someone does not have JS enabled, and clicks link 2 - JS will not parse the options and the correct listings will not be shown.
Are Ajax deep links and non-Ajax links incompatible? It would seem so, as servers cannot parse the # part of a url, since it is not sent to the server.
There's a monkeywrench being thrown into this issue by Google: A proposal for making Ajax crawlable. Google is including recommendations for url structure there that may give you ideas for your own application.
Here's the wrapup:
In summary, starting with a stateful
URL such as
http://example.com/dictionary.html#AJAX
, it could be available to both
crawlers and users as
http://example.com/dictionary.html#!AJAX
which could be crawled as
http://example.com/dictionary.html?_escaped_fragment_=AJAX
which in turn would be shown to users
and accessed as
http://example.com/dictionary.html#!AJAX
View Google's Presentation here (note: google docs presentation)
In general I think it's useful to simply turn off JavaScript and CSS entirely and browse your website and web application and see what ends up getting exposed. Once you get a sense of what's visible, you will understand what most search engines see and that in turn will show you what is and is not getting spidered.
If you go to mysite.com/clothes/men/hats+scarfs with JavaScript enabled then your JavaScript should automatically rewrite that to mysite.com/clothes#men/hats+scarfs - when you click on a filter, they should be controlled by JavaScript meaning you'll only change the hashtag rather than the entire URL (as you're going to have return false anyway).
The problem you have is for non-JS users going to your JS enabled deeplinks as the server can't determine that stuff. Unfortunately, the only thing you can do is take them to mysite.com/clothes and make them start their journey again (as far as I'm aware). You'll need to try and ensure that when people link to the site, they use the hardcoded deeplink rather than the hashed deeplink
I don't recommend ever using the query string as you are sending data back to the server without direct relevance to the prior specified destination. That is a corruptible security hole as malicious code can be manually added to the query string to cause a XSS or buffer overflow attack at your webserver.
I believe REST was intended to work with absolute URIs without a query string, because then your specifying only a location of a resource and it is that location that is descriptive and semantically relevant in addition to the possibility of the resource being so equally relevant. Even if there is no resource at the specified path you have still instantiated a potentially unique and descriptive location that can be processed accordingly.
Users entering the site via deep links
Nonsensical links (like /clothes/men/hats#women/shoes) can be avoided if you construct your Ajax initialisation code in such a way that users who enter the site on filtered pages (e.g. /clothes/women/shoes) are taken to the /clothes page before any Ajax filtering happens. For example, you might do something like this (using jQuery):
$("a.filter")
.each(function() {
var href = $(this).attr("href").replace("/clothes/", "/clothes#");
$(this).attr("href", href);
})
.click(function() {
update_filter($(this).attr("href").split("#")[1]);
});
Users without JavaScript
As you said in the question, there's no way for the server to know about the URL fragment so filtering would not be applied for users without JavaScript enabled if they were given a link to /clothes#filter.
However, even without filtering, these links could be made more meaningful for non-JS users by using the filter strings as IDs in your /clothes page. To prevent this messing with the Ajax experience the IDs would need to be changed (or the elements removed) with JavaScript before the Ajax links were initialised.
How practical this is depends on how many categories you have and what your /clothes page contains.