Gå til innhold

Kontroll av string-lengde


Anbefalte innlegg

Jeg har problemer med å sette en sperre for antall tegn i PHP.

 

Databasen har max 30 tegn, og når noen skriver over 30 tegn i html-skjema og trykker post, skal jeg ha en sjekk som kontrolerer om dette er tilfellet.

 

Hvis det er mindre enn 30 tegn - kjør SQL-query, hvis det er over 30 tegn - IKKE kjør.

 

 

Noen som kan hjelpe meg med dette?

 

bruker:

 

PHP

Oracle

MySQL

 

 

mvh

 

Tore Minsaas :thumbup:

Lenke til kommentar
Videoannonse
Annonse
Dette er de tingene jeg faktisk mener Javascript er mer passende enn php til :)

 

Selv om jeg bruker php-metoden :p

:no: Nei, problemet med javascript er at neste 10% deaktivert javascript - og det er mulig å lure et javascript enkelt ved å lage et nytt skjema. Du burde absolutt bruke php til dette. Lag en skjemavalidator, som sjekker etter tegn, min lengde, maks lengde og gjøre variabelen trygg(mysql_escape_string())

Lenke til kommentar
:no: Nei, problemet med javascript er at neste 10% deaktivert javascript - og det er mulig å lure et javascript enkelt ved å lage et nytt skjema. Du burde absolutt bruke php til dette.

Grunnen til at jeg mener du ikke trenger PHP til dette er at det krever CPU av serveren og tar mer båndbredde.

 

I dette tilfellet så takler ikke tabellen i MySQL mer enn 30 tegn, og hvis noen da går rundt javascriptsperringen og får kastet inn 600 tegn, så skrives ikke mer enn de 30 første inn i databasen.

Lenke til kommentar

Problemet er størst dersom en person sender skjemaet og ikke har javascript - og denne personen regner med at all teksten kommer frem!

Det er derfor det er en stor fordel å bruke PHP. Man burde likevel sjekke innholdet i variabelen, og da burde man også sjekke lengden på variabelen når man først er i gang.

Lenke til kommentar

Dude, vil du krangle så burde du finne en annen å krangle med - jeg gidder ikke. Selv utvikler jeg kommersielle scripts, og sammarbeider med programmerere fra hele verden - så de scriptene jeg lager burde fungere for flest mulig brukere.

 

Det er mange som ikke har javascript enabeld, glem ikke at ikke alle har nyes versjon av browsere - mange brannmurer kan stoppe javascript - noen deaktiverer det - noen surfer på jobben hvor de har skrudd det av. Som du også sikkert skjønner så er det mange grunne til at JavaScrip kan være av.

 

Hva er det du vil frem til med en kommentaren?

Du kan f.eks. ta en kikk på w3schools 2004 statistikk for javascript:

http://www.w3schools.com/browsers/browsers_stats.asp

I følge den har 8% av alle brukere skrudd av eller har ikke støtte for javascript.

 

8% er mange, tenk deg at siden har 100 registreringer hver dag - det betyr at det er nesten 3000 brukere som ikke har støtte for javascript, og det er mange som da ikke får opp feilmeldingen i javascript.

 

Denne posten høres sikkert ganske sur ut, men den er ikke så ille ment. Se heller på den som et tips :thumbup:

Endret av ????????
Lenke til kommentar
:no: Nei, problemet med javascript er at neste 10% deaktivert javascript - og det er mulig å lure et javascript enkelt ved å lage et nytt skjema. Du burde absolutt bruke php til dette.

Grunnen til at jeg mener du ikke trenger PHP til dette er at det krever CPU av serveren og tar mer båndbredde.

 

I dette tilfellet så takler ikke tabellen i MySQL mer enn 30 tegn, og hvis noen da går rundt javascriptsperringen og får kastet inn 600 tegn, så skrives ikke mer enn de 30 første inn i databasen.

Ikke for å være kranglete, men PHP bruker ikke båndbredde så lenge den ikke outputer noe, eller kommuniserer med eksterne objekter. JavaScript derimot, det bruker båndbredde siden dette blir sendt som tekst til browseren.

 

Er litt enig med begge her. Det utgjør ingen "sikkerhetsrisiko" ved at brukeren skriver inn for mye. Uansett vil stringen bli kuttet ned til 30 tegn så lenge mysql-databasen er satt opp med varchar(30). Uansett, brukeren burde få beskjed om dette som ???????? nevner, slik at brukeren ikke blir sittendes som et spørsmålstegn når han merker at halve stringen er klipt vekk.

 

Likevel, en mellomting av PHP og JavaScript kan være fint i en slik situasjon. Da får brukerene som har JS slått på beskjed om at feltene ikke er fylt inn riktig før browseren sender skjemaet og må laste på nytt (som mange ser på som en fordel). For de som ikke bruker JS vil man i stedet få en feilmelding når skjemaet er sendt. Slik havner ingen utenom.

 

Jeg bruker JS til en del forskjellig, men har en tommelfingerregel som sier at man alltid skal sjekke alt serverside som sendes av informasjon, og at man alltid skal ha et alternativ til JS. Man kan også anbefale brukerene å slå på JS ved bruk av noscript-taggen (som outputtes til de som har slått av JS). Dette kan f.eks være nødvendig når man bruker tidssparende JS-script som et fargekart, som kan velge farger for en, i stedet for å bruke eksterne programmer til å finne HEX-koden til en farge.

Lenke til kommentar
Ikke for å være kranglete, men PHP bruker ikke båndbredde så lenge den ikke outputer noe, eller kommuniserer med eksterne objekter. JavaScript derimot, det bruker båndbredde siden dette blir sendt som tekst til browseren.

 

Er litt enig med begge her. Det utgjør ingen "sikkerhetsrisiko" ved at brukeren skriver inn for mye. Uansett vil stringen bli kuttet ned til 30 tegn så lenge mysql-databasen er satt opp med varchar(30). Uansett, brukeren burde få beskjed om dette som ???????? nevner, slik at brukeren ikke blir sittendes som et spørsmålstegn når han merker at halve stringen er klipt vekk.

Hva mener du med at javascript bruker båndbredde? Javascript kjøres jo clientside og sjekken på hvor lang strenger er viil aldri sendes over nettet...

 

Når strengen er lenger enn 30 tegn vil ikke MySQL lagre mer enn 30 av tegna, men resten vil fortsatt være med i spørringen.

Endret av RottePostei
Lenke til kommentar

Javascript tar plass i kildekoden, sant? La oss si at javascriptdelen består av 1000 tegn (for å gjøre det enkelt). 1000 tegn ~ 1 kb.

 

Om man har 100.000 sidevisninger av denne siden i måneden vil javascriptdelen ta opp 100 000 * 1 kb = 100 000 kb = 100 mb.

 

Ja, dette er veldig lite. Saken var egentlig at PHP ikke bruker båndbredde (som Toolshed sa), mens Javascript bruker båndbredde (noe Toolshed ga uttrykk for at det ikke gjorde).

 

Alle tegnene vil være med i spørringen. Det jeg mente med "sikkerhetsrisiko" var at flere tegn ikke blir lagt inn uansett. Med andre ord tenkte jeg ikke på validering eller noe i den dur.

Lenke til kommentar

Jeg satt med en case der jeg hjalp folk å legge inn bestillinger til hjemme-PC. Vi snakker over 5000 personer, og alle skulle fylle inn 6 sider med skjema. Det var, om jeg skal gjette vilt, ca. 50 felt.

 

Hvis 5000 brukere får tilsendt et javascript på 1kB hver, er man oppe i 5MB.

 

Hvis man derimot skulle sende all dataen til serveren, for så at serveren skal sende tilbake informasjon om hva som er skrevet feil og hvordan det skal gjøres på hvert felt noen skriver feil, og tro meg, det er maaaange, så blir det rimelig mye data der.

 

Men jeg mener javascript og php har sine ulemper her, og jeg er enig i veldig mye som spørsmålstegnene sier, men én ting er jeg ikke med på, og det er det argumentet at folk ikke har javascriptkompatible nettlesere eller nettlesere med javascript avslått.

 

EOD for min del :)

Lenke til kommentar

Det er vel ikke bare snakk om javascript kompatible nettlesere, men også "dumme" brukere og folk som elsker å "gå rundt" sikkerhetsopplegg for å ødelegge/hacke, kall det hva du vil. Jeg har alltid lært at når man utvikler programvare skal man anta at brukeren som benytter programmet er dum. Det skal ikke være mulig å begå feil. Derfor burde man bruke php og ikke javascript. Dersom en side er avhengig av at javascript er skrudd på for å fungere korrekt, er det ikke en bra side. Dessuten tar vel det ikke så mye ressurser på serveren å sjekke tekststrenger? Tviler også sterkt på at alle de 5000 brukerne sender skjemaet over nettet på akkurat samme tidspunkt.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...