Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Náš Lopuch Vám
vytře zrak

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub PHP [ŽP: neomezená] (kategorie Programování) moderuje makovec.
Archiv
Diskuse o vybornem skriptovacim jazyku php. Dulezite odkazy, pred polozenim dotazu zkuste hledat odpoved zde:
  1. www.php.net - domovská stránka PHP
  2. www.kosek.cz - spousta tutorialu pro PHP v češtině
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: kwksrmf
[ 1845 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
knedle knedle online - Krabice živých 9.8.2007 15:36  2012
dotazjak vypada reg vyraz, ktery mi rozdeli string podle '
ale bude ignorovat \' ?

tj> tento retezec 'rozdeli na' tri \'ruzne retezce\' a ne na pet

nejak se v tom motam
huh huh 8.8.2007 02:05  2011
pepak [2008]: Neresim. IMHO je bud potreba mit aplikaci zabezpecenou a pak je jedina volba sifrovat (https) nebo ne a pak je to jedno. Zadny bastl neudela z nesifrovanyho http bezpecnou vec, to mi prijde podobne naivni jako ty ruzny javascriptovy sifratory hesel :-).
etdirloth EtDirloth 7.8.2007 12:26  2010
pepak [2008]: neriesim to vobec (test HTTP_USER_AGENT je imo hrozny napad - nepouzil by som to asi ani ako barlu) -> jediny sposob, ktory ma napada je sledovanie sekvencie requestov, lenze to si opat nemozes otvorit viacero okien naraz a dost si tym komplikujes zivot aj ako programator - ked chces mat klud na dusi, povol admin rozhranie (resp. akekolvek rozhranie podliehajuce restrikciam) vylucne cez https
knedle knedle online - Krabice živých 7.8.2007 12:06  2009
hm tak to je vec, ke ktere jsem se jeste nedostal - budu si o session hijack neco precist
pepak pepak - Pepak.net 7.8.2007 07:33  2008
Jak chráníte svoje aplikace proti útokům typu session hijack? Trochu jsem si to teď studoval (např. na PHP Security Consortium) a nějak nevidím cestu, jak to zařídit. Jako částečná ochrana mi připadá jenom testování REMOTE_ADDR, i když to moc nechrání v případě, že je útočník za stejným NAT/proxy jako oběť (nebo v případě, že mu stačí jednorázové poškození - např. sebrat session adminovi a s podvrhnutou IP adresou poslat příkaz na smazání nějakého záznamu).

Security Consortium navrhuje testování HTTP_USER_AGENT, eventuelně v kombinaci s nějakým hashem, ale to mi připadá jako naprosto neúčinné - když už budu schopen ukrást session id (předpokládám přenos v cookie), tak nepochybně dokážu ukrást i cokoliv jiného, co se v HTTP hlavičkách přenáší. Dále doporučují obnovu SID, což je asi OK poté, co uživatel potvrdí svoji identitu (např. jménem a heslem), ale vůbec se mi nelíbí dělat to průběžně, protože je pak docela problematické otevřít si několik stránek najednou.

Řešíte tohle vůbec nějak? A pokud, tak jak?
pepak pepak - Pepak.net 7.8.2007 07:32  2007
Nakonec jsem to napsal víceméně podle toho, co jsem napsal do posledního odstavce příspěvku 2003. Na vstupu mám údaj o jménu základní třídy (např. ZakladniDatabaze) a jménu třídy, se kterou budu všude dál pracovat (Databaze). Procházím výstup get_declared_classes() a hledám poslední třídu, která je potomkem základní třídy. V okamžiku, kdy ji najdu, si z ní odvodním potomka se správným finálním jménem: eval("class ${finalnitrida} extends ${nalezenatrida} { };");. Zatím se zdá, že to funguje dobře, akorát se mi nelíbí, že musím spoléhat na nedokumentovanou vlastnost get_declared_classes(), že se třidy vrací v pořadí, v jakém byly deklarovány.
etdirloth EtDirloth 2.8.2007 09:04  2006
pepak [2003]: urcite by som zostal pri tom, ze "viem ako sa ma cielova trieda volat" - uz len kvoli moznosti konfiguracie (nastaveniami si urcim, ktora uzivatelska trieda sa ma pouzit na vytvorenie instancie)

- ak mas pocit ze od jednej 'Zakladnej'.$triedy je uzivatelom mozne podedit iba raz, sprav vsetky "systemove" (tzn. neuzivatelske) dedenia vylucne abstraktne (potom budes moct urobit instanciu iba z uzivatelskej zdedenej triedy, pretoze ta jedina bude konkretnou implementaciou)

- ak uzivatel potrebuje nieco ako "viacnasobnu dedicnost", pripadne vytvorit viac tried zdedenych podla 'Zakladnej'.$triedy, implementuj si Tovaren a k nej riadiaci mechanizmus, ktory ti umozni urcit (konfigurovat), ako ma byt vytvorena instancia;
- Tovaren ti zaroven umozni vynechat staticke triedy na urovni Produktu a zapuzdrit ten tvoj eval tak, aby uzivatel nemusel v kode pouzivat meno "AktivnejTriedy" (bude to vyzierat nejak takto Tovaren::DajAktivnuTriedu()->volanie_metody(); pricom ked napriklad potrebujes iba Singleton, tak metoda DajAktivnuTriedu(); moze kludne vracat referenciu atd.)
pepak pepak - Pepak.net 2.8.2007 07:51  2004
EtDirloth: To mi připadá jako asi nejlepší řešení. Nelíbí se mi jen to, že pokud mám opravdu využít možnosti databáze, tak toho v té knihovně bude muset být strašně moc.
pepak pepak - Pepak.net 2.8.2007 07:50  2003

Řeším teď otázku, jestli jde v PHP nějak rozumně zařídit dědičnost mezi statickými třídami. Rád bych dosáhl toho, abych měl sérii základních tříd, od kterých bych mohl odvozovat potomky s tím, že aplikace prostě použije posledního nadefinovaného potomka. Kdybych chtěl ty třídy instancovat, byla by to trivialita:


// Tohle se nachazi nekde v zakladni casti aplikace

class ZakladniTrida { ... }
$aktivniTrida = new ZakladniTrida();

// Tohle si napise uzivatel
class OdvozenaTrida extends ZakladniTrida { ... }
$aktivniTrida = new OdvozenaTrida();

// Kdekoliv v aplikaci pak pracuju s instanci $aktivniTrida
// a neresim, ktery konkretni potomek je pouzit.
$aktivniTrida->vykresli_zahlavi();
$aktivniTrida->vykresli_telo();
$aktivniTrida->vykresli_paticku();


Na instancích se mi nelíbí pár věcí, hlavně to, že pak musím řešit viditelnost proměnných, správné přiřazování (použít nebo nepoužít referenci) a tak nějak se mi to zdá méně bezpečné (vždycky si někdo může usmyslet, že zrovna proměnnou $aktivniTrida potřebuje pro svoje celočíselné ID pro třídu výrobků).



Pro statické třídy nelze přímo použít žádnou proměnnou, že bych měl třeba $aktivniTrida = 'ZakladniTrida';. Nicméně jsem si našel způsob, jak tohle obejít (na vstupu mám $aktivniTrida = 'ZakladniTrida';, z toho potom vytvořím novou třídu AktivniTrida pomocí eval("class AktivniTrida extends $aktivniTrida { } a skutečně pak můžu požívat věci jako AktivniTrida::vykresli_hlavicku(); a opravdu to funguje tak, jak by člověk od zděděného zpracování očekával.¡V tom není problém.



Spíš se teď zabývám tím, jak tenhle systém udělat co nejjednodušší pro použití. Teď na to mám funkci založenou na tom, že vím, jak se ty třídy mají jmenovat: Na vstupu dostanu string se jménem třídy, kterou potřebuju dostat, a vycházím z předpokladu, že se předdefinované třídy budou jmenovat Zakladni${jmeno} a uživatelské jen ${jmeno}, takže můžu prostě naincludovat soubory, podívat se na to, jestli existuje třída ${jmeno} a pokud ne, udělat ten eval výše. To funguje docela uspokojivě pro dva možné potomky třídy (základní a uživatelský), už ne tak pro tři (základní, modifikovaný základní [možno si představit třeba jako cachovanou variantu základní verze]) a víc. Teď přemýšlím o tom, jak to udělat pro větší počet možných potomků. Zatím mi připadá docela použitelné jít na to přes get_declared_classes() a prostě si po vložení příslušných souborů najít poslední odpovídající třídu a tu evalnout. Co byste na takové řešení řekli?

etdirloth EtDirloth 31.7.2007 12:49  2002
pepak [1999]:
4) ja som podobny problem riesil vytvorenim Data Access Layer -> samostatna kniznica, ktora riesi vsetky pristupy k DB vo forme funkcii/metod, zapuzdrujucich samotne SQL statementy a ich volania, pricom samotna aplikacia/engine/system neobsahuje ani ciarku SQL, ale dotazuje sa prave prostrednictvom tejto kniznice (analogia ulozenych procedur) -> ked sa rozhodnes pouzit novy SRBD, proste prepises celu kniznicu pre tento novy system a linknes ju namiesto povodnej

pridanim novej vrstvy ziskas vacsiu volnost v sposobe jej implementacie (moze byt okrem ineho napisana v inom jazyku, vyuzivat specifika daneho SRBD a tym optimalizovat pristup k datam, ...), ale zaroven si pridas potrebu reimplementacie kazdeho pouziteho SQL statementu pre kazdy pozadovany SRBD (ale to by si konec koncov aj tak musel urobit)
mach 31.7.2007 10:59  2001
Hm, prispevek s id 2000 a hned je v nem chyba:

"ted se rozmyslim" <— "ted kdyz se rozmyslim"
mach 31.7.2007 10:58  2000
Dlouho jsem nepouzival templaty a v PHP generoval semanticky HTML kod. Ted na par veci pouzivam Smarty a jsou fajn. Co se tyce porovnani obou pristupu: pomoci stylovani CSS se neda udelat plnohodnotna view cast MVC-like frameworku; ted se rozmyslim, ze na nejakou stranku chci pridat detailni prehled produktu v kosiku, tak proste nekam pripisu:

{include file=cart_overview.tpl}
pepak pepak - Pepak.net 31.7.2007 07:39  1999
A neprilis souvisejici druha otazka: Rekneme, ze chci napsat vicemene univerzalni system, kde si uzivatel muze pomoci nejakych promennych upravit chovani k obrazu svemu. Hezky je to videt treba na databazovych nebo jazykovych tridach - system by mel byt schopen prizpusobit se uzivatelovu prostredi (ja bych treba chtel Firebird, ale nekdo hned zacne vyskakovat s PostgreSQL a spousta lidi samozrejme zna a pouziva akorat MySQL, takze je treba pocitat i s nim), ale je docela otazka, jak to udelat, kdyz kazde prostredi bude mit sva specifika: I treba u jazyku je to uz videt (kazdy jazyk pouziva jiny format data a casu, napriklad, ale muzou tu byt treba otazky slovosledu - pro nektery je lepsi "100 uzivatelu online", pro jiny "online 100 uzivatelu" a ne vzdycky to pujde osetrit pres printf), u databazi uz je to docela extremni (i kdybych se drzel jenom MySQL, bude diametralni rozdil, jestli budu pouzivat trojkovou radu, ctyrkovou radu nebo petkovou radu - nemluvim o tom, ze jednou se vola mysql_* a podruhe mysqli_*, jde treba o takovou vec, ze na MySQL 5 si spoustu veci napisu jako ulozenou proceduru nebo trigger a tim mi odpadne obrovska spousta PHP kodu).

Jaky je vas nazor na to, jak tohle resit? Vim o nekolika cestach, kudy do toho, kazda se mi ale zda do jiste miry nevyhovujici:

1) Nekolik souboru, kazdy pro jednu variantu implementace (jako to dela treba PHPNuke): Mam treba soubory mysql.php, postgresql.php, interbase.php apod., ktere vsechny obsahuji stejnou strukturu trid nebo funkci (kazda obsahuje treba funkce jako sql_connect() nebo sql_query() se stejnou strukturou parametru a implementuje je pomoci specifickych funkci toho ktereho rozhrani). V programu proste includuju tu verzi, kterou si uzivatel vyzada. Problem je v tom, ze me to stavi pred dilema, jestli radsi vyuzivat jen ty funkce, ktere jsou spolecne vsem implementovanym systemum (a obetovat tak spoustu vykonu i moznosti) nebo jestli timhle zpusobem rozepsat strasne velkou cast kodu (fakticky si nevystacim s sql_query(), potrebuju spis neco jako sql_read_article() nebo sql_create_user()) a stejne mit neefektivni aplikaci (tentokrat spis spotrebou pameti - vsechna data se musi najednou nacist do promennych a teprve pak zpracovat) a navic to nejspis bude tak neprehledne, ze se v tom nevyzna ani prase.

2) Jeden soubor a v nem na kazdem vhodnem miste spoustu vetveni podle jednotlivych parametru (tak funguje nebo aspon drive fungovalo phpBB): Proste mam funkci create_user() a v ni je na vhodnem miste vetveni typu if ($database_engine=='mysql') { ... } elseif ($databaseengine=='postgresql') { ... } else ... Je to taky neprehledne, ale asi o neco min nez predchozi pripad, naproti tomu se mi vubec nelibi, ze to znamena pri kazdem provadeni skriptu prinejmensim zparsovat, kdyz uz ne primo spustit, obrovskou spoustu zbytecneho kodu.

3) Docela se mi libi myslenka, mit zdrojak v podobnem tvaru jako bod 2 vyse, ale delat spis necim jako jsou v konvencnich jazycich IFDEFy - s tim, ze pred vlastnim nasazenim na web se kod napred prozene nejakym prepocesorem, ktery podle zadanych parametru vyhazi vsechny zbytecnosti a necha jen cisty PHP kod. V podstate se tak prace s vybranim vhodne vetve prehodi z runtime na install-time, zvetsim praci pro cloveka, co to bude poprve nasazovat, ale zmensim praci pro server pri vlastnim behu. Problemu je nekolik: Jednak nevim o nastroji, ktery by mi tohle umoznil (ale to se da celkem snadno zaridit), hlavne si ale nedovedu predstavit, jak bych takovy system ladil nebo upravoval, protoze tim preprocessingem vlastne prijdu o primou a pruhlednou vazbu mezi zdrojakem a tim, co se skutecne vykonava. Pokud by system bezel na serveru, kde je nejaky akcelerator, tak se to snad da resit nejakou specialni syntaxi komentaru, ale pak bude docela problem vyznat se v tom, kde ktery komentar zacina a konci...
hugo hugo Usmívejte se, - bude hůř!!!! 31.7.2007 07:31  1998
U větších projektů používám Smarty. Ale někdy je to trochu poznat na rychlosti. Ovšem pokud design dělá někdo jiný, tak je to neocenitelné.
pepak pepak - Pepak.net 31.7.2007 07:13  1997
Jak se divate na nejruznejsi templatovaci systemy? Porad tak nejak premyslim, jak by mel idealni templatovaci system vypadat a jestli by nakonec nebylo nejlepsi se na templaty vykaslat uplne (napsat do PHP zdrojaku natvrdo HTML kod, takovy, aby sel snadno stylovat).

[ 1845 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt