[JVS] backspace half disabelen

[the_dgc]

goedendag,

ik ben momenteel bezig met het bouwen van een webbased aplicatie voor een klein bedrijf. nu ben ik alleen tegen een gigantisch probleem aangelopen.
de backspace. op het moment dat net iemand iets in de database heeft gezet dan en hij of zei drukt op backspace dan worden de gegevens nog een keer ingevoerd.

nu ben ik aan het zoeken geweest op internet en heb ik voor dit probleem 2 oplossingen gevonden.

de eerste oplossing is een java script
<code>
<SCRIPT LANGUAGE="JavaScript">
/* function key(e){
var k = e ? e.which : event.keyCode;
if(k == 8 ) {
alert('wegens veiligheids redenen is deze toets geblokeerd');
return false;
}

}
document.onkeydown = key;
</script>

</code>
de var k is hier het toets nummer. en 8 is de backspace.

en de tweede oplossing is een javascript regel.
history.forward();

beide scripts werken maar volstaan niet 100%
bij het eerste script wordt er voor gezorgt dat de site niet opnieuw laad maar op een pagina met tekstboxen is het script iritant omdat je ook binnen de textboxen ook geen backspace kunt gebruiken.
het tweede script laad de zelfde pagina opnieuw op het moment dat backspace of een andere vorm van terug wordt gebruikt. maar daardoor gooit tie ook de formulieren leeg.

ik ben dus opzoek naar een javascript (omdat het client-side gecontroleerd moet worden) die er voor zorgt dat minimaal de backspace gedisabeld wordt als deze niet wordt gebruikt in een formulier en die de site niet vernieuwd zodat een formulier gevult blijft.

wie kan mij vertellen waar ik deze oplossing kan vinden..

[Spider.007]

Dat script is sowieso niets aangezien je alsnog op de backbutton moet drukken

Heb je al gezocht?

[rml][ php/mysql] Dubble invoer na refresh (F5)[/rml]/

Waarom moet het eigenlijk clientside?

[ Voor 11% gewijzigd door Spider.007 op 06-03-2004 15:42 ]

[Clay]

de backspace. op het moment dat net iemand iets in de database heeft gezet dan en hij of zei drukt op backspace dan worden de gegevens nog een keer ingevoerd.

Dan zou ik dat oplossen, en niet de backspace knop van de gebruiker kapot maken. Wie ben jij om te bepalen welke toets een gebruiker wel of niet mag indrukken? Dat moet je nml ook alt + [pijl] kapot maken, de back knop van de browser en alle andere mogelijkheden om back te gaan...

[the_dgc]

Spider.007 schreef op 06 maart 2004 @ 15:42:
Dat script is sowieso niets aangezien je alsnog op de backbutton moet drukken

Heb je al gezocht?

[rml][ php/mysql] Dubble invoer na refresh (F5)[/rml]/

Waarom moet het eigenlijk clientside?

heb jij gelezen...?

ik heb gezocht.. dat heb ik verteld.. ik heb ook mijn zoek resultaten weggezet.
ik wil het aan de client zeide hebben omdat daar momenteel het probleem ligt. want het invoeren is maar 1 belangrijk voorbeeld. maar ik wil bv ook niet dat mensen op andere plaatsen terug kunnen.

Clay schreef op 06 maart 2004 @ 15:42:
[...]


Dan zou ik dat oplossen, en niet de backspace knop van de gebruiker kapot maken. Wie ben jij om te bepalen welke toets een gebruiker wel of niet mag indrukken? Dat moet je nml ook alt + [pijl] kapot maken, de back knop van de browser en alle andere mogelijkheden om back te gaan...

als je nikt nuttigs te vertellen hebt.. ga dan je post plaatsen bij de onzin topics.

en ik weet ook dat er veel meer toetsen zijn om een pagina terug te gaan.. maar die leveren geen probleem af om gewoon te disabelen omdat deze geen andere functies hebben. backspace wel. bovendien hebben gebruikers van bedrijfssystemen te werken met het programma en niet te klagen omdat ze toetsen niet kunnen gebruiken. we praten hier niet over een website die via internet te bereiken is.

dus als je geen oplossing of zinnige vraag hebt post dan niet. dit houd de topic overzichtelijk en de inhoud relevant.
bijvoorbaad dank.

[drm]

the_dgc:als je nikt nuttigs te vertellen hebt.. ga dan je post plaatsen bij de onzin topics.

Het is wel degelijk nuttig, en imo heeft hij nog gelijk ook

Denk er eens bij na: wat is nou precies het probleem; is dat de back-functie van de browser of het feit dat het twee keer ingevoerd wordt? Dat laatste is namelijk kinderlijk eenvoudig op te lossen met een Location header vanaf de server zodra het spul verwerkt is. De browser vervangt de history entry dan namelijk door wat er in de Location header staat en zal dus niet proberen opnieuw een formulier te verzenden.

Nogmaals; een plakbandoplossing is geen echte oplossing

[the_dgc]

drm schreef op 06 maart 2004 @ 15:58:
[...]
Het is wel degelijk nuttig, en imo heeft hij nog gelijk ook

Denk er eens bij na: wat is nou precies het probleem; is dat de back-functie van de browser of het feit dat het twee keer ingevoerd wordt? Dat laatste is namelijk kinderlijk eenvoudig op te lossen met een Location header vanaf de server zodra het spul verwerkt is. De browser vervangt de history entry dan namelijk door wat er in de Location header staat en zal dus niet proberen opnieuw een formulier te verzenden.

Nogmaals; een plakbandoplossing is geen echte oplossing

ok laat ik het anders stellen..
ook voor de gebruiksvriendelijkheid is het beter dat ik dit doe.
het is in dit geval niet zomaar een plakbandoplossing zoals jij het wilt noemen.
het is wel degelijk goed nagedacht voor dat deze oplossing is gekozen. want misschien was dan het database invoer probleem niet het best gekozen voorbeeld. want zelf weet ik daar ook wel php beveiligingen voor te maken zodat dat niet gebeurd. maar het zit em meer in de formulieren zelf.

op de eerste plaats wil ik voorkomen dat mensen door middel van andere toetsen (bv backspace) dan aangegeven het formulier verlaten. dit kan ik voorkomen door 1 van de 2 gevonden scripts te gebruiken. maar om het dan nog gebruiksvriendelijk te houden ben ik op zoek naar deze optie.. dus dat je de gegeven toetsen niet kunt gebruiken en dat de site bij het gebuik niet opnieuw laad en dit is iets wat je alleen maar aan de kant van de gebruiker kunt doen.
en ik wil het nogmaals benadrukken. we praten hier over een systeem wat binnen een bedrijf gaat draaien en niet op het internet (waar ik dit soort dingen niet zou gebruiken) dus gebruiksvriendelijkheid staat wat hoger in het vaandel. en dat dat tenkoste gaat van een aantal vrijheden en toetsen dat wordt voor lief genomen. alleen het eerst gegeven script neemt iets te veel vrijheden weg omdat het iets te goed reageerd.

ik hoop dat ik hiermee mijn visie en gebruik doeleinde duidelijk genoeg heb gemaakt.

[Bosmonster]

[edit]

Topic weer open na email-correspondentie.

Een applicatie (internet of intranet) moet werken met de software zoals die bestaat, in dit geval browsers. Als functionaliteit in de brower de functionaliteit in de applicatie gaat beheersen ligt er een probleem bij de applicatie. Het hele back/forward/refresh probleem is iets wat eenvoudig op te lossen is in een goed gebouwde applicatie, gecombineerd met gebruikmaking van standaard browserfeatures. Openen van een nieuw venster of (i)frame zorgt er al voor dat de history leeg is en de gestarte applicatie niet verlaten kan worden. Status opslaan in sessie-geheugen en POST's op laten volgen door Location-headers zorgt ervoor dat mensen nooit zomaar terug kunnen of expired-meldingen krijgen.

Eenvoudige en nogal standaard oplossingen om je applicatie te laten werken zonder met de browser te hoeven 'rommelen'. Het is je applicatie die veilig moet zijn onafhankelijk van de software waarmee gekeken wordt en niet juist WEL afhankelijk van de browser. Of het nou intern gebruikt wordt of niet maakt helemaal niks uit in dit geval, want het zou simpelweg betekenen dat je niet weet hoe een applicatie veilig te maken serverside.

Om aan te vullen op wat jij denkt dat de oplossing is: Dit is al wat vaker langs gekomen hier op GoT. Conclusie is dat je NOOIT alles af kunt vangen met clientside script. Want naast de browser knoppen, keyboard shortcuts heb je ook nog legio mensen die gebruiken maken van andere toetsenbord knoppen, alternative muisknoppen (meeste muizen tegenwoordig hebben een speciale back-knop), etc, etc.

Maar goed, ik ben heel benieuwd naar jouw specifieke situatie waarin al deze stellingen niet zouden voldoen

[ Voor 80% gewijzigd door Bosmonster op 07-03-2004 14:35 ]

[the_dgc]

op de eerste plaats wil ik mijn verontschuldigingen aanbieden aan clay over mijn reactie. deze was niet helemaal terecht. een van de redenen dat ik zo heftig reageerde is omdat ik tijdens het zoeken een hoop topics tegen was gekomen die door onzin gesloten zijn. maar deels had je inderdaad gelijk. alleen het was gewoon niet wat ik zocht.

gedurende de tijd dat het topic hier was gesloten heb ik niet stil gezeten. ik heb op een ander forum de zelfde vraag ook gesteld. dit heeft geleid tot de oplossing waar ik naar opzoek was. namelijk een client-sided oplossing.

de code van de oplossing is de volgende
-------------------------------------------------------------------------------

<SCRIPT LANGUAGE="JavaScript">
function key(e){
var k = e ? e.which : event.keyCode;
if(k == 8 && event.srcElement.tagName!="INPUT" && event.srcElement.tagName!="TEXTAREA") {
alert('wegens veiligheids redenen is deze toets geblokeerd');
return false;
}

}
document.onkeydown = key;
</script>

--------------------------------------------------------------------------------

ik heb deze code nu te samen met de regel history.forward(); in mijn code gezet en heb dus de volgende situatie gecreerd.
het is niet mogelijk om terug te gaan naar de vorige pagina. en op het moment dat men bezig is met het invoeren van een forum en men heeft geen tekstvak geselecteerd en men drukt opzettelijk of niet de backspace toets in dan heeft dat geen uitwerking dat het formulier leeg is.
de rede dat ik momenteel alleen de backspace toets afscherm met deze code is omdat dit eigelijk de enige toets is die tijds het invoeren gebruikt wordt. de overige toetsen of toetscombinaties zijn er duidelijk voor gedefineerd om de pagina te verversen of terug te gaan in de code en zullen daarom ook minder gebruikt worden. bovendien vangt dan de extra toegevoegde regel de eventuele rotte gevolgen op.

overigens ben ik voldoende instaat om serversided beveiligingen te maken in mijn code. alleen gezien de situatie heb ik er dit keer gewoon voor gekozen dit laatste puntje client-sided op te lossen.

[ Voor 8% gewijzigd door the_dgc op 07-03-2004 23:13 ]

[Verwijderd]

Het is gekkenwerk om alles af te vangen, want wat ga je doen in andere browsers en configuraties? Of personalized shortcuts, etc.

Wat je kunt doen is de data serverside checken. Wordt idententieke data binnen X seconden/minuten nogmaals ingevoerd, .. afkappen en melding tonen.

Deze data kun je naar eigen inzicht opslaan in cookies, sessions, etc.. wat je maar wilt.

Overall geldt ook hier weer de gouden regel, never trust user input

[ Voor 11% gewijzigd door Verwijderd op 07-03-2004 23:19 ]

[the_dgc]

Verwijderd schreef op 07 maart 2004 @ 23:19:
Het is gekkenwerk om alles af te vangen, want wat ga je doen in andere browsers en configuraties? Of personalized shortcuts, etc.

Wat je kunt doen is de data serverside checken. Wordt idententieke data binnen X seconden/minuten nogmaals ingevoerd, .. afkappen en melding tonen.

Deze data kun je naar eigen inzicht opslaan in cookies, sessions, etc.. wat je maar wilt.

Overall geldt ook hier weer de gouden regel, never trust user input

tegen die dingen ga ik niks doen omdat er een vaste configuratie draaid op het bedrijf. ik heb daar overigens samen met een ander ook het systeem beheer in handen. dus de oplossing is ook deels gebaseerd op de systeem configuraties binnen het bedrijf...

op het moment dat dit zelfde systeem op een website zou gaan draaien dan is dit inderdaad niet de juiste en beste oplossing.. maar gezien de aard van de gegevens is en zal dit niet het geval zijn