Posts Tagged ‘Hash’

Fix: javascript location.hash throttling issue with IFrame

I had implemented a simple (and most importantly working in older browsers too) way of communication between an IFrame and its parent page via location.replace(“#” + hash), which doesn’t add entries to history like location.hash=… does, and the onhashchange event, when I noticed Edge-Chromium was throwing a “Throttling navigation to prevent the browser from hanging.” error and the lon/lat fields I had on my test page wheren’t updating anymore when I was dragging quickly for a while my location picker marker on an OpenLayers map. If I released the marker and tried after a sec it was starting working again.



since the URL shown in the error message redirects to some page that has permission denied, I looked up a discussion that explained the “–disable-ipc-flooding-protection” Chromium switch to turn off that protection, however I was not having any loop in my code that was mentioned in that discussion as probable cause.

On Firefox there was a similar error but with other message:


Searching about it I read about the “debouncing” concept (to avoid flooding some API with consequtive requests too fast/often) at


And ended up finding a simple implementation of it at

that I adapted to run in older browsers (like IE11) too:

function debounce(func, wait) {
  var timeout;
  return function() {
    var context = this;
    var args = arguments;
    clearTimeout(timeout); //clear previous scheduled execution if still pending
    timeout = setTimeout(function() { func.apply(context, args); }, wait);

function setLocationHash(hash) {
    window.location.replace("#" + hash); //don’t set window.location.hash directly, adds entries to browser history

setLocationHashDebounced = debounce(setLocationHash, 20);
    //this will make sure any setLocationHash calls that occur within 20msec replace any pending ones (all are timed to execute in steps of 20msec)


function markersUpdated(otherLocations) { //callback
    theOtherLocations = otherLocations;
    if (theOtherLocations.length > 0) {
        var hash = theOtherLocations[0].toString();

function hashChanged() {
    var hash = window.location.hash.substring(1);
    if (hash.length > 0) {
        var hashParts = hash.split(‘,’);
        if (hashParts.length >= 2){
            var location = [hashParts[0], hashParts[1]]; //[lon, lat]
            map_addOtherMarker(location); //Note: this will just move selected marker if existing and otherLocations.length = _maxOtherLocations > 0
             if (hashParts.length >= 3 && hashParts[2] == "zoom")

Gotcha: must set document.location.hash only at end of page in Mozilla

I just came across a different behaviour between IE and Mozilla Firefox: scripts at the former seem to execute after the page has fully rendered, while the later they seem to execute when they’re met by the page parser or something like that.

The HTML script tag has a defer attribute for running scripts after page has rendered, but that is available only for script tags that load an external script, not for embedded scripts in the HTML page. So this seems like one of those different interpretations that usually plague "standards". 

So, at the following JSP code, I was creating a table of student entries with a named anchor (bookmark) at each of the entries (each named per student id), so that when coming back from another page to that one I could tell it to scroll down to a given student automatically.

The issue was that if I placed the script that set document.location.hash to the student id, then at IE it worked OK, but at Mozilla Firefox it just moved to the top of the page even though the URL at the address bar of the browser had the hash entry (e.g. #55555) at the end and would scroll down correctly if I pressed Refresh button there.

Moving the script to the end of the page made it work for both IE and Mozilla Firefox. Don’t you love HTML’s "debug everywhere"?


<%@ page contentType="text/html" session="true" pageEncoding="UTF-8" %>

response.setHeader("Cache-Control", "no-cache, no-store"); //HTTP 1.1
response.setHeader("Pragma", "no-cache"); //HTTP 1.0
response.setDateHeader ("Expires", -1); //prevents caching at the proxy server

<%@ page import="javax.portlet.*" %>
<%@ page import="java.util.ResourceBundle" %>

<%@ taglib uri="" prefix="portlet" %>
<%@ taglib uri="" prefix="fmt" %>

  RenderRequest renderRequest = (RenderRequest) request.getAttribute("javax.portlet.request");
  RenderResponse renderResponse = (RenderResponse) request.getAttribute("javax.portlet.response");

  String studentId = (String)renderRequest.getAttribute(Constants.JSP_RENDER_STUDENTID);
  if (studentId == null) studentId = "";

       for(int i = 0; i < proposalsCount_supervisor; i++) {
        IProposalListItem proposal = proposals_supervisor.getProposalListItem(i); 
  <a name="<%=proposal.getStudentId()%>"></a>
   <div class="dissertation_subsection<%=(i%2)%>">




<script type="text/javascript"> <%– MAKE SURE THIS IS PLACED AT THE END, ELSE IT WON’T WORK AT MOZILLA –%>
document.location.hash="<%=studentId%>"; //scroll to previously examined student
<%– alert(document.location.hash); –%>

HowTo: Check MSDN Subscriber downloads for tampering via SHA-1 key

Supposing you have an MSDN Subscription, you could download say SQL Server 2012 Standard Edition (x86 and x64) – DVD (English) from the following URL:

Suppose you do so and you keep that .ISO file (a CD/DVD image that you can burn to a disk using Windows 7 or Active@ ISO Burner tool, or mount as a virtual disk with Daemon Tools or unpack with WinRAR etc.).

Later on before installing it you’d like to know if it has been tampered in between by some virus, or if it was tampered by some man-in-the-middle attack during the download process.

Luckily, the MSDN subscriber downloads page is accessible without even signing in with your Microsoft account credentials and has a Details link for each download item that shows an SHA-1 hash key for the file (very handy if you don’t want to use the company’s credentials on a developer machine, but just want to copy-paste the SHA-1 key from there to check it against the file you have at hand).

Speaking of SHA-1, it would be nice if Microsoft also displayed an MD5 key there too for cross-checking both of them, or even a SHA-3 key in the future, that is supposed to be more (cryptographically) secure.

To check the file against the SHA-1 key, you can use the Microsoft File Checksum Integrity Verifier (FCIV) tool, a free command line utility that computes MD5 or SHA1 cryptographic hashes for files:

FCIV installer just unpacks an fciv.exe and a ReadMe.txt file. The command-line parameters for fciv.exe are displayed if you run it from a command-line (cmd.exe or command.exe in XP) window:

// File Checksum Integrity Verifier version 2.05.
Missing flag: -xml

Usage:  fciv.exe [Commands] <Options>

Commands: ( Default -add )

        -add    <file | dir> : Compute hash and send to output (default screen).

                dir options:
                -r       : recursive.
                -type    : ex: -type *.exe.
                -exc file: list of directories that should not be computed.
                -wp      : Without full path name. ( Default store full path)
                -bp      : specify base path to remove from full path name

        -list            : List entries in the database.
        -v               : Verify hashes.
                         : Option: -bp basepath.

        -? -h -help      : Extended Help.

        -md5 | -sha1 | -both    : Specify hashtype, default md5.
        -xml db                 : Specify database format and name.

To display the MD5 hash of a file, type fciv.exe filename

Based on those, you can create an fciv.bat file, where you have something like the following:

c:\users\myself\desktop\admin\fciv.exe -both %*

This batch file (fciv.bat) runs fciv.exe (assuming it is at path c:\users\myself\desktop\admin above, change this appropriately), passing it –both parameter to generate both SHA-1 and MD5 keys (could have used –sha1 instead for more speed, since MSDN doesn’t give MD5 key for files).

It uses %* to pass all command-line parameters of the batch file to the executable fciv.exe file. This means you can then drag-drop any file onto the fciv.bat at Windows Explorer and it will run fciv.exe on it, telling it to generate both MD5 and SHA-1 keys (shown in a tabular form at the output).

Before exiting, the batch file executes pause (the @ prefix means to not display the command itself on the console – could have also used an @echo off command at the start of the batch file but want to show the fciv.exe command path being executed for troubleshooting) instead of closing the console window immediately as would happen if you drag-dropped a file on fciv.exe itself). Pressing space after you read the hash keys (can also copy-paste them from the console right-clicking it and selecting Mark command, then drag to select and press SPACE key to copy), will then close the console.

Do note that FCIV also can take other parameters, to add calculated keys to a simple XML file (serving as a database) which it can use later on to check multiple files for tampering when you tell it to.

Microsoft File Checksum Integrity Verifier (FCIV)

I recently came across a very useful Microsoft tool (FCIV) that can compute and store (as XML) checksums (MD5, SHA1 or both hashes) of folders/files you want and can also be used to later on verify the checksum lists to see if they’ve been tampered with.

Would be nice to have a GUI wrapper around that tool that would also cooperate with the task scheduler to run regular checks of sensitive files.

You can get FCIV from (after unpacking it at some folder you can checkout the tool parameters by typing fciv or fciv /? at the command line – of course you can use fciv | more to see the syntax page by page).

You can read more regarding that (unsupported) Microsoft tool at


Microsoft (R) File Checksum Integrity Verifier V2.05 README file

1.What is File Checksum Integrity Verifier (FCIV)?
4.Database storage format.

1.What is fciv?
Fciv is a command line utility that computes and verifies hashes of files.

It computes a MD5 or SHA1 cryptographic hash of the content of the file.
If the file is modified, the hash is different.

With fciv, you can compute hashes of all your sensitive files.
When you suspect that your system has been compromised, you can run a verification to determine which files have been modified.
You can also schedule verifications regularily.

– Hash algorithm: MD5 , SHA1 or both ( default MD5).
– Display to screen or store hash and filename in a xml file.
– Can recursively browse a directory ( ex fciv.exe c:\ -r ).
– Exception list to specify files or directories that should not be computed.
– Database listing.
– hashes and signature verifications.
– store filename with or without full path.

Usage:  fciv.exe [Commands] <Options>

Commands: ( Default -add )

        -add    <file | dir> : Compute hash and send to output (default screen).

                dir options:
                -r       : recursive.
                -type    : ex: -type *.exe.
                -exc file: list of directories that should not be computed.
                -wp      : Without full path name. ( Default store full path)
                -bp      : base path. The base path is removed from the path name of each entry

        -list            : List entries in the database.

        -v               : Verify hashes.
                         : Option: -bp basepath.

        -? -h -help      : Extended Help.

        -md5 | -sha1 | -both    : Specify hashtype, default md5.
        -xml db                 : Specify database format and name.

To display the MD5 hash of a file, type fciv.exe filename

Compute hashes:
        fciv.exe c:\mydir\myfile.dll
        fciv.exe c:\ -r -exc exceptions.txt -sha1 -xml dbsha.xml
        fciv.exe c:\mydir -type *.exe
        fciv.exe c:\mydir -wp -both -xml db.xml

List hashes stored in database:
        fciv.exe -list -sha1 -xml db.xml

        fciv.exe -v -sha1 -xml db.xml
        fciv.exe -v -bp c:\mydir -sha1 -xml db.xml
4.Database storage format:
xml file.

The hash is stored in base 64.
<?xml version="1.0" encoding="utf-8"?>
        <name> </name>
        <MD5> </MD5>
        <SHA1> </SHA1>

You can build a hash database of your sensitive files and verify them regularily or when you suspect that your system
has been compromised.

It checks each entry stored in the db and verify that the checksum was not modified.

6. History:
Fciv 1.2 : Added event log.
Fciv 1.21: Fixed bad keyset error on some computers.
Fciv 1.22: Added -type option. Support up to 10 masks. *.exe *.dll …
Fciv 2.0:  xml as unique storage. Added -both option.
Fciv 2.01: Exit with error code to allow detections of problem in a script.
Fciv 2.02: Improved perfs. When both alg are specified, it’s now done in one pass.
Fciv 2.03: Added -wp and -bp options. Fciv now stores full path or relatives paths.
Fciv 2.04: Removed several options to simplify it.
Fciv 2.05: Added success message if the verification did not detect any errors.

%d bloggers like this: