10. april 2005 - 01:52Der er
16 kommentarer og 1 løsning
Kryptering: Invalid length for a Base-64 char array
HAr lige et lille problem jeg skal se om jeg kan finde en løsning på... problemet er som topic, altså at der en gang imellem bliver klaget over at længden ikke passer... og ja... hmmm....
Det bliver brugt til URL incryption hvilket vil sige at jeg pakker hele min parameterliste ned i en enkel textstreng som jeg så kryptere med DES for så at sende den via Url, hvor jeg så henter den ud igen og dekryptere den med DES... og det virker da også i langt de fleste tilfælde... men ikke i alle...
Og så er det lige at jeg ikke helt kan se hvorfor det er sådan... for efter som jeg Kryptere den og konvertere de krypterede bytes til Base-64 burde der da umiddelbart ikke være problemer med at vende tilbage igen?
Støv, fibre og metalliske partikler kan påvirke både uptime, levetid og driftssikkerhed. Derfor arbejder flere datacentre systematisk med contamination control.
Det sjove af det hele er at kopiere jeg den streng der ligger krypteret i min URL og smider en manuelt igennem dekryptering med samme nørgle kan den pluselig godt ved dem som den ellers mælder fejl ved....
Du skal ikke url-encode først, men sidst, lige inden du lægger værdien i URL-en. En url-encode laver fx "+" om til noget, der forstås som "+" og ikke som blank.
Ja nu mente jeg altså før jeg smed dem på url'en... jeg ved godt hvad Url encode gør... Men jo mere man skal encode jo mere betyder det også for performance, og da jeg skulle have mine Querys krypteret, så kunne jeg ikke se noget grund til at skulle sætte både DES kryptering og URL encoding i spil...
Det bliver jo ikke anderledes end det du gør nu. URL-encode laver kun om på de "giftige" tegn, så man er sikker på alt kommer med over. Næsten alle dine tegn er fine, undtagen "+", og måske andre.... Og mon en url-encode er langsommere end en replace. I hvert fald ville du få dem alle med, nuværende og fremtidige.
Men det jeg ville sige var bare, at din løsning reelt var blevet foreslået tidligere.
Da DES bruger base64 vil resultatet efter DES være bytes i den nedre halvdel af ASCII-tabellen. Disse vil normalt være fredelige når de indgår i query-strengen på et URL. Men nogle få exceptionelle undtagelser som f.eks. '+' vil give problemer. Ved URL-encoding er det kun de tegn som vil blive oversat til noget i stil med "%2B" (for '+'). Da der næppe vil være mere end et par stykker af dem i din streng, vil resultatet vel maks. blive 0-10 tegn længere.
Hvis du derimod URL-encoder *før* at du DES-kryptere (som du antyder i 10/04-2005 14:22:01) så kan jeg godt forstå din påstand, men denne fremgangsmåde ville også være den helt forkerte på mange forskellige måder!
Lad mig slå fast at du *bør* URL-encode. Lige nu har du kun oplevet problemet i forbindelse med '+', men hvad så når du en dag støder på tilfældene '$', '&', ',', '/', ':', ';', '=', '?' eller '@' for blot at nævne nogle. Ved at bruge URL-encoding så vil du være fremtidssikret:
** Hvis du derimod URL-encoder *før* at du DES-kryptere (som du antyder i 10/04-2005 ** 14:22:01) så kan jeg godt forstå din påstand, men denne fremgangsmåde ville også ** være den helt forkerte på mange forskellige måder!
Nej, som jeg tidligere sagde betyd det får jeg kasteden den på min Url og ikke før den røg igennem min DES... Ellers ville jeg jo ikke løse problemet da jeg stadig ville få +'er ud... og når jeg snakker en faktor 10 er det ikke hvor meget det fylder... det er Ydelses messigt... dvs. det tager 10 gange så lang tid at URL-encode...
** Lad mig slå fast at du *bør* URL-encode. Lige nu har du kun oplevet problemet i ** forbindelse med '+', men hvad så når du en dag støder på ** tilfældene '$', '&', ',', '/', ':', ';', '=', '?' eller '@' for blot at nævne ** nogle. Ved at bruge URL-encoding så vil du være fremtidssikret:
Nej, for faktisk er alle de tegn du lige lister op der 100% urelevante her... Igen af dem giver problemer selv om de evt. var med... så hvorfor skulle jeg gøre mit site 10 gange tungere på det område for at opnå ingen ting???
** PS: Og så mener jeg i øvrigt at de 30 point burde være mine da det var den ** manglende URL-encoding som gav problemet!
Du må da hjertens gerne få de 30 point... hvis du mener det... jeg er sådan set bedøvende... Nok var URL encode en løsning... men nu var det jo en forklaring jeg ledte efter...
Mit egentlige spm var: ** Og så er det lige at jeg ikke helt kan se hvorfor det er sådan... for efter som ** jeg Kryptere den og konvertere de krypterede bytes til Base-64 burde der da ** umiddelbart ikke være problemer med at vende tilbage igen?
Og der mener jeg ikke at et "du URL-Encoder ikke" rækker, for nej det ved jeg da godt jeg ikke gør efter som jeg har valgt ikke at gøre det???...
md_craig> Du specificerede ikke hvad det var som du mente "en faktor 10+" på, så jeg gik ud fra at det var længden - at du mente at din URL-encodede streng var 10+ gange længere end hvis du ikke URL-encode den. Og det er den jo bestemt ikke. My bad, jeg indså ikke lige at du mente eksekveringsmæssigt.
Ja, en URL-encode tager længere tid end en Replace - når du altså kun køre den på et enkelt tegn - '+'. En faktor 10 svare vel til at en URLencode implementeres som Replace på mindst 10 forskellige tegn og det er vel egentligt rimeligt nok når man ser hvor mange tegn det er som bør URL-encodes.
At du ikke har oplevet problemer med andre tegn, antager jeg nu mere er et held end en indikation af at det aldrig vil gå galt. Hvorfor skulle det kun være '+' som gik galt? Du forklare jo selv at '+' opfattes som et space ' ' og dette skyldes jo netop at dette tegn har en special-funktion i forbindelse med URLs. Nuvel, men det har '?', '&' og '=' altså også, så hvorfor går netop disse tegn godt mens at '+' fejler?
Hvad sker der f.eks. den dag hvor at du tilfældigvis får noget i stil med:
- blot fordi at din data-streng DES-kryptere til "qwerty&asdfg=zxcvbn"?
Behold bare de 30 points, det betyder såmen ikke så meget. :^)
Tonen skyldes bare at jeg blev bare en smule fortørnet over at du på den ene side erkendte at det var URL-encodningen som var problemet (10/04-2005 10:20:05), men på den anden side ikke krediterede det: Ja, jeg mener faktisk at jeg forklarede hvad dit problem var. :^|
** At du ikke har oplevet problemer med andre tegn, antager jeg nu mere er et held ** end en indikation af at det aldrig vil gå galt. Hvorfor skulle det kun være '+' ** som gik galt? Du forklare jo selv at '+' opfattes som et space ' ' og dette ** skyldes jo netop at dette tegn har en special-funktion i forbindelse med URLs. ** Nuvel, men det har '?', '&' og '=' altså også, så hvorfor går netop disse tegn ** godt mens at '+' fejler? ** ** Hvad sker der f.eks. den dag hvor at du tilfældigvis får noget i stil med: ** http://DinServer/DitScript.aspx?DinKrypteredeStreng=qwerty&asdfg=zxcvbn
Den dag kommer ikke ;)... alt og jeg mener alt i min Query bliver krypteret...
Som det var tænkt før (og da '+' gav problemer) ville de tegn rigtit nok være et problem... men nu har jeg faktisk slet ikke behov for alt det bras mere...
det med replace af ' ' til '+' har bare hængt ved. men har lige prøvet og det er slet ikke nødvendigt mere... så nu har jeg vist den helt rigtige løsning til det jeg skal bruge det til... _____________________________________________________________________________________
der er altså ingen default.aspx?dinKrypteredeStreng=nogetbrass... derfor får jeg altid kun en ren lang kryptering og derfor bliver de sedvanlige operatorer der er i forbindelse med ens Query ('=' og '&') helt overflødelige...
det jeg bruger er så "Request.Url.Query" og som det viser sig henter den din Query helt RAW, dvs at +'er heller ikke bliver reformateret ser det ud til...
Så faktisk er det den Rigtige løsning i mit tilfælde... Og nu burde URL-Encode så falde helt uden for perspektiv...
Synes godt om
Ny brugerNybegynder
Din løsning...
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.
