PHP avagy PERL???

nucler
PHP avagy PERL???
2003-07-15T09:24:18+02:00
2003-08-22T19:18:51+02:00
2022-06-29T05:07:30+02:00
  • Vagyis? Elfogadható egy kis csalás?

    Nem ezt mondtam. Csak a "Mondjuk úgy: kelet-európai piac" mondatodra írtam. A csalás nem kelet-európai sajátosság.

    Az animációs példára: persze van ilyen is. Te hogy kezdted? Megvetted a szükséges szoftvereket?

    Persze, a Perl vagy PHP fejlesztéséhez nem kell megvenned semmit. De azért jól jön az a kis Macromedia Studio (310+áfa), és néha elkel egy kis Photoshop is (198+áfa). A jogtiszta Windows fölé...

    Így van. Jogtiszta a Windowsom (OEM, vassal adták). 50 ezerért vettem macromedia studio 4-et, majd upgradeltem 5-ösre valmi 80-100 körüli áron. Photoshop nem kell, ott a fireworks.
    De eddigi php/perl programozásaimhoz egyik sem kellet (design nem az én asztalom)

    Ezen a szürke piacon ilyen is van...

    És erősen várom, hogy linuxra is megjelenjenek ezek a progik, így a windows árát meg tudom spórolni.

    Persze értem én, mit mondasz. Én sem tudok olyan olcsó lenni mint a feketén dolgozók. Nem is ezzel volt bajom, csak szvsz túl sarkosan és sommásan mondtad az ítéletedet a kelet-európai piacról. Nem hiszem, hogy ilyen csak kelet-európában fordul elő... lásd Andersen Consulting...

    Zila
    Mutasd a teljes hozzászólást!
  • Nem csak a kicsik csalnak.


    Vagyis? Elfogadható egy kis csalás?

    A piac meg épp attól piac, hogy nem mindenki annyiért dolgozik mint a másik.


    A hazai közállapotokat nem szívesen nevezem piacnak. Legfeljebb szürke piacnak. Mondok is rögtön egy példát. Többmilliós 3D animáció. A hazai ár eleve az európai ár kb. 1/5-e. A munkát (minden "valódi" versenytársat lekőrözve) elvállalja néhány középiskolás. Az előlegből, amit kapnak, megveszik a szükséges "vasat". Ráadásul azt is egy nagyker ár alatt árusító "szürke" boltban, de ez most mindegy. A munkát úgy-ahogy megcsinálják, a megbízó sem ért hozzá túlságosan. (Mondom: Magyarország.) Nem fizetnek adót. Sem TB-t. Nincs munkahelyük, bérleti díjuk, a villanyszámlás nem hozza a légkondi díját. Nem veszik meg a szükséges szoftvereket (kapásból leesne úgy 8 millió).

    Másszóval a "piaci engedmény" költségeit adócsalásból és szoftverlopásból finanszírozzák.

    Persze, a Perl vagy PHP fejlesztéséhez nem kell megvenned semmit. De azért jól jön az a kis Macromedia Studio (310+áfa), és néha elkel egy kis Photoshop is (198+áfa). A jogtiszta Windows fölé...
    Mutasd a teljes hozzászólást!
  • Ja! És Perl vagy Php fejlesztéshez nem kell megvenned semmit. A fejlesztésekhez használt programjaim jogtiszták GNU GPL licensszel.
    Mutasd a teljes hozzászólást!
  • Mondjuk inkább úgy: kelet-európai piacnak. Utánanéznék azért az otthoni fusizgatók programliszenceinek és adóbevallásuknak.

    Ugyan már. WorldCom. Exon. Stb. Nem csak a kicsik csalnak.
    A piac meg épp attól piac, hogy nem mindenki annyiért dolgozik mint a másik. Egy kezdő vállalkozásnak igenis megéri - rövid távon - a piaci ár alatt dolgozni, hiszen kell a referencia, kell az ügyfélkör.
    Nem tudom miért csodálkoztok ezen?

    Zila
    Mutasd a teljes hozzászólást!
  • Melyik a biztonságosabb? Az a programozótol függ. Ha van PHP tudásod, de szerinted a Perl biztonságosabb, hülyeség megtanulni. Mindegyik alapból ugyanolyan biztonságos, de ha átírod lehet bizonságosabb és rosszabb is. De én mégis a PHP-t ajánlanám, mert igaz, hogy újabb mint a Perl, és általában a régebbi nyelvek egy kicsit biztonságosabbak, de a PHP-val könyebben tudod kezelni a kódot.
    Mutasd a teljes hozzászólást!
  • Nem, ezek nem nagy kapacítású fejlesztők voltak. Csak egyszerű script kiddie-k.

    Attól, hogy valakinek van "szabad kapacitása" még nem fog dolgozni a piaci ár 1/10-ért... Legalábbis normális ember nem.
    Mutasd a teljes hozzászólást!
  • "Hát, tudod ezt hívják piacnak."


    Mondjuk inkább úgy: kelet-európai piacnak. Utánanéznék azért az otthoni fusizgatók programliszenceinek és adóbevallásuknak.
    Mutasd a teljes hozzászólást!
  • Gondolom nem csak én tapasztaltam már olyat, hogy egy megrendelő kér egy árajánlatot egy programra, amire 2 hónapot saccolok, és mondok mondjuk 1-1,5 milliót. Erre jön valaki, és megcsinálja a munkát 50-100 ezer forintért! Ilyen már kétszer is előfordult velem...


    Hát, tudod ezt hívják piacnak. És nem biztos, hogy az olcsóbb rosszabb :) Lehet, hogy akkora kapacitással rendelkezik az ellenfeled, hogy ennyiért is megéri neki. Vagy így akar betörni a piacra... Lehet, hogy újra kellene gondolnod az árképzésedet...

    üdv,
    Zila
    Mutasd a teljes hozzászólást!
  • A Delphi-t én is csak azért hasonlítottam a PHP-hez, mert látszólag könnyű tanulni.

    Ha leültetek egy hozzá nem értőt egy Delphi elé, kezébe nyomok egy könyvet, akkor 3 nap múlva már adatbázist programoz :)
    Mutasd a teljes hozzászólást!
  • Kicsit továbbszaladt a thread, csak a pontosság kedvéért, Zend Encoderrel fordított állományok futtatásához semmilyen root által végzett beállítás nem szükséges, ugyanúgy parseolja és futtatja a PHP Zend Engine-je mint egy plaintext php állományt, talán kicsit gyorsabban. Nem véletlen ugyanaz a cég csinálja mindkettőt.
    Mutasd a teljes hozzászólást!
  • A Delphi-t azért nem hasonlítanám a PHP-hez. Egyrészt azért az Object Pascal még mindig szigorúbb nyelv - és így jobb nevelő -, mint a PHP. Másrészt a Delphi-ben van lehetőség (és van hova) fejlődni (mert a RAD IDE és a VCL csak egy "előtét" az egyébként igen rugalmas és kiterjedt szerkezeteket biztosító fordítóra). A PHP-ben nincs igazán.

    A Delphi a megfelelő kezekben kiváló eszköz tud lenni, amivel szinte minden feladatra áttekinthető, szép, és - minden kódolási, mind futási sebesség tekintetében - gyors megoldás adható. Ugyanakkor a PHP-ben történő fejlesztés korlátja maga a nyelv, aminél fapadosabbat és inkonzekvensebbet keveset ismerek, és ami gyakorlatilag lehetetlenné teszi átlátható, gyors, és jól karbantartható kód létrehozását.

    Bár tény, hogy bizonyos bonyolultsági szint alatt webes megoldásokra (de csak arra, és csakis egy adott komplexitási szint alatt) egyértelműen jobb megoldás gyakorlatilag minden más eszköznél.
    Mutasd a teljes hozzászólást!
  • Tényleg nem a PHP hibája az, hogy könnyen tanulható. Ez az előnye. De nem csak a PHP ilyen nyelv manapság, a Delphi-t is ide sorolom.


    És nem is az a baj, hogy jók/hatékonyak az eszközök, mert én is ezért szeretem a Delphi-t.


    Tényleg az a bajom, hogy rengeteg hozzá nem értő van a pályán/piacon, és ez a tendencia a könnyen tanulható eszközök terjedésével egyre csak növekszik.

    Ez pedig nem hiszem, hogy jót tesz a szakmának...


    Gondolom nem csak én tapasztaltam már olyat, hogy egy megrendelő kér egy árajánlatot egy programra, amire 2 hónapot saccolok, és mondok mondjuk 1-1,5 milliót. Erre jön valaki, és megcsinálja a munkát 50-100 ezer forintért! Ilyen már kétszer is előfordult velem...


    "Azt már inkább, hogy nem rendelkezik megfelelő támogatással a biztonságos szkriptek készítéséhez"

    Igen, erre gondoltam.


    "Már pedig ez a megoldás. A nyelv bizonyos eszközökkel csökkentheti annak esélyét, hogy a programozók hibás kódot írjanak, de ezért általában elég komolyan meg kell fizetni teljesítményben és rugalmasságban, valamint semmilyen nyelvi szabály nem véd a nyelvi szintje felett (pl. az alkalmazási logika szintjén) jelentkező hibáktól."

    Ebben igazad van. Ez lenne az ideális megoldás. De sajnos ez eddig nem jött be, tehát talán más megoldást kellene keresni.


    "A PHP-vel sem az az elsődleges baj, hogy nem annyira szigorú nyelv, mint mások, illetve, hogy támogatja nem biztonságos szerkezetek használatát is (általában kompatibilitási okokból), hanem az, hogy elhiteti azokkal akik dolgoznak benne, hogy valóban tudnak programozni - miközben dehogy."

    Igen, ezt akartam mondani. A Delphi is ilyen. De mielőtt bárki is megsértődne: mindkettőt aktívan használom :) )a PHP-t kevésbé, a Delphi-t minden nap)

    Erre mondtam, hogy nem mindenben jó a RAD vagy a könnyű tanulhatóság. Sajnos ez sokszor visszaüt, és ezt általában a komolyabban hozzáértők szívják meg.


    Elég csak mostanság divatos "főnöki mentalitásra" gondolni: "nem veszek fel profit fél milláért, hisz ezért kapok 5 kezdőt is, és az ugyebár többet ér..."
    Mutasd a teljes hozzászólást!
  • Ami engem inkább zavar, hogy ezek az eszközök még kevésbé kényszerítik a programozót a biztonságos út használatára.

    Kényszeríteni nem hiszem, hogy kényszerítené - egyszerűen itt is csak arról van szó, hogy ha olyan ember dolgozik az eszközzel aki nem ismeri azt, illetve akinek biztonság témában sincsen semmilyen háttere, az nyilvánvalóan nagyobb eséllyel ejt biztonsági lyukat a programon, mint komolyabb tapasztalattal rendelkező társa.

    Azt mondjuk nem hibának nevezném a PHP esetében, hogy viszonylag könnyen tanulható, és így lehetővé teszi olyanok számára is a programok készítésék, akik valójában semmilyen szempontból sem lennének alkalmasak arra. (A MySQL is tipikusan ilyen eszköz egyébként.)

    Azt már inkább, hogy nem rendelkezik megfelelő támogatással a biztonságos szkriptek készítéséhez. Mert pl. Delphi-ben is lehet a paramétereket közvetlenül az SQL kifejezésbe befűzve abszolút insecure programot készíteni, viszont ott legalább alapból megvan a lehetőség és a támogatás a maximálisan biztonságos paraméter-átadásra (a topikban korábban említett ParamByName és társai személyében).

    Mert ugye azt senki sem gondolja, hogy majd minden programozó megtanul JÓL és BIZTONSÁGOSAN programozni, és akkor nem lesznek ilyen hibák.

    Már pedig ez a megoldás. A nyelv bizonyos eszközökkel csökkentheti annak esélyét, hogy a programozók hibás kódot írjanak, de ezért általában elég komolyan meg kell fizetni teljesítményben és rugalmasságban, valamint semmilyen nyelvi szabály nem véd a nyelvi szintje felett (pl. az alkalmazási logika szintjén) jelentkező hibáktól.

    A PHP-vel sem az az elsődleges baj, hogy nem annyira szigorú nyelv, mint mások, illetve, hogy támogatja nem biztonságos szerkezetek használatát is (általában kompatibilitási okokból), hanem az, hogy elhiteti azokkal akik dolgoznak benne, hogy valóban tudnak programozni - miközben dehogy. (A PHP "programozók" legtöbbjének ez az első nyelve, és abszolút nem rendelkezik semmilyen háttérismerettel sem, ami mellett nem csoda, ha óriási szarvashibákat ejt.) Persze igazából ez sem a PHP hibája (hiszen az csak egy eszköz), hanem azé a piacé amely elfogad és eltart ilyen "programozókat".

    Ilyenkor gondolok arra, hogy nem volt mindenben szerencsés ötlet a RAD eszköz.

    Ez leginkább úgy hangzik, mint ha a biztonság iránti aggódás helyett inkább a felett keseregnél, hogy neked mennyit mellett szenvedned, hogy ugyanazt produkálhasd, mint a mai modern eszközökkel szinte bárki. (Megjegyzem, azért a két tudás még véletlenül sem összehasonlítható egymással, bár az tény, hogy a laikus külső szemlélő számára ez kevésébé nyilvánvaló.)
    Mutasd a teljes hozzászólást!
  • Teljesen igazatok van abban, hogy ez a programozó hibája, nem pedig a programnyelv a ludas benne. Ez OK.


    Ami engem inkább zavar, hogy ezek az eszközök még kevésbé kényszerítik a programozót a biztonságos út használatára.

    Tehát lehet, hogy kevesebb lenne az ilyen biztonsági rés, ha nem lenne erre lehetőség. Talán...

    Ez picikét hasonlít a C-s buffer overrun hibákra. pl. Pascalban ilyen hibákat a stringkezelése miatt nehezebb csinálni.


    Szóval nem konkrétan a PHP-vel van a bajom. Inkább a ma elterjedt nyelvekkel.


    Mert ugye azt senki sem gondolja, hogy majd minden programozó megtanul JÓL és BIZTONSÁGOSAN programozni, és akkor nem lesznek ilyen hibák.


    Ez a tendencia pedig talán a könnyen használható nyelvek elterjedésével kezdődött.

    Itt arra gondolok, hogy amikor az első megrendelésre készített programomat csináltam Turbo Vision-ban (anno BP7-ben), akkor még sokkal több tudás kellet egy alapszintű program elkészítéséhez.

    Emlékszem, az egy egyszerű számlázóprogram volt. Csak a számlákat és az ügyfeleket tartotta nyilván, árutörzset, raktárkészletet nem ismert...

    De ezzel a programmal kb. 2-3 hónapot dolgoztam annak idején. + még előtte 2-3 évet Turbo Pascal-ban, hogy eljutottam erre a szintre.

    Manapság pedig az első script kiddie fog egy Delphi-t és ehhez hasonló tudású programot 1 nap alatt összeüt.

    Ilyenkor gondolok arra, hogy nem volt mindenben szerencsés ötlet a RAD eszköz.

    Arról nem beszélve, hogy ezért a programért fog kérni 20 ezer forintot a megrendelőtől, engem meg hülyének néznek, ha nem vagyok hajlandó ennek 10-szereséért sem dolgozni... De ez már más téma :(
    Mutasd a teljes hozzászólást!
  • Ugyanúgy használhatod az egyébként nem ingyenes forrás titkosítókat is, mint ahogy lefordítasz egy binárist (Zend Encoder/Optimizer, IonCube Encoder), ráadásul ezek gyorsítják is az alkalmazásodat.

    Azért mondjuk ez nem igazi érv, mert ha ezeket a programokat fel tudod rakni (ti. rendszergazda vagy), akkor már azt is tudod biztosítani, hogy csak az férjen hozzájuk, akiknek te engedélyezed.

    Ez igazából csak PHP alapú motorok licenszelésénél lehet érdekes.
    Mutasd a teljes hozzászólást!
  • Oooo, teljesen igazad van, de azt azert ne feledjuk el, h ez inkabb sql hiba, es nem a nyelv-e. :)

    Ez nem SQL hiba, hanem programozói hiba...
    Mutasd a teljes hozzászólást!
  • De ezt Vargusz kollega is kifejtette :)
    Mutasd a teljes hozzászólást!
  • Oooo, teljesen igazad van, de azt azert ne feledjuk el, h ez inkabb sql hiba, es nem a nyelv-e. :)
    Mutasd a teljes hozzászólást!
  • Ugyanígy csinálhatod szerintem minden más nyelven is az ilyesfajta hibákat, amennyiben a sebezhető módszert választod direkt.
    PHP-ban is írhatsz biztonságos kódot. A (hivatalos) PEAR::DB class például lehetőséget ad a következőre:
    $db->query("SELECT * FROM NEVEK WHERE NEV = '?'",$nev)
    Vagy, ha eléggé oda tudsz figyelni, akkor a következőt is használhatod:
    mysql_query("SELECT * FROM NEVEK WHERE NEV = '".mysql_real_escape_string($nev)."'")
    Csak azt ne mondd hogy delphiből nem tudsz forráskódban levő sql queryket futtatni. Másrészt, megfelelő adatbázist használva igenis lehet PHP-ből is tárolt eljárásokat hívni. Tehát itt nem látok különbséget a két lehetőség között.
    Továbbá említetted a zárt forráskód hiányát. Ugyanúgy használhatod az egyébként nem ingyenes forrás titkosítókat is, mint ahogy lefordítasz egy binárist (Zend Encoder/Optimizer, IonCube Encoder), ráadásul ezek gyorsítják is az alkalmazásodat. Kérdezem én, kire vetsz, ha egy bináris alkalmazásod mellé felteszed a forrását, és bárki elolvashatja? Vagy delphiben honnan szeded egy adatbázis user jelszavát?
    Mutasd a teljes hozzászólást!
  • Azért bizonyos esetekben az eszközök kínálják a bugok lehetőségét. Most itt nem elsősorban a PHP-re gondolok, hanem úgy általánosan.


    pl:

    Komoly biztonsági rizikót látok abban, amikor az SQL lekérdezés benne van a PHP/ASP-ben.

    Az egy ügy, hogy aki hozzáfér a fájlhoz, az látja a business logic-ot, ami nem biztos hogy előnyős. Ez a kisebb probléma.

    A nagyobb rizikó az, hogy így a programozó hajlamos rossz megoldást választani. Itt elsősorban a kapott paraméterekből dinamikusan összerakott SQL-re gondolok.

    Ilyenkor ugyanis sokan elfelejtik az SQL injection sebezhetőségek.

    Erre sokkal jobb megoldást ad, ha tárolt eljárásokat használ az ember. Az eljárás nevét "statikusan" megadja, majd a paramétereket a tárolt eljárás paramétereinek adja át.

    Tehát pl Delphi-ben így:

    with StoredProc, Parameters do
    begin
    ProcedureName := 'spValami';
    ParamByName('param1').AsInteger := X;
    ParamByName('param2').AsString := Y;
    end;


    Ez a kód sokkal kevesebb sebezhetőséget tartalmaz, mintha dinamikusan pakolgatnám össze az SQL mondatot.

    Ugyanis, pl. ha MSSQL szerver van, akkor az alábbi "keresési string" megadásával nem vágom tönkre a szervert:

    pl. A keresési kód:

    "SELECT * FROM NEVEK WHERE NEV = '$nev'"

    A veszélyes "keresőfeltétel" pedig:

    '; SHUTDOWN --


    Na ez a hiba tárolt eljárásnál és paraméterek használatakor nem fordulhat elő.
    Mutasd a teljes hozzászólást!
  • Namost, erre csak azt tudom mondani, h nem igazan a programnyelv lehet bugos, hanem a kod, amit ir az ember. Igy aztan lehet fejleszteni PHP-ban, PERL-ben, ASP-ben, ha bena az ember, akkor a program nem lesz bugos. Egyebkent meg megfelelo biztonsagi beallitasok (PHP-t futtato usernek csak 1 konyvtarban van iras-olvasas joga) nem lehet gond.
    Mutasd a teljes hozzászólást!
  • Csak azért, mert most nemrég hallottam egy beszélgetést, és vannak cégek, akik óckodnak a PHPtól, inkább PERL, mert hogy biztonságosabb. Na most itt komoly UNIX rendszerekről van szó.
    Mutasd a teljes hozzászólást!
  • Hááát, a PHP nem új dolog, legfeljebb Neked....

    Én mindenféleképpen a PHP-t javasolnám. A PHP világ dinamikusan fejlődik, a PERL meg stagnál.

    A PHP-ben egyszerűbb kódolni, főleg, ha egy űrlapból érkező, nagy mennyiségű változót kell feldolgozni.

    A biztonság tőled is függ! PERL-ben is lehet lyukas programokat írni.

    Kódoltam PERL-ben is PHP-ban is elég sokat, a PHP hatékonyabb.
    Mutasd a teljes hozzászólást!
  • Itt olyanra gondoltam, hogy míg a PERL egy régi, kifinomult nyelv, addig a PHP még új, és esetleg ha jobban belemegy az ember (shell parancsot adok ki phpn keresztül, vagy php-n futtatok külső scriptet), akkor van annyira biztonságos mint a PERL? Jó, ezt elég nehéz így megmondani, de ha komoly dolgot kell csinálni, amit webről is lehet irányítani, mit választanátok?
    Mutasd a teljes hozzászólást!
  • Na azért ha a jelszavakat md5-el kódolod kicsit meg lehet nehezíteni a dolgát. Bár a jelszót akkor írja át amikor akarja...
    Mutasd a teljes hozzászólást!
  • Mit nevezel biztonságnak?

    pl. Hogy hostolod valahol az oldalt, és ott bármely rendszergazda (talán még az sem kell) belenézhet a PHP/Perl scriptek kódjába? Ergo látja a "busines logic"-ot, de ami komolyabb: az adatbázis loginodat, ezen keresztűl a regisztrált felhasználók adatait, jelszavait, stb... (És ugyebár 1 felhasználó általában nem használ több jelszót, ezért van egy joker jelszava a gépéhez/email-jéhez, stb...


    Ui: Vagy paranoiás vagyok? :)

    Mutasd a teljes hozzászólást!
  • PHP avagy PERL a biztonságosabb? Van elég biztonságos manapság a PHP? Ez érdekelne.
    Köszönöm
    Mutasd a teljes hozzászólást!
abcd