mboost-dp1
Full Trust Silverlight
Som det ser ud i dag er der ikke mulighed for asymmetric kryptering i Silverlight i medium-trust.
En ting er at skulle bruge adgang til brugerens keystore (X.509 certifikater), men ikke engang med en statisk certifikat er det muligt at benytte asymmetric RSA kryptering.
Selvom det ikke ser ud til at være muligt, vil jeg da lige lufte tanken her, så er der nogen som ved om man kan promte brugeren til at godkende et Full Trust enviroment i deres browser?
Ellers bliver løsningen en thin-client som skal installeres, da jeg synes at DanId's OpenOCES java løsning er utrolig dårlig (både i implementation og i kode).
Fordi det virker utrolig ironisk... at sikkerhed er grunden til at man ikke kan bruge sikre krypteringsalgoritmer ;)
En ting er at skulle bruge adgang til brugerens keystore (X.509 certifikater), men ikke engang med en statisk certifikat er det muligt at benytte asymmetric RSA kryptering.
Selvom det ikke ser ud til at være muligt, vil jeg da lige lufte tanken her, så er der nogen som ved om man kan promte brugeren til at godkende et Full Trust enviroment i deres browser?
Ellers bliver løsningen en thin-client som skal installeres, da jeg synes at DanId's OpenOCES java løsning er utrolig dårlig (både i implementation og i kode).
Fordi det virker utrolig ironisk... at sikkerhed er grunden til at man ikke kan bruge sikre krypteringsalgoritmer ;)
1. Applets stinker. Virkelig, der er intet acceptabelt browser plugin efter mere end 10 år, og applets er fortsat langesomme og gør browserne ustabile og for højt memoryforbrug.
2. Koden TDC skrev i sin tid er dårlig Java 1.4, der er blant andet slet ikke brugt generics, og Java har ikke de nødvendige klasser til X509 certifikater, og derfor bruger TDCs kode JNI til at køre nogle C++ DLLs.
Jeg vudere at der er flere tusinde linjer i deres projekt, som er totalt overflødiggjort af .NETs Security.Security.Cryptographics bibliotek.
Så at tilpasse java koden ville være noget tæt på en total omskrivning, og da resten af projektet er udført i C# virker det som lidt meget af gøre ud af det (Begrænset tidsramme, med meget fast deadline).
2. Koden TDC skrev i sin tid er dårlig Java 1.4, der er blant andet slet ikke brugt generics, og Java har ikke de nødvendige klasser til X509 certifikater, og derfor bruger TDCs kode JNI til at køre nogle C++ DLLs.
Jeg vudere at der er flere tusinde linjer i deres projekt, som er totalt overflødiggjort af .NETs Security.Security.Cryptographics bibliotek.
Så at tilpasse java koden ville være noget tæt på en total omskrivning, og da resten af projektet er udført i C# virker det som lidt meget af gøre ud af det (Begrænset tidsramme, med meget fast deadline).
Windcape (3) skrev:Så at tilpasse java koden ville være noget tæt på en total omskrivning, og da resten af projektet er udført i C# virker det som lidt meget af gøre ud af det (Begrænset tidsramme, med meget fast deadline).
Netop med en skrap deadline vil jeg anbefale at tage noget fungerende kode som virker og tilrette fremfor at skrive en ny løsning.
Worst case med den eksisterende kode er at man bliver nødt til at rulle nogle af sine rettelser tilbage fordi de ikke virker og leve med det originale.
Worst case for ny kode er at man ikke kan få det til at virke og ingenting har.
Derfor C# er valgt, da .NETs standard API virker (og en del bedre) end noget mange år gammel Java kode uden dokumentation.arne_v (4) skrev:Netop med en skrap deadline vil jeg anbefale at tage noget fungerende kode som virker og tilrette fremfor at skrive en ny løsning.
Silverlight er en udvidelsesmodel til fremtiden, men jeg vil helst have styr på om det er en nem eller problematisk udvidelsesmodel før den endelige tidsplan bliver fastlagt.
Windcape (3) skrev:Applets stinker. Virkelig, der er intet acceptabelt browser plugin efter mere end 10 år, og applets er fortsat langesomme og gør browserne ustabile og for højt memoryforbrug.
En applet bruger kun op til 64 MB heap (medmindre man er på 6u10+ og eksplicit beder om mere). Det er faktisk ikke ret meget memory efter dagens standard.
Og hvis man ikke presser citronen for hårdt så virker de faktisk over hele linien (presse citronen for hårdt er hvis man begynder at kode efter at multiple applets kører i samme JVM og den slags).
Windcape (3) skrev:Koden TDC skrev i sin tid er dårlig Java 1.4, der er blant andet slet ikke brugt generics,
Tro det eller ej, men folk overlevede faktisk at skrive kode uden generics i præ-1.5 Java og præ-2.0 C#.
Windcape (3) skrev:og Java har ikke de nødvendige klasser til X509 certifikater,
Java har fin support for X509 certifikater.
java.security.cert.X509Certificate og venner.
Den har ihvertfald eksisteret siden 1.3.1 sandsynligvis længere.
Windcape (3) skrev:og derfor bruger TDCs kode JNI til at køre nogle C++ DLLs.
List mystisk.
Java har support for X509 certifikater.
Og applets og JNI er en kombination af samme kvalitet som trekantede hjul.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund