We're using URL hashes in some places in our app to filter the display, e.g. #highlight=free will highlight our free content. We use javascript to process the hash, listen to hash changes. All works great.
We're wondering however about the best way to mix it with "real" HTML anchor links. i.e. links that point to a specific html id on the page, e.g. #chapter-5.
Should we implement jumping to the right place using javascript and stop relying on the default browser behaviour? for example, link to #chapter=chapter-5&highlight=free and handle both filter and anchor in javascript? Or is there a safe/standard way to "mix" anchors and custom hashes?
If your target environment allows it, then the "safe/standard way" would be to leave hashes with old-school hash (commonly seen as "hashbang") approach alone for regular in-page anchors and use modern HTML5 history API instead.
If you must support older browsers you can use some polyfill that resorts back to that hash.
The comments to the question were probably the most helpful so far, and so we chose to implement anchor jumping and deal with everything after the # in javascript, and not rely on built-in support in browsers for it.
For those interested, we use a combination of jquery.deparam, URI.js and some custom code to listen to hash changes and hook into our own functions. We also played with Hasher.js which looked nice, so we might use it in future.
Related
I have a website that is only accessible via https.
It does not load any content from other sources. So all content is on the local webserver.
Using the Retire.js Chrome plugin I get a warning that the jquery 1.8.3 I included is vulnerable to 'Selector interpreted as HTML'
(jQuery bug 11290)
I am trying to motivate for a quick upgrade, but I need something more concrete information to motivate the upgrade to the powers that be.
My question are :
Given the above, should I be worried ?
Can this result in a XSS type attack ?
What the bug is telling you is that jQuery may mis-identify a selector containing a < as being an HTML fragment instead, and try to parse and create the relevant elements.
So the vulnerability, such as it is, is that a cleverly-crafted selector, if then passed into jQuery, could define a script tag that then executes arbitrary script code in the context of the page, potentially taking private information from the page and sending it to someone with malicious (or merely prurient) intent.
This is largely only useful if User A can write a selector that will later be given to jQuery in User B's session, letting User A steal information from User B's page. (It really doesn't matter if a user can "tricky" jQuery this way on their own page; they can do far worse things from the console, or with "save as".)
So: If nothing in your code lets users provide selectors that will be saved and then retrieved by other users and passed to jQuery, I wouldn't be all that worried. If it does (with or without the fix to the bug), I'd examine those selector strings really carefully. I say "with or without the bug" because if you didn't filter what the users typed at all, they could still just provide an HTML fragment where the first non-whitespace character is <, which would still cause jQuery to parse it as an HTML fragment.
As the author of Retire.js let me shed some light on this. There are two weaknesses in older versions of jQuery, but those are not vulnerabilities by themselves. It depends on how jQuery is used. Two examples abusing the bugs are shown here: research.insecurelabs.org/jquery/test/
The two examples are:
$("#<img src=x onerror=...>")
and
$("element[attribute='<img src=x onerror=...>'")
Typically this becomes a problem if you do something like:
$(location.hash)
This was a fairly common pattern for many web sites, when single page web sites started to occur.
So this becomes a problem if and only if you put untrusted user data inside the jQuery selector function.
And yes the end result is XSS, if the site is in fact vulnerable. https will not protect you against these kinds of flaws.
I'm trying to release content by role within a topic in D2L's LMS. Is this possible using Javascript? Something like, "if {RoleName}=Student, then display this, else display that"...? I realize I can restrict/release content by role on a topic level, but I'm trying to do so within a topic and thus can't use release conditions. Any ideas?
You can control that functionality directly through the Content tool interface without needing to add in JavaScript. If you don't have access to that in Content, talk to your site administrator.
A roundabout way to do this would be to parse the QueryString to get the OU, then make a Valence request to find out the user role in the course. It would take a lot of work to get all the pieces connected for what seems like a really simple use case. This is the strategy I'm using for tools I've made that get embedded right in D2L pages.
If Replacement Strings worked properly then you could use a combination of them and JavaScript. But since the replacement happens at save time rather than render time in most places, they're really not usable for your scenario.
Desire2Learn Replace Strings in Content
Another option would be to create your own custom widget and put it on the course home page. Since Replacement Strings work properly in widgets, you could read the value of the {rolename} replacement string and store it in a cookie. Then, in your pages you would read the value of the cookie to create your conditionals.
Does anyone have a good solution for getting and setting variables in window.location.hash?
Take a URL that looks like this:
domain.com/#q=1&s=2
What I'd like is an unstressful way - JavaScript or jQuery - to check the values of q and s when the page loads, and change them following events on the page.
I have found some code for getting hash variables, but nothing sensible for setting them.
Am I missing something really obvious, or do I need to roll my own solution (and release it!)?
Thanks.
Haven't used it but there is jHash
jHash allows you to work with the
'location.hash' value in a similar
fashion to a server-side query string.
This library utilizes the HTML5
"onhashchange" event, but also
includes a fall back to still allow
the change notifications to work
properly in older web browsers.
jQuery BBQ can do this.
See also:
Get URL parameter with jQuery
Get QueryString values with jQuery
Edit as #gonchuki points out, jQuery.query can also do this.
JHash didn't work for me in that I wanted it to trigger the routes right away. I personally used routie instead.
It lets you do advanced routing just like jHash but will trigger on page load correctly.
Below will match example.com/#users/john
routie('users/:name', function(name) {
//name == 'bob';
});
I use 'window.location.hash' to add '#something' to the URL without refreshing the page.
I want to know how to do the same but using a slash (/) instead of hash (#).
Why? I have navigation tabs and I use a jQuery and Ajax to dynamically load the data. When javascript is enabled, '#something' is added to the end of the URL to get the data. When javascript is disabled, it redirects to '/something'. So I want to fake the same URL for both.
Instead of http://site.com/section#something -> http://site.com/section/something
Thanks.
You can use any combination after the hash you want, but the answer to your question is no, you can't do what you're asking without re-directing the user.
Being able to play with the URL without re-directing would be a security concern on some levels (can you change the domain too? why not?....see where this rabbit hole goes?). For example changing your URL via JavaScript to say: http://www.mybank.com (why isn't my bank using SSL? bad bank, bad!) would be a phishers dream...so browsers don't allow messing with the URL like this at all...not without actually taking you there.
Take a look at this article. Basically, it lets you do this:
history.pushState({}, 'New Title', 'new_page.html');
This updates the history and the location bar but not actually load the page. That's what you want, but it's part of HTML5, and few (if any) browsers support it at the moment. Sticking with hashes is a better idea.
History.pushState (see the link in #Casey's post, or Kyle Scholz' blog) is present in the latest versions of Safari and Firefox, and Modernizr 1.5 now tests browser support for it. I just starting playing around with this today and it appears to do exactly what you want.
I realize this doesn't help with older browsers; some kind of window.location.hash trick will still be needed there.
Why don't you deploy SWFAddress?
It does get you URLs in the form of ../#/section/something and should be pretty much what you need. It's widely used for many Flash/AJAX websites on SEO considerations.
I need to link to a page that uses javascript to create the appearance of different pages. Each of the links on the page I am pointing to calls a javascript function that produces the "new" page. So, if I just link to the page, I get the default configuration. But what I need to link to is a particular configuration after the js function has run.
At first I thought I would be able to append the function to the url, but apparently that functionality is not supported for security reasons (is this correct?). Is it possible to post the values?
Does anyone know how I can display the correct configuration?
In the general case, no, it's not possible, which is why these sort of JavaScript-only pages are an inaccessible, unusable total pain in the neck and people should stop creating them, the idiots.
If you are lucky and the site you're talking about has actually Done It Properly, then they'll have used #fragment navigation, so when you click a link it does a history-able and bookmark-able navigation, updating the URL to one with a #something at the end that you can use to navigate back there. If you're really lucky, there might even be a fallback URL for non-JavaScript browsers that you could link to. But more often all there is is a JS function, which you can't link to or invoke outside of that site, leaving you quite out of luck should you want to deep-link anything.
(Did we learn nothing from the <frame> fiasco, guys? All you trendy webmasters hacking up clever-clever swooshy jQuery-animated load()-powered multiple-pages-in-one sites are churning out rubbish that is no better than the frame-addled worst of the Netscape 3 era. Stop it. Seriously.)
Okay, I was given the solution by a friend. It seems I should answer my own question. In fact, I felt a little silly once I saw how simple the solutions was. I just forgot how to plant "posts" in a URL. It seems the question itself was erroneous.
All I really needed to do was set some Javascript variables in a page I don't own. Solution looks something like this.
http://www.apage.com/control.aspx?var1=someVal&var2=someVal...&varn=someVal
Thanks to those who responded.
The owner of the page could do you a favour and provide a mechanism to run functions depending on a value in the querystring.
Otherwise there may be something that can be done with ajax but it could be messy.