18. november 2007 - 19:04Der er
25 kommentarer og 2 løsninger
XMLHttpRequest, post og kryptering
Hej, først; jeg sidder lige og roder med noget XMLHttprRequest, hvor jeg sender noget bruger input til et php dokument, der så gemmer det i en database. Problemet er, at når jeg bruger post-metoden til at sende informationen til dokumentet, så forstår den ikke æ, ø og å. Jeg sender informationen sådan her:
var userinput = "æøå";
xmlHttp.onreadystatechange = function () { // some code }; xmlHttp.open('post', 'fil.php', true); xmlHttp.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); xmlHttp.send('input='+userinput);
Og i min php-fil har jeg header('Content-Type: text/html; charset=ISO-8859-1'); men den forstår ikke æ, ø og å. Når jeg bruger get-metoden, dvs. når jeg ikke har xmlHttp.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); (hvilket er det jeg tror er lidt skyld i den ikke forstår æ, ø og å), så forstår den fint æ, ø og å, men ikke med post-metoden. Hvorfor løser jeg det?
Og bagefter; jeg skal have krypteret mine ting der bliver sendt med XMLHttpRequest... Jeg ved ikke hvordan det skal gøres, da jeg aldrig har arbejdet med det før. Jeg har ledt lidt, men har ikke kunne finde noget Javascript relateret, desværre.
Hvor krypteret skal det være? Hvis du krypterer i javascript, skal du jo være ops på, at brugeren altid kan se din javascript kode, og derved bryde den. Overvej SSL, hvis det er noget meget hemmeligt :)
Anyway, jeg kunne forestille mig at du lavede en encoding før du sendte dine data.. Det kunne være en base64-encoding. På denne måde vil danske tegn blive gemt ned i den kodede tekst, og du vil kunne hente dem frem igen ved at dekode hvor end du ønsker det.
Bemærk at basr64 IKKE er kryptering, men dog ulæseligt for dem der ikke ved hvad de laver.
Well, der vil på nogen tidspunkter blive sendt et password igennem, hvilket egentligt er det der skal krypteres. Så lidt kraftigt skal det da være... Jeg vil prøve at kigge på base64:) Men ellers, er der andre alternativer, når nu jeg skal sende passwords igennem?
*Bump* Jeg kunne rigtig godt bruge noget hjælp, så hvis der var nogen der kunne tænke sig at hjælpe med mine to problemer, ville det jo være dejligt:D
Jeg har lige kigget lidt på base64 encoding, men det jeg er lidt nysgerrig om hvor vidt det er muligt at lave noget, så man ikke umiddelbart kan se i kildekoden, hvordan det krypteres?
En hash er en kode der genereres udfra eksempeltvis et password. Det er så kompleks at man ikke umiddelbart kan dekryptere det og derved ikke gendanne passwordet.
Det man kan gøre er at gemme den generede hash i en database og når man så skal se om det er det rigtige password brugeren har indtastet, så laver man blot en ny HASH og sammenligner disse.
Det der er tricket her er at der ikke vil blive sendt noget over nettet som brugeren kan bruge til at gendanne passwordet.
Cool, nu har jeg ihverfald mine passwords krypteret ... det virker super, og så fik jeg også lejlighed til at læse om hashing og cryptegraphy:P
Hvordan skal base64-encoding kunne hjælpe på mit problem? Løsningen må vel egentligt være at encode og decode teksten iso-8859-15 til utf8 og decode det når det skal udskrives ... hvordan ved jeg dog ikke, og har ikke kunne finde noget brugbart via. google.
Okay, inde på webtoolkit.info fandt jeg en utf-8 encoder/decoder i javascript, og så prøvede jeg at tage og encode bruger indholdet der bliver sendt til et php-dokument med den, og når php-dokumentet så havde modtaget det, blev de decodet med phps indbyggede utf8_decode, før det bliver sat i databasen. Når jeg så trækker noget ud af databasen gør jeg bare det modsatte. Det resulterede i at, følgende blev til fÒ¸lgende ... hvorfor det ikke virker kan jeg dog ikke forstå. Kan det være fordi de to filer der sender indholdet og modtager det, begge er iso-8859-15?
Har du prøvet at skrive det ud på skærmen inden du lægger det i databasen.. Jeg fisker blot efter om det er dekodningen, eller overførslen til/fra databasen der fucker op.
Nu har jeg lige siddet og leget lidt med encodeURIComponent. Det jeg gjorde var, at alt data der blev sendt videre til et php dokument, men encoded, og alt der blev modtaget blev decoded, men jeg fandt meget hurtigt ud af at det ikke rigtig gør som det burde. Hvis jeg tager en streng der indeholder et æ og smider encodeURIComponent på den streng, bliver indholdet lavet om til %C3%A4, men hvis jeg sender strengen der indeholder %C3%A4 videre til php-dokumentet, så bliver den lavet om til noget den ikke skulle, hvilket jeg synes er meget mærkeligt. For hvis jeg blot tager og fylder en streng med %C3%A4, så modtager php-dokumentet det rigtig nok... Hvorfor det?
Jeg har set mig nødsaget til at lave en crapcoding hvor jeg tager og replacer æ, ø og å med ae, oe og aa, som en midlertidig løsning. Der er desværre også opstået en _utroligt_ mærkelig fejl, men den høre vidst ikke til her:)
hehe... tro mig.. jeg har for nyligt brugt 2 uger på at finde ud af alt det her mystiske FANDENS FUCKING LORT... med charsets.. :)
en HTML side er gemt binært med i UTF-8 (tjek med Notepad++) i headeren skriver du en meta, hvor du angiver content encoding <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
dét der sker nu, er at IE fucker alle dine Querystrings, og sender dem i UTF-8 Firefox derimod, sender dem i ASCII, eller Latin-1 encoding som man kalder den
dette gælder også for scripts, det er derfor vigtigt at du gemmer filerne i det rette format, og sørger for at angive det korrekte format alle steder, til at være det samme!
%C3%A4 er UTF-8 formatteret hvorimod %e6 er 'æ' i Latin-1
Hvis PHP ikke fatter UTF-8 Querystrings, skal du sørge for at URL-encode til Latin-1... men da Javascript ikke har Latin-1 URLencoding indbygget, er det derfor nemmere at skifte til UTF-8 --- dette var løsningen for mig...
jeg bruger ASP, og har indstillet scriptet til at køre UTF-8
husk at det som regel er selve FILEN som skal gemmes i UTF-8 for at skifte til UTF-8
Mange, mange, mange gange tak for det tip, montago! Nu har jeg fået det til at virke - den sender æøå helt perfekt. Jeg opdagede dog noget lidt mærkeligt; hvis jeg bruger decodeURIComponent når jeg trækker tingene ud, laver det mere ballade end det gør godt. For hvis jeg ikke bruger det, køre alt, indtil videre som smurt, men hvis jeg smider det på, er der nogen steder det går galt... Hvorfor er decodeURIComponent ikke nødvendigt?
og for en god ordens skyld, så skal det lige siges at alle mine php-dokumenter der modtager og giver ting til javascript er utf8 encoded, men alle mine andre sider er stadigvæk iso-8859-1.
Okay, jeg har lige fundet ud af at indholdet, selvom det optræder rigtigt når javascript spytter det ud, optræder således i databasen: følgende; Dvs. at når mine iso-8859-15 gemte dokumenter der også har et meta der angiver iso-8859-15 charset, udskriver teksten ved at hente det fra databasen, ser det således ud: ÊÞÃ; jeg har prøvet at gemme filerne som utf8, men beholde iso-8859-15 meta charsettet, men det virker heller ikke... Det er virkelig ærgeligt!!
Well, som jeg skrev i et tidligere indlæg har jeg konverteret _alle_ mine dokumenter til utf8, hvilket resulterede i at det bare virker:D Rigtig lækkert!!
Jeg forestiller mig at i, montago og anri, deler pointene fifty/fifty, så hvis i smider nogen svar ville det være dejligt:)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.