De Devschuur Coffee Corner

[caoim]

Graaf is waarschijnlijk typisch Vlaams I guess

[riezebosch]

Haan schreef op maandag 05 oktober 2009 @ 12:44:
Ik zie hier heel vaak jQuery voorbij komen, maar heb er zelf nog niet mee gewerkt. Kan iemand vertellen wat er zo mooi aan is? (ik ben nu eens op jquery.com begonnen met lezen). Steeds als ik de term voorbij zie komen krijg ik een beetje het gevoel dat jQuery gehyped wordt net als de term AJAX, dus ben ik benieuwd wat de ervaringen in de praktijk zijn

Staat een artikel in het .NET Magazine van september.

[Sebazzz]

NMe schreef op woensdag 07 oktober 2009 @ 13:34:
[...]

Ja, want dat is elegant wou je zeggen.

Nee PHP is zowieso lekker elegant

[Exirion]

Interface Builder Je zou hopen dat XCode plus Interface Builder een redelijke RAD omgeving biedt maar je moet zoveel handmatig instellen en wroeten in wazig ingedeelde menu's dat je net zo goed je hele UI opbouw in code kunt inkloppen. Om IB te kunnen gebruiken moet je, itt bijvoorbeeld bij Delphi/C++Builder, zo goed weten wat er onder water allemaal moet gebeuren dat je juist sneller bent met code kloppen. Ook resulteert dat in een minder versnipperde en dus overzichtelijkere implementatie. Wat ze bij Apple denken is me af en toe een raadsel.

[Cartman!]

.oisyn schreef op woensdag 07 oktober 2009 @ 13:45:
Lieve schat, de discussie ging om het gebruik van 'or'

Je hebt gelijk, een andere mogelijkheid geven op een discussieforum is waanzin

[R4gnax]

Cartman! schreef op woensdag 07 oktober 2009 @ 12:19:
Wat ik mis in jQuery is het gebruik van classes, of zit dat er tegenwoordig wel in? Wij werken al jaren met MooTools en ik ben er erg tevreden over.

JQuery UI bevat de $.widget() functie welke je kunt gebruiken om een nieuwe widget 'class' te definiëren.

Widget heeft standaard functionaliteit voor property getters/setters, een constructor, een destructor (die automatisch aangeroepen wordt als het HTMLElement waarop de widget gebouwd wordt uit de DOM tree verwijderd wordt), interne data storage, private functies, etc.

Je kunt er ook best goed 'class-based' mee programmeren, zolang je niet complete klassieke class inheritance usw. toe wilt gaan passen.

offtopic:
Daarnaast is jQuery gestoeld op chaining van functies op HTMLElement nodes en het gebruik van closures. Het is een heel andere filosofie dan object-georiënteerd programmeren. Je zou er goed aan doen eens te proberen met de library mee te gaan, in plaats van tegen de stroming in proberen te zwemmen. Zul je zien dat closures heel handig kunnen zijn en de gemiddelde javascript code stukken korter én leesbaarder krijgen dan een OO implementatie...

[ Voor 23% gewijzigd door R4gnax op 07-10-2009 16:31 ]

[Cartman!]

Dat ga ik eens bekijken dan, thanks Overigens kun je MooTools ook gewoon chainen dus dat is niet specifiek iets voor jQuery, erg handig iig.

[YopY]

Is het erg als ik uit verveling een ding (dat ik eerder al gepost heb overigens) blijf optimaliseren?

Is een speciale HTML special chars functie, hij moet letterkarakters wel replacen, maar speciale karakters (? en & enzo) niet, dus URLEncode zelf valt af.

De oude versie (zie een eerdere post) gebruikte een... zestigtal String.replaceAll() (Java) aanroepen. String.replaceAll() gebruikt een regular expression om zooi te replacen.

De nieuwe versie gebruikt CharacterIterator, een 'cache' array van eerder geënncodeerde karakters, en chars ipv de daadwerkelijke letters (aangezien het chars 192 tot 255 zijn).

Ik bespaar jullie de copypasta, dus zie hier: http://pastebin.com/f5382dfe9

De oude versie deed 600 - 700 ms over een string van 100.000 karakters, deze versie 0 tot 15 (waar 15 een vaak voorkomende hoeveelheid is, waarschijnlijk een subproces van Java).

...kan het nog sneller? =D

[.oisyn]

Vast wel, als je niet overal String objecten voor gebruikt en zelf handmatig die hex codes omzet.

.edit:

Java:

    private final static char[] hexChars = "0123456789ABCDEF".toCharArray();
    
    public static String oisynsSpecialChars(String str)
    {
        char[] chars = str.toCharArray();
        StringBuilder b = new StringBuilder(chars.length * 2);
        int start = 0;
        for (int pos = 0; pos < chars.length; pos++)
        {
            int c = (int)chars[pos];        
            if (c < 192 || c > 255)
                continue;
            b.append(chars, start, pos - start);
            b.append('%');
            b.append(hexChars[c >> 4]);
            b.append(hexChars[c & 0x0f]);
            start = pos + 1;
        }
        if (start < chars.length)
            b.append(chars, start, chars.length - start);
        return b.toString();
    }

  Old: run 0: 191062740
  Old: run 1: 148127875
  Old: run 2: 155312640
  Old: run 3: 143610155
  Old: run 4: 143241027
  Old: run 5: 163664997
  Old: run 6: 143911755
  Old: run 7: 140052658
  Old: run 8: 140264266
  Old: run 9: 139724850
  New: run 0: 12668447
  New: run 1: 3606485
  New: run 2: 3205315
  New: run 3: 3362326
  New: run 4: 3313120
  New: run 5: 2965485
  New: run 6: 3294263
  New: run 7: 3671571
  New: run 8: 3042937
  New: run 9: 3297122
oisyn: run 0: 14163826
oisyn: run 1: 2334395
oisyn: run 2: 2569716
oisyn: run 3: 2435737
oisyn: run 4: 1940333
oisyn: run 5: 2273398
oisyn: run 6: 2177925
oisyn: run 7: 1876602
oisyn: run 8: 2223090
oisyn: run 9: 2181979

1.5x zo snel als jouw snelste implementatie
(Gebruik trouwens System.nanoTime() voor nauwkeurigere metingen)

[ Voor 109% gewijzigd door .oisyn op 08-10-2009 16:02 ]

[YopY]

Ah, owned xD. Ik was zonet al blij om te zien dat hij sowieso sneller was dan URLEncoder vanuit Java zelf.

Die van mij is een tikkie vlotter dan eerst met een for-loop zonder die char iterator en door de te converteren chars van te voren in een array te zetten, maar die van jou is nog steeds vlotter.

Zo'n ster ben ik nog niet in low-level programmeren, .


(en om eerlijk te zijn vindt ik dat wel best )

Edit: Hrm, het verschil is niet zo groot meer, geen 1.5 keer sowieso. Alleen die van mij hangt zichzelf nu op als 'ie een string van 10 miljoen karakters krijgt, waarschijnlijk vanwege het gebruik van String ipv chars in de StringBuilder.

[ Voor 21% gewijzigd door YopY op 08-10-2009 16:41 ]

[.oisyn]

Het zal ook wel helpen om de StringBuilder van tevoren een aardige chunk geheugen te geven (de constructor met een int argument), zodat hij z'n interne buffer niet steeds hoeft te resizen als hij vol zit. Voor de rest zal de bottleneck wel in URLEncoder.encode() zitten.

[YopY]

.oisyn schreef op donderdag 08 oktober 2009 @ 16:45:
Het zal ook wel helpen om de StringBuilder van tevoren een aardige chunk geheugen te geven (de constructor met een int argument), zodat hij z'n interne buffer niet steeds hoeft te resizen als hij vol zit. Voor de rest zal de bottleneck wel in URLEncoder.encode() zitten.

Dat kan, maar dat is opgelost door de karakters 192 tot 255 alvast door de functie te halen in een static blok, zodat dat slechts eenmaal gedaan wordt. Scheelt ook een controle op de aanwezigheid in de array bij elk karakter. 10 miljoen maal triviaal = minder triviaal, ;D.

Mja, entertainment op de donderdagmiddag.

[TJHeuvel]

Van de Facebook Wiki:

smartsize	bool	This parameter smartly sizes the iframe to fit the remaining space on the page and disables the outer scrollbars. If you include more than one smartsizing iframe, they automatically distribute the size appropriately. (Default value is false.)
frameborder	int	Indicates whether to show (1) or hide (0) an iframe border. (Default value is 1.)
scrolling	string	Indicates whether to show scrollbars. (Default value is yes.) - use "yes", "no", or "auto" (not "true" or "false")

[Verwijderd]

Mooi stukje consistentie

[D-Raven]

Aawww wat is die API toch zo geweldig consistent heh

[ Voor 0% gewijzigd door D-Raven op 09-10-2009 11:48 . Reden: hmm volgende keer wat sneller op post rammen :P ]

[Cartman!]

In een uurtje "niks te doen" even mn authenticatie ding uitgebreid. Maak nu (optioneel) gebruik van salt per user icm. challenge/response. Wachtwoord over de lijn is daarmee altijd anders. Toch geinig. Als iemand geen JS heeft dan werkt het gewoon zonder versleuteling.

edit: ipv. per user salt is ook een serverwide salt te gebruiken, dan hoeft er geen ajax-request gebruikt te worden om de salt op te halen.

[ Voor 20% gewijzigd door Cartman! op 09-10-2009 12:19 ]

[whoami]

riezebosch schreef op woensdag 07 oktober 2009 @ 14:16:
[...]

Staat een artikel in het .NET Magazine van september.

Which reminds me, dat het al een hele tijd geleden is dat ik nog eens zo'n .NET magazine ontvangen heb ...

[.oisyn]

Cartman! schreef op vrijdag 09 oktober 2009 @ 12:18:
edit: ipv. per user salt is ook een serverwide salt te gebruiken, dan hoeft er geen ajax-request gebruikt te worden om de salt op te halen.

Waarom zou je voor de user salt per se een ajax request nodig hebben dan?

[Cartman!]

Anders weet ik clientside niet met welke user ik te maken heb...?

edit:

ik bedoel dus, iemand vult username+password in, en als ik het wil hashen om te vergelijken met wat ik in de database heb ik moet ik hash(salt+password) toepassen, maar dan heb ik wel de salt van die user nodig die probeert in te loggen. Een andere manier zou ik anders niet echt weten, als je een goed/beter idee hebt dan wil ik t graag weten

[ Voor 73% gewijzigd door Cartman! op 09-10-2009 13:14 ]

[BalusC]

Stuur gewoon de input naar de server side en laat de server side het antwoord teruggeven?

[Cartman!]

En wat is dat beterdan het via een XHR doen wat de gebruiker niet merkt?

[.oisyn]

Cartman! schreef op vrijdag 09 oktober 2009 @ 13:06:
Anders weet ik clientside niet met welke user ik te maken heb...?

Ah ja, je hebt gelijk, ik redeneerde wat krom.

[BalusC]

Cartman! schreef op vrijdag 09 oktober 2009 @ 13:22:
En wat is dat beterdan het via een XHR doen wat de gebruiker niet merkt?

Ik snap je niet of je snapt het niet.

Laat de server gewoon de binnengekregen wachtwoord hashen/zouten en beantwoord dan de client of de username+wachtwoord correct is of niet. That's all. Je hebt de zout helemaal niet clientside nodig, dat zou de zout anders compleet overbodig maken (security leak). Of denk ik nu te simpel?

[Cartman!]

De bedoeling is juist om het hashen clientside te doen zodat het wachtwoord niet plain over de lijn gaat. Het is niet zo erg dat de client de salt weet, de salt is in feite alleen bedoeld om een dictionary-attack te voorkomen als iemand toegang krijgt tot de database.

[.oisyn]

BalusC schreef op vrijdag 09 oktober 2009 @ 14:35:
[...]

Ik snap je niet of je snapt het niet.

Laat de server gewoon de binnengekregen wachtwoord hashen/zouten en beantwoord dan de client of de username+wachtwoord correct is of niet. That's all. Je hebt de zout helemaal niet clientside nodig, dat zou de zout anders compleet overbodig maken (security leak). Of denk ik nu te simpel?

Het is een challenge/response systeem waarin het wachtwoord dus sowieso niet over het net gaat, maar md5(hashed_wachtwoord + challenge). De server kan vervolgens kijken of dat klopt (want die weet hashed_wachtwoord en challenge). Het probleem zit 'm in het feit dat hashed_wachtwoord weer gelijk is aan md5(wachtwoord + user_salt), en user_salt staat ook in de database opgeslagen. De client heeft user_salt nodig om zelf hashed_wachtwoord te berekenen om uiteindelijk md5(hashed_wachtwoord + challenge) door te sturen.

[ Voor 14% gewijzigd door .oisyn op 09-10-2009 14:46 ]

[BalusC]

Ah duidelijk, ik had niet eerder gehoord van "challenge/response" in deze context. Thanks

[Cartman!]

Bedankt voor de uitleg die ik had moeten geven

Wat ik nu doe, tijdens het laden genereer ik een random hash en die zet ik in de pagina. Iemand vult username+password in, ik vraag dan met een xhr de juiste salt op (ik return een fake random salt als de user niet bestaat). Dan bereken ik

code:

hash(challenge + hash(salt+password))

Ik verwijder het veld password uit de DOM en vervang deze met een veld dat response heet.

Serverside valideer ik t:

code:

response == hash(challenge + db_entry)

Zo is het wachtwoord over de lijn altijd anders en kun je t toch valideren. Ik *denk* dat deze methode vrij safe is gezien toch een keer iets over de lijn moet. Als iemand toegang krijgt tot je database dan zou je per wachtwoord moeten attacken ipv. op de hele tabel in 1 keer vanwege de wisselende salt.
Aanvulling nog: omdat de challenge serverside in de sessie zit is de response maar 1 keer geldig, een volgende login zal er een andere challenge zijn. Replay attack werkt dus niet.

Hoop dat ik t goed uitgelegd hebt zo, als iemand denkt dat t beter kan: vertel het me, want ik vind het wel geinig het beter te maken als t kan (kom dan niet met dat ik https moet gebruiken, t gaat om t systeem zelf, niet het protocol).

[ Voor 7% gewijzigd door Cartman! op 09-10-2009 14:57 . Reden: kleine edit ]

[Woy]

Cartman! schreef op vrijdag 09 oktober 2009 @ 14:52:
(ik return een fake random salt als de user niet bestaat).

Daar lijkt me een kleine flaw te zitten. Als je gewoon 2 keer een request doet voor een user weet je of hij bestaat als je 2 maal dezelfde salt krijgt.

Beter kun je IMHO een salt returnen die afhankelijk is van de username die opgevraagd word.

[Cartman!]

Goed punt ja, daar zat ik net ook al over na te denken. Ik maak gewoon een hash van de username en return daar de lengte van zolang de salt is. Tnx.

[pedorus]

Cartman! schreef op vrijdag 09 oktober 2009 @ 14:52:
Zo is het wachtwoord over de lijn altijd anders en kun je t toch valideren. Ik *denk* dat deze methode vrij safe is gezien toch een keer iets over de lijn moet. Als iemand toegang krijgt tot je database dan zou je per wachtwoord moeten attacken ipv. op de hele tabel in 1 keer vanwege de wisselende salt.

Hoezo? Als je nu de database hacked heb je db_entry, en al alles wat je nodig hebt. Waarom zou je teruggaan naar het originele wachtwoord?

[Cartman!]

Je gaat ook niet terug naar t originele wachtwoord. Maar als iemand een wachtwood als md5 ergens heeft staan dan zou je t met een rainbowtable kunnen terugrekenen naar het originele wachtwoord. Vaak heeft iemand wel een e-mailadres in een account, als je dan hetzelfde wachtwoord gebruikt kan iemand ook op andere plekken misbruik maken van je gegevens. Hiermee is dat niet rendabel omdat je het niet meer kunt terugrekenen.

om luie redenen gebruik ik sha1 in de database. T liefst zou ik sha256 pakken, daar is ook een prima javascript implementatie voor maar dan kun je niet meer in de phpMyAdmin ff snel een nieuw password instellen en dat irriteert mn collega's Ik heb gewoon een file waarmee ik hashes kan maken maar dat willen ze niet gebruiken. Ben helaas de enige securityhoer hier lijkt t

[ Voor 31% gewijzigd door Cartman! op 09-10-2009 15:13 ]

[Verwijderd]

Damn, busted! € 21,50 invoerrechten betalen over m'n Amazon pakketje. Ach, ze zijn in ieder geval binnen en nog steeds goedkoper dan bol.com

[pedorus]

Cartman! schreef op vrijdag 09 oktober 2009 @ 15:08:
Je gaat ook niet terug naar t originele wachtwoord. Maar als iemand een wachtwood als md5 ergens heeft staan dan zou je t met een rainbowtable kunnen terugrekenen naar het originele wachtwoord. Vaak heeft iemand wel een e-mailadres in een account, als je dan hetzelfde wachtwoord gebruikt kan iemand ook op andere plekken misbruik maken van je gegevens. Hiermee is dat niet rendabel omdat je het niet meer kunt terugrekenen.

Volgens mij begrijp je het probleem nog niet. Als je nu je database hacked, kun je gewoon direct op je site inloggen. Er is totaal geen noodzaak meer om iets te 'terugrekenen', het originele wachtwoord boeit niet. Daarnaast heb je vaak ook nog het concept dat je normaal ook een extra salt hebt, die niet in de database staat en ook niet wordt overgezonden, maar in de code staat. Dat stukje beveiliging heb je hier ook niet.

[Cartman!]

Ja, zeker kan dat, daar ben ik me van bewust. Maar als je de database al inkunt heb je toch alle gegevens al tot je beschikking die je zou zien als je kunt inloggen in principe. De veiligheid erin is dat de wachtwoorden van je gebruikers veilig zijn, dat is iig. mijn insteek. Maar je hebt zeker gelijk.

weer een edit:
als je toegang hebt tot de database kun je gewoon een nieuwe sessie aanmaken met een eigen gekozen sessionID met een gekoppelde userid naar keuze. Zet een cookie met je eigen sessieID en hops, ingelogd als de gekozen user. Zo werkt het op GoT in feite ook.

[ Voor 31% gewijzigd door Cartman! op 09-10-2009 15:16 ]

[.oisyn]

@pedorus: En volgens mij begrijp jij niet dat die hash bestaat om de user te beschermen tegen het feit dat z'n originele wachtwoord niet op straat ligt zodra de database gehacked wordt, en de hacker dus bijv. ook niet kan inloggen op z'n e-mail account omdat de domme user nou eenmaal overal hetzelfde wachtwoord gebruikt.

pedorus schreef op vrijdag 09 oktober 2009 @ 15:13:
Daarnaast heb je vaak ook nog het concept dat je normaal ook een extra salt hebt, die niet in de database staat en ook niet wordt overgezonden, maar in de code staat. Dat stukje beveiliging heb je hier ook niet.

Hoe weet je dat? Hij heeft het steeds over de functie hash().

PHP:

function hash($str)
{
    return md5("mijn supergeheime salt die in de code staat en niet in de db" . $str);
}

[ Voor 58% gewijzigd door .oisyn op 09-10-2009 15:19 ]

[Woy]

pedorus schreef op vrijdag 09 oktober 2009 @ 15:13:
[...]

Volgens mij begrijp je het probleem nog niet. Als je nu je database hacked, kun je gewoon direct op je site inloggen. Er is totaal geen noodzaak meer om iets te 'terugrekenen', het originele wachtwoord boeit niet. Daarnaast heb je vaak ook nog het concept dat je normaal ook een extra salt hebt, die niet in de database staat en ook niet wordt overgezonden, maar in de code staat. Dat stukje beveiliging heb je hier ook niet.

Het probleem is dan ook niet zo dat iemand op de site in kan loggen met een username. Die is waarschijnlijk toch al compromised als je al in de database kan komen.

Het gaat meer om de bescherming van de wachtwoorden zelf.

[Woy]

Cartman! schreef op vrijdag 09 oktober 2009 @ 15:03:
Goed punt ja, daar zat ik net ook al over na te denken. Ik maak gewoon een hash van de username en return daar de lengte van zolang de salt is. Tnx.

Ik zou denk wel een hash van de username + een private key doen. Een hash van de username ligt wel erg voor de hand, dan is het alsnog makkelijk te controleren of een user bestaat.

[Cartman!]

Ja, had ik al gedaan, tnx

[RayNbow]

* RayNbow is een beetje laat, maar goed...

Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes

^ misschien interessant leesvoer uit 2007...

[pedorus]

Woy schreef op vrijdag 09 oktober 2009 @ 15:16:
[...]

Het probleem is dan ook niet zo dat iemand op de site in kan loggen met een username. Die is waarschijnlijk toch al compromised als je al in de database kan komen.

Maar de vraag is of na het oplossen daarvan iedereen zijn wachtwoord moet wijzigen (ala fok.nl).

Het gaat meer om de bescherming van de wachtwoorden zelf.

Hmm, ja, maar als je de server niet vertrouwd, dan kun je de javascript die naar de client verstuurd wordt natuurlijk ook niet vertrouwen. In dat opzicht zie ik geen echte toegevoegde veiligheid.

[Cartman!]

Daarna moet iedereen sowieso zn wachtwoord wijzigen ja, maar vooral zorgen dat het echte lek op je server gedicht is. Desnoods vult iemand hetzelfde wachtwoord weer in, de salt is gewijzigd en daarmee de uiteindelijke password hash ook. In een 'normale' situatie kun je de server vertrouwen imo.

andere vraag voor jou: hoe zou je het dan doen om ook jouw situatie te omzeilen?

[ Voor 12% gewijzigd door Cartman! op 09-10-2009 15:29 ]

[Woy]

.oisyn schreef op vrijdag 09 oktober 2009 @ 15:16:
Hoe weet je dat? Hij heeft het steeds over de functie hash().

PHP:

function hash($str)
{
    return md5("mijn supergeheime salt die in de code staat en niet in de db" . $str);
}

Dat voegt alleen niet zoveel toe, want de hash functie moet ook op de client beschikbaar zijn, en dus zal "mijn supergeheime salt die in de code staat en niet in de db" niet geheim zijn, en dus geen extra veiligheid bieden.

pedorus schreef op vrijdag 09 oktober 2009 @ 15:25:
[...]
Maar de vraag is of na het oplossen daarvan iedereen zijn wachtwoord moet wijzigen (ala fok.nl).

Ja in principe wel, de gegevens in de DB zijn altijd genoeg om in te kunnen loggen. Het voordeel is echter dat er niet eenvoudig wachtwoorden achterhaald kunnen worden. Ik zou echter niet weten hoe je dat kan voorkomen.

Hmm, ja, maar als je de server niet vertrouwd, dan kun je de javascript die naar de client verstuurd wordt natuurlijk ook niet vertrouwen. In dat opzicht zie ik geen echte toegevoegde veiligheid.

Dat is wel een punt van aandacht. Als je server echt compromised is zodat ze je scripts aan kunnen passen, dan kan een aanvaller er ook gewoon voor zorgen dat de passwords op een andere manier bij hem terecht komen. Maar ook hier zie ik weer niet hoe je dat wilt voorkomen, zonder dat de gebruiker elke keer controleert welk script er precies draait.

[ Voor 5% gewijzigd door Woy op 09-10-2009 15:33 ]

[pedorus]

Cartman! schreef op vrijdag 09 oktober 2009 @ 15:28:
andere vraag voor jou: hoe zou je het dan doen om ook jouw situatie te omzeilen?

Gewoon de standaard-oplossing gebruiken, en dit achterwege laten.

Maar goed, toch even een idee:
2 salts (en waarschijnlijk nog 2 extra om van de standaard-hashfuncties weg te komen zoals .oisyn laat zien).

In de database staat salt1, salt2, en hash1(salt1+hash2(salt2+password)). Client krijgt beschikking over salt2 (uit db via request), wachtwoord, en de hash2-functie. Eventueel kun je salt2 schrappen, om het wat eenvoudiger te maken.

[Cartman!]

Maar als je toegang hebt tot de database dan kun je toch nog steeds overal bij? Behalve dat het iets ingewikkelder in elkaar zit zie ik weinig concrete verschillen waar een aanvaller echt iets mee kan. Volgens mij is het enige dat je niet een replay kan doen op hash(challende+db_entry) maar of dat je nu gaat helpen als iemand toegang heeft tot je server? Ik denk t niet. Goed bedacht overigens, dat wel.

[YopY]

RayNbow schreef op vrijdag 09 oktober 2009 @ 15:24:
* RayNbow is een beetje laat, maar goed...

Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes

^ misschien interessant leesvoer uit 2007...

Interessant leesvoer, inderdaad . Het is jammer dat de meeste (*kuch*php*kuch*) tutorials nog steeds MD5 of SHA-1 promoten (al dan niet met een salt), terwijl dit artikel duidelijk maakt dat ook dat niet echt geweldig is.

Vooral het punt dat een goeie hash functie voor het opslaan van passwords langzaam moet zijn is een sterke.

---

Overigens, ipv een challenge / response systeem, is het oversturen van een wachtwoord over een HTTPS verbinding veilig?

[.oisyn]

yup.

[Woy]

Idd, HTTPS bied zekerheid over de identiteit van de server, en garanties dat 3den de communicatie niet kunnen afluisteren of wijzigen ( Mits de private key van het certificaat ( of TTP ) niet compromised is )

[Soultaker]

YopY schreef op vrijdag 09 oktober 2009 @ 16:00:
Interessant leesvoer, inderdaad . Het is jammer dat de meeste (*kuch*php*kuch*) tutorials nog steeds MD5 of SHA-1 promoten (al dan niet met een salt), terwijl dit artikel duidelijk maakt dat ook dat niet echt geweldig is.

Och, voor de meeste webtoepassingen is dat prima. Ik ben al lang blij als m'n plaintext password niet op straat komt te liggen, en de meeste websites authenticeren nog gewoon via HTTP, wat natuurlijk niet echt secure is, dus dan is het vrij zinloos om de beveiliging binnen de authenticatieserver verder te verbeteren.

Vooral het punt dat een goeie hash functie voor het opslaan van passwords langzaam moet zijn is een sterke.

Als je 't daarvan moet hebben... Het zou beter zijn als gebruikers een beetje zinnige wachtwoorden zouden kiezen, maar als password1 het populairste wachtwoord is dan kun je je hash functie zo traag maken als je wil maar dan valt 'ie toch wel te bruteforcen.

edit:
Ik vraag me trouwens af hoe Tweakers.net dit geïmplementeerd heeft?

[ Voor 3% gewijzigd door Soultaker op 09-10-2009 16:32 ]

[Cartman!]

MyReact gebruikt md5 zonder salt ieder geval, ik weet niet in welke mate React hier van verschilt is de kans vrij groot dat dit ook md5 is zonder salt. Ik heb zover ik weet nooit een melding gekregen dat ik verplicht mn password moest resetten.

dit quote ik van een developer van MyReact/React:

md5 is alleen geïmplementeerd om de daadwerkelijke wachtwoorden te beschermen; en niet de toegang. De enige juiste wijziging voor extra bescherming tegen woordenboek aanvallen zou een salt zijn; dit vereist echter weer wat logica en we hebben hier zelf nog nooit behoefte aan gehad

Ja ik weet dat GoT een fork is van React, maar gezien ik dus nooit gedwongen ben mn password te updaten denk ik niet dat zij ineens een salt+wachtwoord hebben kunnen maken, ze zouden mn originele password immers niet weten.

[ Voor 57% gewijzigd door Cartman! op 09-10-2009 16:38 ]

[Soultaker]

Nee inderaad, ik ook niet. In principe zouden ze het automatisch kunnen doen (als je inlogt via het oude systeem, kunnen ze een geüpdatete hash van je wachtwoord opslaan, en die verder gebruiken). Sowieso lijkt het me waarschijnlijk dat Tweakers.net een eigen authenticatiesysteem hanteert, want je kunt met één account inloggen op de frontpage en het forum...

[Cartman!]

Hoezo eigen? Het enige wat er gebeurt is dat je inlogt en vervolgens een sessie krijgt, als je die sessie eenmaal hebt gebeurt er niks meer met wachtwoorden.

En ze kunnen het wel updaten als je em invoert maar dan slaan ze nog steeds de enkel md5 gehashte versie op, heb je er nog weinig aan (tenzij ze die weggooien als ze de nieuwe hebben). Ik log als versleuteld in overigens dus de server krijgt nooit mn originele password terug.

[HuHu]

code:

OUD  :     md5($pass);
NIEUW: md5(md5($pass) . $salt);

Zo kun je heel eenvoudig overstappen op het gebruik van een salt zonder dat iedereen z'n wachtwoord moet updaten.

[Soultaker]

Dat is idd ook een mooie fix.

[Verwijderd]

Hmm, ik wil iets programmeren, maar ik weet niet wat

[RayNbow]

Verwijderd schreef op zondag 11 oktober 2009 @ 13:13:
Hmm, ik wil iets programmeren, maar ik weet niet wat

Project Euler
Programming Praxis
Etc.
?

[Verwijderd]

Ooh ja, Euler is wel weer eens leuk om te doen Eigenlijk wil ik wat groters doen dan puzzeltjes, maar het is leuk pass-time

[ Voor 45% gewijzigd door Verwijderd op 11-10-2009 13:47 ]

[Soultaker]

CodeCup 2010 ;-)

Verder wachten op PRG Contest #5 natuurlijk.

[Verwijderd]

CodeCup 2010, goed idee! Heb nog nooit aan zoiets meegedaan eigenlijk, wordt wel eens tijd

[YopY]

Soultaker schreef op vrijdag 09 oktober 2009 @ 16:22:
Als je 't daarvan moet hebben... Het zou beter zijn als gebruikers een beetje zinnige wachtwoorden zouden kiezen, maar als password1 het populairste wachtwoord is dan kun je je hash functie zo traag maken als je wil maar dan valt 'ie toch wel te bruteforcen.

Sja. Je ziet wel een aantal sites verschijnen die dmv Javascript de sterkte van je wachtwoord testen - en als ze goed beveiligd zijn gaan ze gewoon het wachtwoord weigeren als het niet voldoet. De meeste sites (of, de meeste sites die ik tegenkom / op registreer) hebben al het vereiste dat je zoveel karakters moet hebben en een wachtwoord met letters en cijfers. Da's een Goed Ding, imo.

[RayNbow]

Soultaker schreef op vrijdag 09 oktober 2009 @ 16:22:
[...]

Als je 't daarvan moet hebben... Het zou beter zijn als gebruikers een beetje zinnige wachtwoorden zouden kiezen, maar als password1 het populairste wachtwoord is dan kun je je hash functie zo traag maken als je wil maar dan valt 'ie toch wel te bruteforcen.

Uit een van de comments:

This sample is representative of users *who fell for a phishing attack*; their passwords are likely to be weaker than more savvy users who avoided that trap.

Voor zulke mensen werkt geen enkel wachtwoordsysteem.

[Ryur]

Vandaag ook weer een domme actie.
Wij zijn nu nog op console-niveau bezig met Java.
De command "toString()"; waarvan ik dacht dat die het gelijk printte.
Maar blijkbaar niet. Heb daar ruim een uur vastgezeten totdat ik doorhad dat het moet zijn:

System.out.println(Deelnemer.toString());

Voel me zeer dom!

[Alex)]

Die is wel stom ja, .ToString() zet een random object om naar een string. Per object kan dit andere output geven:

Object Kind:
Naam = Pietje
Achternaam = Klaassen
Geslacht = M
Leeftijd = 3

Kind.ToString() kan als output geven: "Pietje Klaassen is een 3-jarig jochie."

[Pete]

GoTCoast schreef op dinsdag 13 oktober 2009 @ 18:01:

System.out.println(Deelnemer.toString());

Het idee is dat je nu ook het volgende kunt doen!

Java:

System.out.println(Deelnemer)

[Sebazzz]

Alex) schreef op dinsdag 13 oktober 2009 @ 20:05:
Kind.ToString() kan als output geven: "Pietje Klaassen is een 3-jarig jochie."

Dat is natuurlijk implementatieafhankelijk. Voor de meeste classes is het waarschijnlijk niet nodig dus die overriden .ToString() niet en laten het aan het base class over. (Als dat een System.Object is wordt dat dus iets van this.GetType().ToString()).

[JefSnare]

RayNbow schreef op zondag 11 oktober 2009 @ 13:27:
[...]

Project Euler
Programming Praxis
Etc.
?

Zitten leuke dingen tussen

[YopY]

Pete schreef op woensdag 14 oktober 2009 @ 07:42:
[...]


Het idee is dat je nu ook het volgende kunt doen!

Java:

System.out.println(Deelnemer)

^ dit. toString() is een functie die gedeclareerd wordt (en overridebaar is) in de Object class. OutStream.println(Object obj) wordt in dit geval aangeroepen, waarna obj.toString() aangeroepen wordt.

De implementatie van toString() is verder aan jezelf, zolang je er maar rekening mee houdt dat toString() gebruikt wordt als informatie, als console output, log output, dat soort dingen - als je het naar bijvoorbeeld CSV, JSON of XML wilt laten vertalen zou je daar een eigen functie voor moeten schrijven (bijvoorbeeld interfaces JSONizable, XMLizable, of een betere naam)

[OkkE]

Vandaag een beetje aan het stoeien geweest met @font-face, was heel interessant, alleen jammer dat het toch eigenlijk alleen in Firefox 3.5 echt goed werkt. Hopelijk verbeterd de support hier voor snel, toch een stuk relaxter als Cufon of sIFR.

Good Fella schreef op woensdag 14 oktober 2009 @ 16:45:
Werkt ook in Safari, Opera 10, IE4+ hoor

Het werkt, maar niet goed (genoeg) in de tests die ik gedaan heb.

Opera [10] vervormd sommige letters.
Safari [4] maakt de tekst vetter dan de overige browsers.
IE [6, 7 en 8] lijkt problemen te hebben met anti-alliasing (zoals vaker); en natuurlijk het *.eot formaat....
Chrome [3] doet het niet altijd en vervormd sommige letters.

Dit alles in zowel mijn eigen testjes als de demo's van Font Squirrel.

[ Voor 56% gewijzigd door OkkE op 14-10-2009 17:05 ]

[MoietyMe]

OkkE schreef op woensdag 14 oktober 2009 @ 16:39:
Vandaag een beetje aan het stoeien geweest met @font-face, was heel interessant, alleen jammer dat het toch eigenlijk alleen in Firefox 3.5 echt goed werkt. Hopelijk verbeterd de support hier voor snel, toch een stuk relaxter als Cufon of sIFR.

Werkt ook in Safari, Opera 10, IE4+ hoor

[Alex)]

Zucht, ik heb weer een leuke. Was aan het devven in Visual Studio (ASP.NET) en toen gaf mijn laptop een BSOD tijdens het runnen van die site in Cassini. En nu wil die hele site het niet meer doen omdat ergens gereferencede DLL's niet goed geladen kunnen worden (foutmelding: Invalid Parameter, E_INCORRECT_ARG oid).

Altijd leuk... not.

[roy-t]

OkkE schreef op woensdag 14 oktober 2009 @ 16:39:
Vandaag een beetje aan het stoeien geweest met @font-face, was heel interessant, alleen jammer dat het toch eigenlijk alleen in Firefox 3.5 echt goed werkt. Hopelijk verbeterd de support hier voor snel, toch een stuk relaxter als Cufon of sIFR.

[...]

Het werkt, maar niet goed (genoeg) in de tests die ik gedaan heb.

Opera \[10] vervormd sommige letters.
Safari \[4] maakt de tekst vetter dan de overige browsers.
IE [6, 7 en 8] lijkt problemen te hebben met anti-alliasing (zoals vaker); en natuurlijk het *.eot formaat....
Chrome \[3] doet het niet altijd en vervormd sommige letters.

Dit alles in zowel mijn eigen testjes als de demo's van Font Squirrel.

Dat te dik worden in Safari heb ik ook wel eens gehad en dat is iets met dat safari zelf nog een keer clear type text rendered en anti aliased terwijl windows dit ook doet (dacht ik).

[Peter]

Good Fella schreef op woensdag 14 oktober 2009 @ 16:45:
[...]

Werkt ook in Safari, Opera 10, IE4+ hoor

Font-face heeft nog heel veel bugs, te veel bugs naar mijn smaak. Sowieso heeft Internet Explorer nog geen degelijke ondersteuning, gezien deze enkel met EOT bestanden kan omgaan. De standaard beschrijft (op dit moment) dat ook TTF als OTF formaten ondersteund moeten worden; deze zijn dan ook veel gangbaarder.

Verder heeft de rendering erg veel last van de monitor instellingen van de gebruiker. Vooral clear-type en geen clear-type kan echt een wereld aan verschil betekenen. Tevens is het eindresultaat in de browsers (nu even vergelijkend tussen Gecko, Presto en WebKit browsers) nog erg verschillend. Logisch, maar verre van ideaal.

Het is zo'n typische functie met enorm veel potentie, maar nog teveel haken en ogen om op dit moment goed toegepast te worden. Ik gebruik het wel in een website, maar puur als uitgebreide testen aangetoond hebben dat de browser het goed aankan.

[Cartman!]

Kwam laatst nog de raarste bug ooit tegen, in IE7. Ben nu thuis maar uit mn hoofd zeg ik: een euroteken stijlen als Arial Bold en hij wordt weergegeven als sans-serif ipv. Arial Bold

testcase: http://future-vision.nl/ie7euro.html

[ Voor 11% gewijzigd door Cartman! op 14-10-2009 18:29 ]

[Verwijderd]

*huil*
Ik loop de hele ochtend te pielen met een rewrite rule voor een mod_rewrite die niet werkt, maar wel zou moeten werken. Uiteindelijk besluit ik gewoon dit eens te proberen.

code:

Options +FollowSymlinks
RewriteEngine on

rewriteRule ^(*.)\.htm$ $1.php [NC]

Werkt ook niet. Ik verbaasd. Ik zoeken. Blijkt dat iemand (ikzelf in elk geval niet) zo'n leuk # voor LoadModule rewrite_module modules/mod_rewrite.so in de httpd.conf heeft gezet.

Ga ik:
a)
b)
c)
of d) héééél even lang koffie drinken?

[.oisyn]

e) IIS installeren

[Matis]

Tja, ik had laatst een oneindig mod_rewrite loopje

ik deed zoiets als

code:

rewriteRule ^(*.)\.php$ index.php?id=$1

Daardoor bleef hij heel de tijd index.php evalueren en renamen en weer evalueren etc

[user109731]

Verwijderd schreef op donderdag 15 oktober 2009 @ 10:45:
*huil*
Ik loop de hele ochtend te pielen met een rewrite rule voor een mod_rewrite die niet werkt, maar wel zou moeten werken. Uiteindelijk besluit ik gewoon dit eens te proberen.

code:

Options +FollowSymlinks
RewriteEngine on

rewriteRule ^(*.)\.htm$ $1.php [NC]

Werkt ook niet. Ik verbaasd. Ik zoeken. Blijkt dat iemand (ikzelf in elk geval niet) zo'n leuk # voor LoadModule rewrite_module modules/mod_rewrite.so in de httpd.conf heeft gezet.

Stond er niets in de error log? Ik krijg hier:

code:

[Thu Oct 15 11:04:32 2009] [alert] [client ::1] /var/www/.htaccess: Invalid command 'RewriteEngine', perhaps misspelled or defined by a module not included in the server configuration

Dan weet je direct wat er mis is toch?

.oisyn schreef op donderdag 15 oktober 2009 @ 10:46:
e) IIS installeren

Gaat niet lukken op zijn OS

[AtleX]

Matis schreef op donderdag 15 oktober 2009 @ 10:50:
Daardoor bleef hij heel de tijd index.php evalueren en renamen en weer evalueren etc

code:

rewriteRule ^(*.)\.php$ index.php?id=$1 [NC,L]

[ Voor 60% gewijzigd door AtleX op 15-10-2009 11:08 ]

[Matis]

AtleX schreef op donderdag 15 oktober 2009 @ 11:08:

code:

rewriteRule ^(*.)\.php$ index.php?id=$1 [NC,L]

De oplossing is/was soms simpeler dan gedacht

[Verwijderd]

Haha, ja maar mijn eerste hunch was niet in de errorlogs kijken natuurlijk.

[Alain]

Ik was net bezig met een database in mysql en had niet in de gaten dat er nog een oude database met dezelfde naam aanwezig was, alleen zonder hoofdletter aan het begin. Dan krijg je zoiets:

SQL:

CREATE DATABASE `Test`;
USE `Test`;

CREATE TABLE `User` (
  `userId` INT UNSIGNED NOT NULL,
  CONSTRAINT `pk_user`
    PRIMARY KEY (`userId`)
) ENGINE=INNODB;

CREATE TABLE `Post` (
  `postId` INT UNSIGNED NOT NULL,
  `userId` INT UNSIGNED NOT NULL,
  CONSTRAINT `pk_post`
    PRIMARY KEY (`postId`),
  CONSTRAINT `fk_user_post`
    FOREIGN KEY (`userId`)
    REFERENCES `User` (`userId`)
) ENGINE=INNODB;

CREATE DATABASE `test`;
USE `test`;

CREATE TABLE `User` (
  `userId` INT UNSIGNED NOT NULL,
  CONSTRAINT `pk_user`
    PRIMARY KEY (`userId`)
) ENGINE=INNODB;

CREATE TABLE `Post` (
  `postId` INT UNSIGNED NOT NULL,
  `userId` INT UNSIGNED NOT NULL,
  CONSTRAINT `pk_post`
    PRIMARY KEY (`postId`),
  CONSTRAINT `fk_user_post`
    FOREIGN KEY (`userId`)
    REFERENCES `User` (`userId`)
    ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=INNODB;

Met de geweldige foutmelding:

code:

ERROR 1005 (HY000): Can't create table './test/Post.frm' (errno: 121)

Wat ongeveer betekent, er is * iets * fout met je FK. Die bestond dus al in een andere database met bijna dezelfde naam ...

[D-Raven]

* D-Raven pakt voor t eerst sinds tijden een bak koffie.
Moet met vb6 aan de slag. Laten we het er maar op houden dat het niet mijn favo taal is. Waar mn werkgever eerst een oude vb6 app om wou zetten naar .net gaan ze nu de vb6 app verder ontwikkelen. Ze vonden dat de ontwikkeling in de .net app niet snel genoeg ging.

Gek heh, als de vb app nog door 4 man wordt doorontwikkeld, en ik als enige op ontwikkeling van de .net app zit.
* D-Raven gaat denk ik eens goed nadenken of hij hier wel wilt blijven werken...

[Verwijderd]

D-Raven schreef op vrijdag 16 oktober 2009 @ 12:10:
* D-Raven pakt voor t eerst sinds tijden een bak koffie.

/me ook..

Gadver, nu weet ik waarom ik thuis geen koffie drink.. Ranzige neppe senseo pads...

Starbucks!!

[.Gertjan.]

D-Raven schreef op vrijdag 16 oktober 2009 @ 12:10:
* D-Raven pakt voor t eerst sinds tijden een bak koffie.
Moet met vb6 aan de slag. Laten we het er maar op houden dat het niet mijn favo taal is. Waar mn werkgever eerst een oude vb6 app om wou zetten naar .net gaan ze nu de vb6 app verder ontwikkelen. Ze vonden dat de ontwikkeling in de .net app niet snel genoeg ging.

Gek heh, als de vb app nog door 4 man wordt doorontwikkeld, en ik als enige op ontwikkeling van de .net app zit.
* D-Raven gaat denk ik eens goed nadenken of hij hier wel wilt blijven werken...

Leuk toch VB ! Zie het als een uitdaging... Overigens heeft VB.NET ook leuke "features" waar je behoorlijk wat tijd aan kwijt kunt raken...

Ik loop nu ook tegen een "dom" probleem aan in VB.NET en ik wil eigenlijk dat de compiler me gaat waarschuwen, maar hij heeft er niet veel zin in. Iemand een idee hoe ik de compiler op het volgende laat checken?

Visual Basic .NET:

'MyObject.MyVar is een property van type: MyEnum? (een nullable dus)
myObject.MyVar = If(check,Nothing,MyEnum.Value1)

Waneer check true is wil ik de property op Nothing hebben staan. ECHTER, dit gebeurt niet, omdat het rechterdeel een niet nullable is. De compiler maakt van de Nothing een 0 die hij cast naar MyEnum (wat neerkomt op de eerste waarde van de Enum). Als ik deze constructie in C# zou bouwen tikt de compiler me op mijn vingers met de mededeling dat links en rechts niet gelijk zijn (dat klopt), echter VB geeft me geen fout maar compiled dus naar (in mijn ogen) verkeerde code.

Ik weet dat links en rechts gelijk moeten zijn, maar ik maak soms ook een foutje, het is dan best nasty dat de compiler mij niet wijst op deze fout en gewoon zelf maar wat gaat rommelen. Dit zorgt nu dus voor problemen omdat er dus onverwachte values in mijn objecten komen (en vervolgens ook in de DB).

Iemand enig idee hoe ik hierop kan laten checken (het liefst met errors)? Ik heb wat zitten spelen met de compiler options en op google gezocht, maar wordt nog niet veel wijzer en een zoekopdracht op IF( is ook niet echt gewenst...

[D-Raven]

.Gertjan. schreef op vrijdag 16 oktober 2009 @ 13:06:
[...]


Leuk toch VB ! Zie het als een uitdaging... Overigens heeft VB.NET ook leuke "features" waar je behoorlijk wat tijd aan kwijt kunt raken...

Als het VB.Net was zou ik een gat in de lucht springen bij wijze van .

[.Gertjan.]

D-Raven schreef op vrijdag 16 oktober 2009 @ 13:34:
[...]


Als het VB.Net was zou ik een gat in de lucht springen bij wijze van .

Geloof me, VB.Net raak je ook vrij rap beu, maar het is inderdaad nog beter dan klassiek VB. Maar met problemen zoals boven verlang ik toch weer naar C#... Bij die taal heb ik toch meer het idee met een volwassen taal te werken...

[Megamind]

Vandaag heb ik MSDN gehad van school

Dus ik wil een pakket van Microsoft downloaden om eens wat mee te spelen, ik heb geen ervaring met elk van onderstaande:
Visual Basic 2005
Visual C++ 2005
Visual C# 2005
Visual J#.NET
Visual J# 2005
Visual Studio .NET 2003
Visual Studio 2008

Ik ben eigenlijk opzoek naar degene met de grootste community en ondersteuning, Delphi/Pascal begint een beetje dood te bloeden. Tijd voor iets nieuws.

Edit: ik zie nu dat in VS2008 gewoon al die talen daarin verwerkt zijn, ik neem aan dat in VS2008 het meest gewoon .NET gebruikt wordt?

[ Voor 13% gewijzigd door Megamind op 17-10-2009 09:24 ]

[Haan]

Tuurlijk, het is de meest recent versie en ondersteunt ook alles wat in VS2005 zit. Alleen VS2003 is afwijkend, maar daar wil je ook echt niet mee werken

[Simon Verhoeven]

Nog een student hier dus ik ken echt nog niet alle nuances van de talen, maar als ik tussen VB.net en C# mag kiezen geef mij dan toch maar c#.
VB.Net geeft mij wat teveel de indruk dat ik met een speelgoedtaaltje aan het werken ben.
Tevens vind ik het gebruik van semicolons en de algehele syntax van C# beter.

[CHeff]

Visual Studio 2003 is alleen interessant als je nog met .NET 1.0/1.1 moet werken.

[roy-t]

Verder wil je J# niet meer gebruiken, dat was echt een redelijk onzinnig project (vind ik). De support daarvoor stopt ook geloof ik.

[Megamind]

Voor diegene die in .NET programmeren, waar gaat jullie voorkeur naar uit?
C# of VB?

C# lijkt qua syntax behoorlijk op Java, wat ik wel een voordeel vind.

[roy-t]

Ik ben zelf ooit overgestapt van VB6 naar C# (gewoon om eens een heel andere taal te leren). Tegenwoordig programmeer ik ook veel in Java (school opdrachten e.d.). C# heeft vind ik de fijnste syntax, als je kunt wennen aan de shitload aan {{{}}} en overal een ;;;; achter zetten (wat voor een VB-er eerst erg vreemd is ).

Verder wordt C# op dit moment wat harder gepushed door MS waardoor het lijkt alsof er sneller leuke nieuwe features naar toe komen. Heel veel schelen de talen elkaar niet qua fuctionaliteit. VB heeft nogaltijd het "with" code blok, maar C# heeft dan weer andere leuke dingen zoals bij het creeren van een object meteen velden die niet in een constructor staan in stellen (als in: MyObject o = new MyObject(){name = "roy", ..}).

Zelf zou ik voor C# gaan, maar je kunt niet echt een verkeerde keuze maken. Het is allemaal .Net .

(En ach het is allemaal maar syntactic sugar voor assembly ).

[user109731]

VB(.Net) is IMHO veel te verbose. "If...Then", "End If", "End Sub", etc. Ja je hebt een IDE die dat aanvult (dat dat uberhaupt nodig/mogelijk is geeft al aan dat het eigenlijk onnodige informatie is), maar je moet er wel telkens overheen lezen

Zit je met oude software of kom je uit de VB-wereld, okee. Maar ik zou anno 2009 niet aanraden VB te leren

[ Voor 3% gewijzigd door user109731 op 17-10-2009 13:56 ]

[Matis]

Als je de keus hebt tussen al die talen raad ik je ook C# aan. De Intellisense van C# in VS2008 is geweldig.

Daarnaast is er natuurlijk heel veel te vinden over C# (MSND, maar ook http://csharp-source.net/ , http://www.codeguru.com/csharp/ en http://www.codeproject.com/?cat=3 )

Succes iig

[mithras]

Grrr, idiote iDEAL. Die basic versie is in principe prima te doen. Een simpel formuliertje bouwen en je bent al klaar. Helaas staat
a) in de handleiding de verkeerde url waarnaar je moet submitten en
b) slechts op één plek dat de hashcode anders is bij testen dan in productie.

En dat terwijl de hashcode uitleg zelf op vier plekken staat en je dus gemakkelijk die ene keer kan missen. Misschien meer een ING rant dan een iDEAL, maar toch verkloot je vele uren waar je best wat anders had kunnen doen

[pedorus]

Ach, al sinds het begin van iDEAL zijn er veels te veel draadjes over om te zeggen dat de manual goed is.. Voorbeeldje:

Verwijderd schreef op maandag 03 juli 2006 @ 11:06:
Het is gelukt.

Mijn fout was dat ik de hashkey uit de productieomgeving (https://ideal....) gebruikt had, maar ik had de haskey uit de testomgeving (https://idealtest....) moeten gebruiken.

N.B. de variabele ValidUntil moet WEL meegehashed worden!

[mithras]

Ik ga natuurlijk niet eerst op GoT zoeken naar problemen van iDEAL als ik zelf nog geen probleem heb

[CMG]

roy-t schreef op zaterdag 17 oktober 2009 @ 13:48:
...(En ach het is allemaal maar syntactic sugar voor assembly ).

Je bedoeld MSIL

[CMG]

m.b.t. de hele VB.NET/C# keuze maakt het eigenlijk weinig uit.

Een voordeel van C# is dat het makkelijk is met zoeken. Als ik iets over .NET wil weten gebruik ik altijd het C# keyword omdat ik dan gerichtere .NET results krijg (zijn meerdere smaken vb) en in het algemeen is er een voorkeur voor C# op het net, wat betekend dat er meer over te vinden is.

Bij ons op het werk is VB.NET de standaard en hoewel ik graag C# code doe ik tegenwoordig thuis ook meer VB.NET coden omdat ik dat nu eenmaal al de hele dag doe.

Als ik jou was zou ik proberen om de projectjes de eerste tijd om en om in C# en VB.NET te doen (zodat je je thuis voelt in beide), want als je eenmaal makkelijk beide talen leest en begrijpt kun je iig bij het zoeken online makkelijker je weg vinden. Het is ook leerzaam om af en toe wat code van de ene naar de andere taal te vertalen.

[BtM909]

Let je een klein beetje op dubbelposten. Als je als laatste reageert en wilt nog wat toevoegen, kan je ook de edit knop gebruiken