Rabobank trusts only Rabokeys
Friday, 12. September 2008, 17:17:09
This is caused by a keypress handling JavaScript - it's all on one line so I made a re-formatted copy. If you thought the bug was weird, wait till you try figuring out what the point of the script is..
The basic logic that causes the problem is: "any browser that supports addEventListener() will support charCode but not keyCode in the keypress event". As it happens, Opera does support addEventListener() but not charCode. The site blocks keypress events with keyCode 116 which is the correct keyCode for a "t" keypress. (If we didn't support addEventListener they would listen for keyDown events with keyCode 116 instead - which is what they basically intended to do.)
With the problem analysis out of the way: I simply don't get what this site is trying to do. They set one handler for keypress events to cancel them if it's the F5 key, and another handler for keyup events to call location.reload() if it's the F5 key!? See here:
function F5DownEventHandler(evt){
this.target=evt.target||evt.srcElement;
this.keyCode=evt.keyCode||evt.which;
this.altKey=evt.altKey;
this.ctrlKey=evt.ctrlKey;
var targtype=this.target.type;
if(this.keyCode==116&&(evt.charCode==null||evt.charCode==0)){
return cancelKey(evt,this.keyCode,this.target)
}
if(this.keyCode==13&&(this.target.id=='z01'||this.target.id=='z02'||this.target.name=='z5'||this.target.id=='ra_searchfield2'||this.target.name=='z81')){
return cancelKey(evt,this.keyCode,this.target)
}
}
function F5UpEventHandler(evt){
this.target=evt.target||evt.srcElement;
this.keyCode=evt.keyCode||evt.which;
this.altKey=evt.altKey;
this.ctrlKey=evt.ctrlKey;
var targtype=this.target.type;
if(this.keyCode==116&&(evt.charCode==null||evt.charCode==0)){
window.location.reload(this.ctrlKey)
}
if(this.keyCode==13&&(this.target.id=='z01'||this.target.id=='z02'||this.target.name=='z5'||this.target.id=='ra_searchfield2'||this.target.name=='z81')){
this.target.parentNode.parentNode.submit()
}
}
So: "we don't mind that [F5] reloads the page and [enter] submits forms as long as we re-implement the browser's functionality in JavaScript".
Or: Rabobank trusts only Rabo-programmed keys?
I guess the browser's OWN implementation of [F5] and [enter] just wasn't buggy enough.










Schalandra # 12. September 2008, 21:57
scipio # 13. September 2008, 07:04
Schalandra # 13. September 2008, 07:18
Smir # 13. September 2008, 08:16
They try to cancel F5, too... but it's the same as the oncontextmenu blockers to protect your sourcecode: You block one way, but there are 10 others
I wrote them about it and also how they can fix it, but they replied, that Opera wasn't on the list of supported browsers and I should use another... but as far as the functions go, everything I used was working well in Opera, except the t-Key...
Schalandra # 13. September 2008, 10:48
But maybe your bank just doesn't want you as a customer?
rburbrid # 23. September 2008, 16:29
OmegaJunior # 18. November 2008, 23:56
Anonymous # 5. December 2008, 23:57
It's extremely obvious that with the F5-handlers, they just make sure you cannot overload their server/make wrong requests multiple times accidentally by keeping the F5 key pressed. By default (in most browsers), holding down F5 sends a continuous flow of requests to the server, their implementation fixes that very nicely.
Schalandra # 6. December 2008, 11:46
If that was their intention (which I heavily doubt) it was a really stupid method. Turn off JS, or simply reconfigure the reload-key and the "fix" is gone with the wind...
There are much better (and more reliable) ways to slow down the number of requests sent by the same IP.
hallvors # 6. December 2008, 19:03
In fact I can't recall anyone mentioning this as a problem ever. In any case it is an implementation detail any browser vendor can quite easily fix to send only one refresh request and ignore key repeats, so if this is a noticeable problem, site authors/administrators should complain to the browser vendors and lobby for a change.