Starší komentáře ke článku: Uchovávejte správně hesla!
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 27.10.2004 9:59:08
nechci pichat do vosiho hnizda, ale z tohodle bych se fakt obtahnul, zlaty PHP
byte[] bInputData = ASCIIEncoding.ASCII.GetBytes(input);
MD5 objMD5 = new MD5CryptoServiceProvider();
byte[] bHashResult = objMD5.ComputeHash(bInputData);
return ASCIIEncoding.ASCII.GetString(bHashResult);
pro srovnani v php
$hash = md5($string);
Datum vložení: 27.10.2004 10:06:25
Presne tak :D
Datum vložení: 27.10.2004 12:11:14
Srovnáváte nesrovnatelné.
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.oracle.com/technology/pub/articles/hull_asp.html' target='_blank'>http://www.oracle.com/technology/pub/articles/hull_asp.html</a>
Datum vložení: 29.10.2004 8:31:30
Abychom tu srovnali porovnatelné:
- exceptions: <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.php.net/manual/en/language.oop5.exceptions.php' target='_blank'>http://www.php.net/manual/en/language.oop5.exceptions.php</a>
- OOP: citát A: "In fact, many of these weaknesses are addressed in PHP 5."
- OOP: citát B: "...new object that introduces features that bring true OOP to PHP."
(Oba citáty jsou z URI uvedeného v předchozím příspěvku.)
Mám dojem, že mnohem víc lidí tady "ví, o čem mluví". ;-)
Datum vložení: 27.10.2004 13:04:55
Tak to já se zase usmívám nad pokusy PHP o práci s databází :-)
Datum vložení: 27.10.2004 17:04:00
co mas proti DB v PHP ty ASP lama !?, v PHP sa s databazou pracuje dost jednoducho, asi v PHP vies hovno, ked nevies o com hovoris tak zavri papulu ty ***** debil
BTW - ASP je idiotina
Datum vložení: 28.10.2004 16:34:03
Ty zase nevíš nic o ASP. Ten kousek kódu nemá s ASP nic společného. Je napsán v C#, který je společně s Javou ve svém oboru nejpokročilejším jazykem. Nic ve zlém - PHP je určeno pro lamy, které jsou šťasné, když mohou nějakou funkci zavolat jedinou funkcí na jednom řádku. Nebyl by samozřejmě problém to tak zařídit v .NETu, ale není to tak z důvodů, které PHPčkaři nikdy nemohou pochopit, protože PHP ve v moderních postupech založených na OOP asi tak daleko, jako VBS.
Datum vložení: 28.10.2004 18:10:19
Opravdu to nejde bez těch nesmyslných invektiv? To Vám nestačilo těch padesát let hádek o to, který programovací (značkovací, skriptovací atd.) jazyk je nejlepší?
Datum vložení: 29.10.2004 7:33:58
Ja sa na programovaci jazyk pozeram z pohladu toho ako sa "skompiluje" vysledny program a aky rychly je vysledny kod. V PHP dokazem naprogramovat taky isty program ako dokazes ty v ASP alebo .NET, ale ten moj bude asi tak 20x rychlejsi, pretoze nepouzijem OOP. OOP je iba kvoli programatorom, aby si ulahcili prehladnost v programoch pri praci na velkych systemoch alebo programoch. Ale ak chces urobit naozaj dobry a rychly program, musis pozerat na to ako to prekladac interpretuje. A podla mna pouzivanie OOP zbytocne spomaluje rychlost vykonavaneho programu - po skompilovani je tam viac kodu.
Hovoris nieco, ze Java je najpokrocilejsim jazykom. Poznam par systemov naprogramovanych v Jave a je mi z toho zle. Mozno je to pokrocily jazyk ale neumerne pomaly - ma velke hardwarove naroky a zbytocne. Radsej pouzivam na programovanie PHP - je to nenarocny a rychly jazyk.
P.S: Bezpecnost programu nezalezi iba na jazyku ale na samotnom kode, ktory sa naprogramuje, alebo na tom ako je zabezpeceny server...
... je tam viacero faktorov
Datum vložení: 29.10.2004 10:24:30
Souhlasim, ze existuji pripady, kdy styl programovani (i prubeh vysledneho kodu) "odshora dolu" je fajn vec. Jenze to se hodi tak na prototypovani a aplikace typu "blog" - ( a uz tam bych pochyboval ). Rozhodne si myslim, ze OOP je pro vetsi systemy nesporna vyhoda, ze oddeleni presentation a business layeru a aplikace je super, ze komponenty, ktere generuji vysledne napr. HTML vubec nemaji tusit, nad jakym DB enginem jsou spousteny atd. Proc? Migrace na jine DB enginy, moznost volat public metody cele te aplikace i jinak nez pres HTTP... asi bychom toho nasli povicero.
Datum vložení: 29.10.2004 12:13:02
ja hlavne vubec nechapu, jak nekdo muze vyvysovat styl "odshora dolu" nad oop.... jiste ze v urcitych pripadech je to jako brat kanon na vrabce, ale rozhodne to v celkovem meritku nelze povazovat za lepsi zpusob!!
Datum vložení: 29.10.2004 15:17:35
Ja nehovorim, ze OOP nie je vyhoda, ale je to iba vyhoda programatorov. Vies ako Java alebo .NET compiler interpretuje OOP v strojovom kode ? Ak nie tak potom o com je programovanie ? Programovanie nie je o tom naucit sa par prikazov a kombinovat ich, ale ak chces urobit dobry soft, musis ist do hlbky a poznat tieto veci, iba potom urobis nieco co je naozaj rychle a potrebuje to na svoj beh minimalne poziadavky.
A ohladom tej migracie na ine db mozem to vyriesit predsa aj inym sposobom ako pomocou objektov. Napriklad mozem mat rozne *.inc subory (mysql.inc, pgsql.inc, oracle.inc) v ktorych budu funkcie s tymi istymi nazvami a podla toho ktoru databazu budem pouzivat, tak taky subor prilinkujem. Rozhodnem sa ze standardne query budu robene pre mysql a v oracle.inc bude funkcia napr. sql_query($query) robit napr to ze urobi este parsing query a prevedie ho z mysql formatu do oracle formatu. A je to omnoho rychlejsie ako keby som pouzil objekty.
Programovanie nie je o objektoch ale o vysledku prace.
P.S: Inak aj PHP vie OOP.
Datum vložení: 30.10.2004 13:11:35
Programátor si musí práci ulehčovat.
1) O rychlost jde čím dál méně. Bussiness aplikace stejně většinu času tráví čekáním na jiné zdroje, např. databáze, nebo nějaká data ze síťe.
2) Ceny HW pořád klesají, ale cena za hodinu práce programátora ne. Servery jsou navíc ve většině případů značně předimenzované.
3) Je třeba myslet do budoucna. Pokud nebudeme programovat objektově, bude rozšiřování projektu čím dál těžší, až se v něm nakonec ztratíme. Provádět změny bude čím dál obtížnější atd atd. Vyšší výkon tyhle nevýhody nevykompenzuje. Honba za výkonem je dnes přežitkem. Prioritou je spolehlivost a rozšiřitelnost.
Dále uvedený způsob práce s databází bych použil spíš jako odstrašující příklad, jak to nedělat. Jednak kvalitní (!) parsing dotazů nebude hračka. Dále byste musel s každou verzí mySQL tento "konvertor" inovovat, protože nemáte žádné omezení, co lze nad mySQL volat a těžko zabráníte, aby někdo nezkusil využít právě tu novou vlastnost. Dále váš konvertor může obsahovat kritickou chybu, která může způsobit i nějaké chyby v datech. A také můžete v některých funkcionalitách narazit na takovou rozdílnost databázových strojů, že řešení prostou konverzí SQL dotazů je nesmírně obtížné, ne-li nemožné.
Mám pocit, že se objektům vyhýbáte jako čert kříži. Co neznám, to pomluvím ;-) Neberte to prosím osobně. Do PHP sice byly zabudovány nějaké rysy OOP, ale zdaleka ne tolik, aby se v tomto ohledu vyrovnalo moderním jazykům.
Datum vložení: 30.10.2004 14:17:14
PHP samozřejmě není a asi ani nikdy nebude čistě objektový jazyk. Já osobně to ale vítám, protože díky tomu mohu používat adekvátní styl podle okamžitých potřeb, podobně jako v C, kde lze také kombinovat oba způsoby ;-)
Datum vložení: 2.11.2004 11:29:58
heh, nahodou OOP rozumiem, celkom dobre. Pracoval som OOP v napr. V Pascale alebo v C, takze vlastnosti a vyhody objektov su mne nie neznamym pojmom. Ale v tom ze sa im vyhybam mate pravdu. V PHP objekty nepouzivam ale iba viem, ze nejaka podpora toho tam je.
A ohladom tej rychlosti viem svoje. Mam skusenosti s aplikaciami napr v JAVE alebo v DELPHI a su o dost pomalsie ako napr nieco v PHP. Samozrejme mate pravdu ze o vela veci sa dnes stara databaza, ale aj poziadavka na databazu musi byt formulovana dobre, aby ju databaza rychlo spracovala.
Datum vložení: 26.8.2005 13:53:21
sakra takhle jsem se dlouho nezasmal Hlaska typu heh, nahodou OOP rozumiem, celkom dobre. Pracoval som OOP v napr. V Pascale alebo v C, takze vlastnosti a vyhody objektov su mne nie neznamym pojmom. --------------------------------- No on treba jazyk C neni objektovy :-)))))) :-))) takze VEDLE ale aspon sem se zasejc zasmal
Datum vložení: 29.10.2004 13:47:40
je to otazka velkosti aplikacie... PHP je sice nenarocny a rychly jazyk, ale iba na mensie web aplikacie. Tazko sa mi predstavuje, ze by som PHP pouzil na tvorbu vacsej aplikacie (napr. pre banky, poistovne, ...), na ktorej by pracoval vasci pocet analytikov, dizajnerov, programatorov a nepouzil pri tom OOP...
Datum vložení: 29.10.2004 14:40:35
presne tak... vytvaret kod "odshora dolu" ve vetsim poctu vyvojaru je krajne neefektivni! vyhoda oop je tady nesporna... krom toho, v .netu si muze kazdy vyvojar svuj kod napsat v libovolnem jazyce, ktery mu vyhovuje a nemusi se bat, ze by se jeho kod nedomluvil s kodem kolegy...
Datum vložení: 29.10.2004 15:10:45
Myslim, ze nejde ani tak o velkost aplikacie ako o styl programovania, da sa naprogramovat v PHP aj vacsi system (banky a poistovne urcite nie, ale napr. system pre obchodne domy, alebo univerzity - prave ten robime v PHP a je to v pohode) ale treba vediet dobre urobit strukturu. My sme pracovali na systeme traja a aj keby na nom pracovalo 50 ludi - bola tam tak dobre urobena struktura, ze by to nevadilo.
Datum vložení: 4.2.2008 16:24:25
Obecne bych slovenskym barbarum doporucil prizpusobit se kontinentalnimu chovani. Kdo se ma na ty opicarny koukat?
Datum vložení: 27.10.2004 13:13:23
1) Slovníkový útok jde řešit jednoduše, totiž principem: "human check". Obrázek, náhodný kód, náhodná pozice, náhodný sklon, náhodná velikost písma... A cracker si s "brutal force" ani neškrtne.
2) A další problém bych viděl v posílání hesla, což zmíněno nebylo. I kdyby bylo nakrásně použito SSL (což by měla být samozřejmost, pokud je to s bezpečností myšleno vážně), stále je heslo možné identifikovat adminem na serveru. I to je problém, resp. ani admin by neměl znát hesla, která kdokoliv používá. Řešením je hashování už v klientovi pomocí JavaScriptu...
Datum vložení: 27.10.2004 21:22:32
hashování na klientovi je k ničemu. Pokud někdo odchytne klientem zahešované heslo, může poslat na server stejný požadavek se stejně zahešovaným heslem a tak se bez problémů přihlásí, aniž by znal nehešovou podobu hesla.
Datum vložení: 27.10.2004 21:42:52
Hešování hesla a dalších dat před odesláním z klienta na server samozřejmě význam má, jinak by se v aplikacích nepoužívalo. Když už pro nic jiného, pak alespoň proto, že si vaše heslo nemůže nikdo přečíst a nemůže se ho pokusit použít na jiných serverech nebo podle něja "hádat", jaký typ hesel používáte ;-)
Datum vložení: 28.10.2004 9:57:23
"že si vaše heslo nemůže nikdo přečíst a nemůže se ho pokusit použít na jiných serverech nebo podle něj nějak "hádat", jaký typ hesel používáte"
Ano, tak jsem to přesně myslel, nenapsal bych to líp :-)
Datum vložení: 28.10.2004 16:43:29
A co přidat ještě nějaké to asymetrické šifrování? Hash by se zašifroval veřejným klíčem serveru, který by byl unikátní pro daný požadavek (či relaci), a i kdyby data někdo odchytil, tak jsou mu k ničemu.
Datum vložení: 29.10.2004 1:36:05
pouzijeme challenge/response a i kdyz bude odchycen hash, tak je to jedno, neb bude pokazdy jinej (i kdyz heslo bude pokazdy stejny)
Datum vložení: 27.10.2004 23:07:58
ad 1] mozna jsem to nepochopil, ale jak timto principem zabranite slovnikovemu utoku? Pokud se utocnikovi dostanou hesla v hashovane podobe "do rukou" je to uz jen na jeho trpelivosti a umu.
ad 2] jak z SSL poznate heslo? Pokud vim tak o to se stara samotny protokol (v nekolika fazich)- aby bylo vse sifrovane. To ze budete heslo sifrovat JavaScriptem znamena ze prozradite funkci, kterou na hashovani pouzivate.
Jako "lepsi" moznost bych videl nejaky applet, ktery by se staral o sifrovani komunikaci. Zase se ale dostanu do problemu - na klienta musi dorazit bytecode, ktery se da pochopit a prozradit algoritmus.
Potom uz nezbyva nic jineho nez nejaky klic, kterym se bude uzivatel hlasit a tim se bude vse sifrovat.
Ale to jsem asi daleko od ukladani hesel do db jako hash code... :-)
Datum vložení: 28.10.2004 9:55:15
ad 1) Samozřejmě, že to zabrání slovníkovému útoku jen v případě, že dotyčný nemá k dispozici ani hash, protože hash hesla je pořád stejný (narozdíl třeba od Digest autentizace, která také používá pokaždé jinou pomocnou náhodnou hodnotu třeba i spolu s IP adresou nebo jinou hodnotou). Stejné je to i u sessions. Pokud není použito SSL, je možno se napojit minimálně na aktuální relaci (pokud není alespoň přídavné zabezpečení v podobě kontroly IP adresy, ale i ta se může měnit v rámci jednoho spojení a nebo může být podvržena). Proto je potřeba šifrovat i přenos, to je prostě základ.
Slovníkovému útoku samozřejmě zabrání i omezení počtu zadání chybných hesel, kdy pak přijde automatická blokace takového účtu, jenomže to pak omezí případného skutečného uživatele, pokud to takto zkouší někdo jiný.
Ale toto se používá hlavně třeba u různých registrací, aby se někdo automaticky neregistroval třeba 1000x. Pokaždé musí vizuálně zjistit z obrázku kód (z již uvedených důvodů programem nezjistitelný) a ten zadat.
ad2) Admin samozřejmě může skriptem na serveru zjistit heslo i když přenos běží (tedy spíš běžel) přes SSL.
A to že prozradím MD5, to jaksi nic moc neznamená, to se používá skoro vždy :-) V poslední době sice už není MD5 tak neprůstřelná, jak se myslelo, ale zatím to není nic tak tragického. Jde sice za určitých specifických okolností nalézt více řetězců, které mají stejný hash, ale to nelze přirovnávat k tomu, že z jakéhokoliv hashe lze zjistit řetězec (možný samozřejmě není z principu hashe jenom jeden řetězec), který k tomuto hashi náleží.
Datum vložení: 28.10.2004 10:23:08
Sessions, například v PHP, se proti stealingu dají poměrně snadno zabezpečit. Lze použít časovou kontrolu přístupu, kontrolu složeného hashe (z hlavičky obsahující IP komunikujících strojů i proxyn, identifikační řetězec prohlížeče a typ OS), generování jednorázové cookie a řadu dalších metod. Jejich nasazení je v jakékoli seriózní aplikaci povinností ;-)
Datum vložení: 9.11.2004 3:30:56
AD 1) [human check obrázkem]
tohle řešení je 100% z pohledu bezpečnostního, ale silně obtěžuje uživatele. Když jsem jeden čas pomáhal s administrací webu, musel jsem heslo zadávat kamsi kazdych 5 minut po dobu 6 hodin v kuse a byl jsem moc vdecny, ze si prohlizec pamatoval aspon login. Nerikam, ze se do takovehle situace dostane vic jak 1 z tisice, ale kriticke chvile muzou nastat i jinak. Byl jsem jeden cas majitelem Pocket PC s pripojenim na net pres GPRS => vypnute obrazky a neexistovala moznost vynutit si zobrazeni nektereho presne vybraneho obrazku. Jde mi o to, ze uzivatel zahnany do takovychto extremnich koutů sahne po nouzovem reseni a vypne vsechny bezpecnosti vyfiku*dace, jen aby mohl dosahnout, ceho potrebuje - cimz dosahujeme presne nezadouciho efektu.
Resenim by mohlo byt napr.: 1-2 sekundova prodleva po prihlaseni. Pokud se ocekava, ze se bude prihlasovat clovek, tuto prodlevu nepociti, ani kdyby se prohlasoval kazdou minutu. Dalsi (nebo doplnujici) variantou obrany proti brutal force je omezeny pocet pokusu za minutu - to vsak vyzaduje vetsi rezii na strane serveru.
AD 2) [Hash hesla JavaScriptem]
Zásadně nesouhlasím! JavaScript se nesmí stavit do žádné klíčové role v práci uživatele, leda, že by konstrukce JavaScriptoveho kódu byla taková, aby umoznovala prihlaseni (byt mene bezpecne) i v případě selhaní scriptu, nebo jeho potlačení klientem. Navíc klient může být v takovém stavu, že heslo sice úspěšně projde hashem, ale z nějakého důvodu dojde k nesprávnemu hashování.
(omlovám se za výpadky diakritiky - zlozvyk)
Datum vložení: 27.10.2004 19:22:26
Nebylo by pro jednoduche zahashovani hesla dostacujici pouzit metodu HashPasswordForStoringInConfigFile :-) ?
Sice se jmenuje docela silene, ale prece jenom to bude kratsi. Sam jsem toto moc neresil, takze nevim jestli je to vhodne reseni, ale na prvni pohled se zda ze by mohlo....
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWebSecurityFormsAuthenticationClassHashPasswordForStoringInConfigFileTopic.asp' target='_blank'>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWebSecurityFormsAuthenticationClassHashPasswordForStoringInConfigFileTopic.asp</a>
Tomas Petricek
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://blog.vyvojar.cz/tomas' target='_blank'>http://blog.vyvojar.cz/tomas</a>
Datum vložení: 28.10.2004 9:35:02
Presne tak. Práve na to je táto metóda určená.
Uz som to chcel do fora napisat, ked som si vsimol tento prispevok ;-)
Este, pre poriadok, uvediem celu "cestu":
System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile( string password, string passwordFormat );
a pouzitie je rovnako jednoduche ako v PHP (ako sa tu uz niekto stazoval):
string hashedPassword = FormsAuthentication.HashPasswordForStoringInConfigFile("heslo", "SHA1");
Datum vložení: 28.10.2004 9:53:14
V php je to na min pismenek :)
Datum vložení: 28.10.2004 16:39:22
Opravdu? Tak to asi přejdu na PHP ;o)
Datum vložení: 28.10.2004 18:17:01
nesmejte sa pls mojej otazke, ale kazdy nejak zacinal ...
ked sa ulozi zaHASHovane heslo do databazy, ako docielit (v PHP + MySQL) to, ze v pripade straty hesla bude heslo poslane userovi na mejl zadany pri registracii ? ( Zatial som to pochopil tak, ze so stringu v databaze ( zahashovane heslo + IP +cokolvek ) sa da tazko ziskat povedne heslo, ip ...
popripade existuje bezpecnejsi sposob ako sa dostat k zabudnutemu heslu ? ( okrem sms )
dik moc za radu, kludne aj na email. JuroH
Datum vložení: 28.10.2004 18:36:54
este jedna vec :
pokial je dostatocne zabezpeceny server kde je databaza, je nutne ukladat hesla v zahashovanej forme ? ( v pripade, ze sa utocnik dostane na databazovy server, uz heslo usera nepotrebuje ) ..... kriticky je aj tak ten moment, kedy sa user registruje, a posiela prvy krat form s heslom ... vacsina clankov o autentifikacii ( ci uz session, alebo http header ) je pisana tak, ze pokial potencialny utocnik odchyti form s registracnymi udajmi, tak zahashovane heslo v databaze mu prekazat nebude.
Je na to riesenie ?
(mozno trepem blbosti, a ma tu kopec "coderov" ukamenuje, ale snazim sa to pochopit. )
Dik, juroh
Datum vložení: 28.10.2004 18:56:33
Ukladat hesla v zabezbecene forme je vzdy vyhodnejsi. Uz treba proto, ze uzivatele jsou schopni pouzivat sterna/podobna hesla na ruznych systemech.
Zapomenute heslo se pak resi vygenerovanim noveho hesla, ktere je zaslano uzivateli.
Datum vložení: 29.10.2004 15:13:22
no to ma tiez napadlo, ze v pripade straty hesla sa vygeneruje na majl usera nove. Pytal som sa preto, ze kopec "portalov" tu moznost ma, ze ked zabudnete heslo, a zadate email, posle vam na dany email heslo suvisiace s emailom. Potom tieto portaly maju ulozene hesla v databaze ako string, ktory zadal user pri registracii ? teda nekryptovane?
Diik za reakciu, JuroH
Datum vložení: 29.10.2004 8:18:25
Nutné :-) to samozřejmě není, ale koledujete si tím o několik problémů. Ten, kdo získá přístup k DB, zná pak hesla uživatelů. To může být třeba admin serveru, nebo Vy, coby autor daného SW. Pokud se dostane k DB, heslo se mu může přesto hodit např. k přístupu na jiný server, mail, získání PINů, atd.
Ve skutečnosti je přenos hesla kritický vždy, ani SSL v tomto směru není zcela neprůstřelné, pokud vím (mám dojem, že např. ISA 2004 by mi mohl docela dobře posloužit k man-in-the-middle attack). Nicméně poskytuje přijatelnou bezpečnost za rozumnou cenu.
Datum vložení: 29.10.2004 15:18:18
hey, to o heslach ma mohlo napadnut :-). O SSL pri prenose hesla zacnem vazne uvazovat. Dik moc, JuroH
Datum vložení: 29.10.2004 1:41:26
chtel bych jen poznamenat, ze misto md5 by asi bylo lepsi pouzit napr crypt() (existenci na win32 nemuzu potvrdit/vyvratit;) prece jen je to trochu odolnejsi na bruteforce utoky, kdy mam k dispozici onen hash a snazim se ho rozlomit. videl jsem tool generujici 4m md5 hashu/sec (na p4/2.4ghz), takze hesla do nejake rozumne delky neni problem dostat v relativne kratkem case
Datum vložení: 29.10.2004 12:35:27
A nebo SHA1
Datum vložení: 31.10.2004 17:30:12
Z principu nelze žádnou webovou aplikaci ultimativně zabezpečit, jen maximálně zabezpečit, a o tom to je. Takže je asi nejlepší při projektu uvažovat ve stylu cena/výkon, tzn. cena dat/pracnost prolomení pro konkrétní projekt. Takže devadesát procent webů může používat i jednodušší metodiky, protože je pro hackery vzhledem k nutnosti vynaložené práce nezajímavý. Toliko jen poznámka ke snažení o bezpečnost - všeho s mírou.)
Add PHP/ASP - se mi zdá, že PHP milovníci o .NET moc nevědí, protože vůbec nejde o ASP, se kterým to pořád srovnávají - PHP je skutečně neporovnatelně lepší než klasické ASP. O tom není pochyb. Ale ASP.NET je něco jiného - principiálně (jen formálně) má logikou blíže k Javě (a servletům). A Java servlets nikoho nenapadne srovnávat s PHP....Možná měl MS zvolit jiné pojmenování této technologie, ať flamesoldiers mohpou klidně spát.
Ale - a to je pro ně - až se někdo z .NET guru jednou trochu uvolní, třeba napíše podporu syntaxe skriptů/jazyka PHP pod .NET - jako další kompiler do MSIL.))) Z recese mohu uvést, že nejen C#, C++,VB.NET nebo JS...ale už to jde pod Pythonem (a to jako i visual), Delphi, Perl(a to jako i visual)...jsem zvědav, co bude příště.:)).
Datum vložení: 31.10.2004 18:45:32
to mi mluvi primo z duse... :) jsem rad, ze to tu nekdo takhle napsal..... podobnych prispevku jsem uz v internetovych diskuzi ale napsal kvantum, lec nekdo neni porad schopny pochopit v cem je ten rozdil.... mozna by stalo za to napsat nejaky clanek, ktery by toto tema (myslim tim php vs .net) pokryl...
toto opravdu nejde srovnavat a tato valka nema zadny smysl!!
Datum vložení: 31.10.2004 23:30:14
Článků, které srovnávají PHP a .NET, respektive vysvětlují jednotlivé technologie, je na internetu dost - několik se jich najde i zde na Intervalu. že to flameři stále nechtějí pochopit, to už je jiná - přitom stejně nesmyslně přistupují k problému jak zastánci PHP, tak "odborníci" na .NET ;-)
Datum vložení: 1.11.2004 7:13:18
problem je v tom, ze vetsinou kritizuji ti, co znaj jen to svoje a o druhe technologii nevedi vubec (nebo hodne malo) nic (vedi-li vubec dostatek o te sve)...
to pak vznikaji znacne nesmyslne argumenty spise pro zasmani! ;-)
Datum vložení: 18.12.2008 17:10:32
[i]přitom stejně nesmyslně přistupují k problému jak zastánci PHP, tak "odborníci" na .NET ;-)[/i] Ty si myslíš, že ak niekto sa špecializuje na PHP není odborník? Lebo to tak vyznelo z tej vety. Prosím o vyjadrenie