TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Příklad metody, která volá sama sebe:
class Trida{
static function metoda($level){
echo $level;
if($level<=0)
return;
self::metoda($level-1);
}
}
$trida=new Trida();
$trida->metoda(10); //volání z instance
Trida::metoda(10); //volání staticky
A jak jsi pokročil při odlaďování? Co ti to píše za chybové hlášky?
Zdravím,
Snažím se z kusu HTML odchytit obsah buňky tabulky. Zkouším to přes preg_match_all() a narážím na problém, kdy je html uvnitř této buňky na více řádků. Už znám několik způsobů, kterými mi to nejde:
~<td.*>([^<]*)</td>~si nebo ~<td.*>(.*)</td>~si vynechá buňky na více řádků, i přes modifikátor s
~<td.*>(.*[\r\n]?)</td>~si nebo jiné kombinace tečky a znaků konce řádků nebo \s nevyberou buď nic nebo celé html
Mám PHP 5.4.14 na localhostu na Windows 7 - v Linuxu (z toho, co jsem četl, problém není). Z nápovědy vím o přepínači 's', který za tečku vezme i nový řádek, mně ovšem nefunguje. Snažil jsem se k tomu něco najít, ale *každá* jednotlivá "zaručená" rada, kterou jsem zkusil, nefunguje.
Kdokoli se stejnou platformou (hlášky Linuxáků, že jim to funguje, mi nepomůžou), prosím, poraďte.
P.S. Nepište sem o SimpleXML, DOMDocument apod. - zajímá mě jen regex/kód, který zafungujuje. Díky.
Tady je to obecně (tj. ne specificky pro PHP)
http://www.zdrojak.cz/serialy/e-shop-pomoci-modernich-technologii/
Výrobci komerčních e-shopů v PHP mají pod kontrolou hosting, na kterých běží - klient vůbec nemá přístup ke kódu; e-shop není kupován jako software ale pronajímán jako služba.
Takže potřebuji poradit co mám udělat aby to nědělalo tady tyto přeskoky v tabulce
Najít ve skriptu chybu a opravit ji. To je jediný, co jde u takhle nejasně definovaného problému poradit.
cookies? ne, ty může uživatel smazat (nebo přistoupit z jiného prohlížeče)
session? ne, po expiraci se budou obrázky jevit jako nenavštívené
jedině ukládat informace o obrázcích permanentně na straně serveru (nejpohodlněji asi do databáze). Jako rozlišení, o jakého uživatele jde, se nabízí IP adresa, i když lepší by bylo identifikovat ho tím, že je necháš se přihlašovat (nevím, jestli to, co chceš dělat, je hra nebo soutěž, takže těžko říct, jaké řešení je na to vhodné). Ukládal bych do každého záznamu identitu uživatele, id obrázku, datum posledního odkrytí pro něj, počet odkrytí a jestli ho vůbec zobrazovat. Pokud se datum odkrytí neshoduje s dnešním, uloží se dnešní a počet odkrytí se resetuje na 1. Pokud datum dnešní je a počet odkrytí už byl 5, uloží se, aby se už nezobrazoval.
Jaké jiné formáty než DOCX to jsou?
Ve Windows Office, v jejich Visual Basicu lze otevírat soubory (ty, které umí Oppice otevřít) pomocí tzv. COM objektů a přes ně pak přistupovat k jejich vlastnostem a prvkům.
Já přes to kdysi dávno řešil cosi v Excelu a Accessu, ale jak je to s formátovaným textem, toť otázka. Možná (ale jenom možná) by třeba i v kombinaci s tímto šlo udělat přes schránku, do které je tento obsah nakopírován.
edit: Teď si uvědomuju, že odpověď, kterou jsem ti poslal, je řešení specificky pro PHP a databáze. Jsou i jiná řešení k vyzkoušení, například node.js, který u mnoha lidí získává na oblibě.
Mě osobně se líbí toto řešení:
Statický text:
Dynamický text:
Povrchní řešení:
Lepší řešení:
předělat :-)
P.S. Ono to nevadí, že se to po jednoho smazání souboru a "opravě" celé rozhodí?
#1 tribalcz
Ahoj. Můžeš pomocí preg_replace zaměnit <br> (nebo <br />) za nový řádek nebo je úplně smazat.
Celkově lepší řešení je použít inline HTML editor jako je fckEditor nebo TinyMCE. Ale za ještě lepší řešení považuju použít Texy!, kde se s takovými problémy vůbec nemusíš zabývat.
P.S. Příště zkus trochu zlepšit tvé písemné vyjadřovací schopnosti (diakritika, interpunkce, velká/malá písmena, pravopis…)
> Na co vše si dát pozor?
obecně: snaž se ukládat jen syrový text a konverze dělej před zpracováním či zobrazením.
Vhodný zdroj k přečtení - http://phpfashion.com/escapovani-definitivni-prirucka
Ahoj. Pokud tomu rozumím správně, tak musíš načíst stránku bez vybraných checkboxů a samotné vybrání udělat v JavaScriptu. Ty checkboxy, které se mají na událost vybrat, si (v PHP) dynamicky vypíšeš do pole (už v JS, podle IDček, předpokládám) a v JS si dopiš událost, která toto pole projde a odpovídajícím prvkům nastaví vlastnost checked.
Čus. To samozřejmě nejde. Jak by se ti líbilo, kdybys měl svoje stránky a kdokoli a odkudkoli na světě ti na ně mohl "umístit" svůj JavaScript?
Jde akorát udělat, že si tvá stránka stáhne (na vlastní žádost) externí javascriptový soubor z jiné domény. A docela často se to dělá u knihoven jako jQuery, Mootools, Prototype a podobné.
například tady:
http://stackoverflow.com/questions/6511567/php-mail-multipart-alternative-for-html-plain-text-emails
Pokud se nemýlím, tak třeba Centrum má plnohodnotnou verzi a lite verzi mailu. Tipoval bych, že v takto zaslaném mailu (s textovou a HTML složkou) se v lite verzi zobrazí prostý text a v plnohodnotné HTML - můžeš zkusit.
Hmm.. tak zřejmě base64 nepodporují.
Řešení by mohlo být posílat mail ve dvou verzích - dělá se to hlavičkou/direktivou "Content-Type: multipart/alternative", za kterým následuje značka (boundary), kterou si můžeš vygenerovat - potom pošleš první verzi mailu (včetně hlaviček s kódováním a transferem), pak značku, pak druhou verzi mailu a zase značku. Určitě to lze vygooglovat.
case '+':
echo 'Vysledek je: ' . ($prvni_cislo + $druhe_cislo);
break;
atd.
Zkus testovat datum a čas poslední změny adresáře.
Ber všechno a [číslo]x[číslo] filtruj až při zpracování.
Existuje ještě pár jednodušších RS, například TextPattern.
Mě osobně se poslední dobou začaly líbit systémy, kde text neukládáš ve WYSIWYG editoru, ale v jednoduchém formátu, srozumitelném běžnému člověku - ten se do HTML převádí při zobrazení - za chodu. Příkladem je dokuwiki, která je ale vhodná spíš na dokumentaci čehokoli.
A nebo si můžeš napsat vlastní jednoduchý systém, který použije Texy! Jde-li o web o pár stránkách, uložíš si jejich obsahy do *.txt, ty dáš na web a pouze si doprogramuješ skript, který vezme z URL, jakou stránku má načíst, vezme odpovídající texťák a pomocí Texy! ho zobrazí.
"LIMIT 1,6" začíná od 2. řádku (ne 1. - počítá se od 0). Dej tam prostě "LIMIT 6".
Poznámky:
(Odpovídám Šťouchalovi na původní otázku): Předpokládám, že jsi v pozici, kdy pro klienty děláš stránky v PHP. Podle mě je to (obecně) nezapomenout, že v první řadě děláš pro klienta/zákazníka, jehož spokojenost máš vždy na prvním místě; neustále se v duchu ptáš, co pro něj mohu udělat a jak to udělat co nejlépe (v daných mezích); dostatečně s ním komunikuješ, abys měl kontext a dost informací, pochopil, co chce a potřebuje, navrhl mu možnosti a vysvětlil, která je v čem dobrá, a tak dále.
Podle mě, když tento přístup nebudeš mít, tak je jedno, jakým způsobem pracuješ, kolik knih jsi přečetl, na kolika školeních jsi byl a jaké máš certifikáty, v jakém editoru píšeš, jestli máš tenhle framework nebo ten; ... a vlastně i v jakém jazyku píšeš.
SET NAMES UTF8 COLLATE "utf8_general_ci";
zeptej se na Webtrhu ( webtrh.cz/f21 nebo webtrh.cz/f40 )
Podívej se do on-line dokumentace: ( http://php.net/manual/en/features.file-upload.multiple.php )
Pokud si nejsi jistý, nech si vypsat patřičné proměnné ($_FILES, v tomto případě).
Druhý způsob: uploadify. ( www.uploadify.com/ )
Třetí způsob (vhodný pro velké množství souborů): uploadovat ZIP a ten na serveru rozbalit. ( http://cz2.php.net/manual/en/ref.zip.php )
Příklad řešení:
Ahoj,
Prostuduj si SQL konstrukci JOIN:
http://cs.wikipedia.org/wiki/JOIN
Tvůj dotaz by pak měl vypadat nějak takto:
SELECT shop_product.*,shop_product_lang.* FROM shop_product LEFT JOIN shop_product_lang ON shop_product_lang.product_id=shop_product.id ...
Pokud se produkt pojí s krátkým číselníkem, můžeš si místo složeného SQL dotazu číselník nejdřív načíst do asociativního pole, kde id bude jeho index, a pak ho dosazovat.
a funkci file_exists() znáš? ;-)
Já osobně bych do čtverečků nešel a zvolil bych u všech objektů evidovat jejich [x, y], pravděpodobně s indexací (kvůli tomu, že k nim bude potřeba přistupovat rychle právě na základě jejich pozice). Pak bych periodicky vyfiltrovával 'blízké předměty' (ty, které budou na obrazovce nebo +/- v nejbližším okolí) do jakéhosi lokálního seznamu a s ním bych pak pracoval při zobrazování těchto objektů a vyhodnocování stavu každého z nich - toto by bylo už být rychlé a s příjemným frameratem; filtrování blízkých objektů řádově jednou za pár vteřin (to by bylo třeba vyladit). Toto řešení (si myslím) by šlo i pro hru více hráčů s jedním herním serverem. Dokonce bych si uměl představit zapojit do toho i databázi (vše na jednom místě, optimalizované filtrování objektů pomocí indexů, vyřešené ukládání, atd). Jak nad tím přemýšlím, tak se mi to chce udělat ;-)
Napadá mě to samé - po uploadu PDFka jej nasekat na obrázky a nechat Flash přistupovat k nim. Pro efekt otáčení stránek bude samozřejmě potřeba mít načtenou i následující (a předchozí) dvoustránku.
Mimochodem: http://www.webresourcesdepot.com/5-free-jquery-page-flip-plugins-for-book-like-interfaces/
10^(1,667xU-9.33) hmm.
Můžeš si dovolit nějakou odchylku? Pokud nechceš zabřednout do racionálních čísel, dá se pracovat s celočíselnými zlomky (předpokládám, že alespoň násobení a dělení je přípustné). Například, kdybys vše na za čátku vynásobil 1024, provedl výpočet a poté 1024 vydělil, pak by to bylo:
10^((1707 * U - 9554) / 1024)
A to 10^x bys mohl zpracovat - pro celou část v cyklu x10 - a pro racionální část tabulkově (x od 0 do 1) nebo pomocí určité numerické metody nebo interpolací s využitím druhé popř. vyšších derivací.
Je to tak. Už funguje. Díky.
Zdrojáky a související soubory jsem hodila sem - http://uloz.to/xV9ALT6z/lazarus-sqlite3-example-zip
Snad to těm, kteří mají stejný problém jako jsem doposud měla já, pomůže.
Pozor, 64bitová verze Lazaru vůbec nemá TSQLite3Connection.
@mjseven: Smím se zeptat, jakou máš verzi Lazaru a pro jaký OS?
alternativní řešení
$result=mysql_query("SELECT ... FROM tabulka");
$row=mysql_fetch_assoc($result);
foreach($row as $key=>$value)
if($value)
echo"<p>$key: $value</p>";Počet nutných dotazů to nezvyšuje, seznam druhů můžeš získat jediným dotazem. Přidaná zátěž na MySQL spočívá v použití agregačních funkcí, na něž je MySQL optimalizované. Naopak, hledání podle druhů bude neoptimalizované a bude zatěžovat jak MySQL, tak PHP. Toto řešení se hodí pro malé i velké projekty.
Řešení se serializací:
pokud a, b, c nemohou obsahovat mezeru, pak třeba...
if Pos(' '+a+' ',' '+x+' ')>0 and Pos(' '+b+' ',' '+x+' ')>0 and Pos(' '+c+' ',' '+x+' ')>0 then ...
#5 Andy
No vida, to je o trochu lepší. Takhle bych ti možná i poradil. Podle mě po tobě ze zadání chtějí, abys četl z klávesnice výšky herců *dokud* nebude zadána nulová výška. Nikde není psáno, že počet adeptů (který zmatečně nazýváš "velikosti hercu") bude znám. Proto si myslím, že místo cyklu for se bude víc hodit cyklus repeat...until.
Doporučil bych, abys pojmenovával proměnné podle toho, co v sobě budou uchovávat, tedy žádné a, b, c, d. Při složitých programech bys brzy ztratil kontrolu, která je která.
Dívám-li se dobře, tvůj program určuje minimum, podle zadání má určovat nejvyšší výšku, tedy maximum.
A měl bys tam mít i vyskočení z cyklu (break), pokud je zadána nulová výška.
Zdravím komunitu.
Chtěla jsem najít (jakkoli primitivní) funkční příklad pro použití SQLite3 v Lazaru. Na první pohled se zdá, že nebude problém a že všeho je přehršel. Ale každý – a tím myslím opravdu KAŽDÝ – příklad, který jsem si stáhla, byl ve formě, ve které nešel zkompilovat a házel chyby, které jsem nedokázala odladit (syntaktické i sémantické, jdoucí hluboko do těch nejobecnějších a nejstandardnějších zdrojáků Lazaru). Zkoušela jsem i různé videocasty a opět u každého z nich jsem se dostala do bodu, kdy autorovi videa něco šlo a mě ne. Nedokážu popsat, jak moc jsem z toho frustrovaná, že jsem mohla na takové relativně jednoduché věci pohořet.
Je tu někdo, kdo v Lazaru dělá a má příklad s SQLite, který opravdu funguje? Byl by tak hodný a vložil sem zdroják (klidně v té nejosekanější formě - jen připojení k databázi)? Popřípadě poradil, co všechno je k tomu potřeba (nastavení projektu apod.)?
Budu vděčná za jakoukoli dobrou radu.
(Btw. Dynamickou knihovnu mám stáhnutou a přiloženu v adresáři projektu. Mám naprosto standardní a typickou instalaci Lazaru, verze 1.0.6.)
a co takto...?
A není to takhle?...
for i:=1 to 20 do
if mat[i,1]=0 then
break;
SirkaMatice:=(i-1)*2+1;Ano, je to banalita. A to taková, že pokud si máš zasloužit postup do čtvrťáku, tak bys takto snadnou úlohu měl zvládnout sám a bez pomoci - jsou to naprosté základy. Měl bys být schopen tu úlohu analyzovat do jednoduchého algoritmu a ten pak pouze přepsat do programovacího jazyka - žádné triky ani úskoky v tom nejsou. A pokud toho nejsi schopen, proč by ti měl někdo pomáhat lhát a podvádět? Jaký v tom smysl falšovat, že's jsi něčeho schopen, když nejsi? Já opravdu nechci žít v republice podvodníků, lhářů a rychlostudentů, kteří se od dětství neučí ničemu jinému než jak ostatní očůrávat, falsifikovat svoje neschopnosti a získávat tak lepší příležitosti než ti, kteří se poctivě učí.
Přeju ti, aby ti nikdo ten program neudělal, a musel sis ho napsat sám. Věř, že je to pro tvoje dobro.
(Předpokládám, že se jedná o formulář pro vložení nebo úpravu záznamu v tabulce.)
Moje řešení je hlídat hodnotu id. Tak lze dokonce vystačit i s jedním tlačítkem (pro uložení záznamu, ať už nového či existujícího).
Do formuláři nezapomeň uvést id záznamu (asi bych ho nedělal editovatelné, max. skryté). Při zpracování formuláře zjistíš nejdříve, jestli bylo stisknuto tlačítko pro uložení a poté, jestli existuje id. Pokud ano, upravuješ stávající záznam, pokud ne, vkládáš nový záznam.
if($_POST['ulozit']){
if($_POST['id']){
//uprava zaznamu - UPDATE tabulka SET ...;
}else{
//vlozeni zaznamu - INSERT INTO tabulka(pole) VALUES(hodnoty);
}
}Standardní řešení je třetí tabulka.
Tabulka `produkty`:
id | produkt
Tabulka `druhy`:
id | druh
Tabulka `produkty_druhy`:
id | produkt_id | druh_id
Serializace v tomto případě není čisté řešení, protože s ní nedokážeš jednoduše vyhledávat a filtrovat podle vybraného druhu.
Jak často předpokládáš, že se bude měnit strom kategorií (nemyslím přidávání nových, ale hlavně přesouvání těch existujících)? Bude to hodně často, docela často nebo naopak předpokládáš, že moc ne nebo jen velmi výjimečně?
Pokud jen výjimečně, pak by sis mohl pomoci trikem, který není zrovna čistý, ale zajistí větší rychlost. A sice, místo předchozí kategorie ve formě čísla (parent_id) si budeš ukládat celou cestu od kořene stromu kategorií až k dané kategorii (například jako IDčka oddělené čárkami, aby se dala pohodlně vložit do SQL operátoru IN()). Každý přesun podstromu ale bude potřebovat "přepočítání" seznamu nadřazených kategorií u každé kategorie, které se to týká.
Druhá věc je zjistit si souhrnně všechna ID kategorií, které budu vypisovat (mnoho z nich se bude opakovat), načíst si je do pole a při jejich vypisování používat toto pole a ne dotazy do databáze.
Z toho, co si tady zatím "předvedl", jsem nabyl názoru, že postrádáš základní znalosti fungování JavaScriptu jako takového. "Projekt webového textového editoru", jak to popisuješ, přitom patří mezi ty složitější případy. Má rada je doplnit si základy na jednodušších příkladech a pak se pustit do těch obtížnějších. Neber to ve zlém, všechno se dá naučit, když se chce.
Do hlavní stránky se doporučuje dát hlavičku kódování nastavenou na UTF-8 (a mít tento soubor skutečně uložený v tomto kódování, navíc bez BOM - to je zkratka pro byte order mark - pár bajtů na začátku, které mohou u HTML udělat pěknou paseku, takže toto vypnout). To samé v bledě modrým u skriptu, který se volá přes AJAX a který hledá a vrací výsledek. I tento skript by měl na výstup odeslat hlavičku o kódování (hlavička jsou metadata, ne samotný obsah, tvůj výsledek v JSONu to neovlivní).
Použil jsi složený dotaz? Něco jako…
SELECT fotky.id,COUNT(komentare.fotka_id) FROM fotky
LEFT JOIN komentare ON komentare.fotka_id=fotka.id;
…?
"už jsem to udělal tim jednim" - jaký přístup jsi tedy zvolil?
"Problém se stránkováním" - upřesni mi to: stránkování čeho? produktů v kategorii?
"Každý produkt má minimálně 20 stromů kategorií" - minimálně nebo maximálně?
Jinak, našel by se i způsob, jak přečíst těch 20 odkazů na kategorie, které máš takto ve 20 záznamech uložené v tabulce, na jeden dotaz/komunikaci s databází. Buď přes uloženou proceduru a nebo přes finesu, které se říká CTE - Common Table Expressions (jen jsem o tom slyšela a nevím, jestli to má MySQL - to by chtělo nastudovat).
Někoho by napadlo též vkládat cestu jednotlivých kategorií, tak, jak jdou za sebou, do jedné hodnoty jako celek (např. jako seznam čísel, oddělených čárkou), ale akademik by nad tím pozvedl obočí, protože je to nesystémové řešení.
http://php.vrana.cz/…zivatelu.php
P.S. "login systém" je strašná, češtinu mrzačící patlanina. O přehnaném používání slova "systém" viz stejnojmennou kapitolu v http://www.dfens-cz.com/view.php?…
Optimalizace dotazu CZechBoYe:
SELECT cislo, jmeno, kategorie, LEAST(IFNULL(cas1,9999), IFNULL(cas2,9999), IFNULL(cas3,9999)) AS minimum
FROM `rychlostka`
ORDER BY minimum
Tip na průměr:
(IFNULL(cas1,0)+IFNULL(cas2,0)+IFNULL(cas3,0))/(3-IFNULL(cas1,1)-IFNULL(cas1,2)-IFNULL(cas3,1))poznámka: pozor, pokud chceš zajistit nějaké pořadí (mandatorní, časové nebo jiné), pak bych doporučovala vytvořit ještě jeden sloupeček. přestože se tvoje ID nejspíš zvyšuje s každým novým záznamem, nemusí to znamenat, že vyšší ID = novější záznam. Toto by se mělo řešit ad hoc sloupečkem (indexovaným).
#1 CZechBoY
Je-li tvůj produkt zanořený do 20 kategorií, pak ke zjištění celé této cesty potřebuješ buď 20 dotazů (1 na kategorii a 19 na parent_id) a nebo 1 dotaz s JOIN na 20 tabulek.
Alternativa může být např. toto http://php.vrana.cz/traverzovani-kolem-stromu-prakticky.php
(ano, fungují tam i podadresáře - pak proměnná obsahuje lomítko, které je odděluje)
Myslím si, že v tomhle případě není moc důvodů zapojovat do toho ještě databázi - klient, pro kterého to dělám, chce jednou za čas přistoupit na ftp, vytvořit nový adresář, nakopírovat do něj pár stovek fotek, a spolehnout se, že galerie bude ihned fungovat a bez potřeby jakékoliv synchronizace zohledňovat změny.
Zda-li je lepší mít obrázky v souborech nebo v databázi (a to včetně obsahu), viz např. http://forum.root.cz/index.php?… (zdrojak.cz nebo root.cz) o tom existoval článek, který citoval studii, která říkala, že co se týče rychlosti, tak pokud je velikost dat do určité hodnoty (a myslím, že to byl 1 MB), pak se vyplatí databáze, pro větší pak soubory.
Výhody ukládání obrázků v databázi (včetně obsahu):
* Nemůže se stát, že by se někdo (ať už z jakéhokoli důvodu) dostal na ftp a tam ti nekontrolovaně smazal, přepsal nebo přesunul pár obrázků a ty by ses o tom nedozvěděl do okamžiku, kdy bys je chtěl zobrazit. (Nutno říci, že byť k tomu dojít může, je to málo pravděpodobné.)
* Pokud chceš ke každému obrázku spravovat i popisek (ať už jeden či více, v jednom jazyku či multilinválně), pak se víc hodí víc databáze.
* Pokud chceš mít pro každý obrázek i miniaturu (ať už jednu nebo různé velikosti), pak se víc hodí databáze.
* Pokud chceš mít v názvu obrázku diakritiku a znaky, které by jinak nešly zobrazit (\ : ? \0 \n…), pak jedině přes databázi.
* Pokud plánuješ možnost ukládat víc verzí stejného obrázku nebo možnost mít více obrázků stejného jména, pak jedině přes databázi
Je to proto, že databáze drží obrázek a všechny informace a metainformace o něm v jednom záznamu.
Nevýhody ukládání do databáze:
* Při zálohování a exportech databáze sql soubory nabobtnají na desítky až stovky megabajtů a manipulace s nimi začne být o trochu náročnější.
* Velikost databáze může být také problém (to si zjisti sám, jestli by to případně nebyl problém),
* Úkoly typu "u tohohle obrázku se mi nelíbí tenhle pixel a chtěl bych ho upravit" bývají při ukládání do databáze složitější.
* Větší nároky na databázi, když má najednou "vyplivnout" obsah stovek obrázků. (U řešení přes soubory je zátěž (na webserver jako celek) v podstatě stejná, v tomto případě je ale soustředěna celá na databázi ("úzké hrdlo"))
* Naopak, při použití sendfile() (kdy v databázi je jen cesta k souboru) je šance, že systém (je-li tak nakonfigurován) pošle soubor asynchronně.
1000 souborů snad ještě jde zvládnout přečíst a poslat během zlomku sekundy. Rozhodneš-li se pro další dělení do adresářů, klíč podle počátečních písmen nemusí být efektivní, doporučil bych nějakou jednoduchou hashovací funkci.
OK, zkusím to ještě jednou.
Ostatní bezpečnostní rizika (která, jak říkáš, jsou všude stejný) si většinou umím najít, prostudovat a uplatnit. Zajímá mě ale tento specifický způsob, ve kterém (nejen pro admina ale i pro klienty) je v parametru předávána relativní cesta k fotografiím ve fotogalerii a zajímá mě jestli test na existenci předaného adresáře (který dělám na začátku skriptu) je dostatečné bezpečnostní opatření.
Celý kód vkládat nechci (měj pro to prosím pochopení), ale řeknu, že po tomto testu s proměnnou $_GET['folder'] pracuju jako s cestou k podadresářům – používám ji jako parametr při čtení adresáře (klasicky přes opendir() nebo glob()), zobrazuju název této cesty v hlavičce html a nadpisech, vkládám ji do html jako součást cesty k obrázkům fotogalerie (všude, kde ji vkládám do html, jde přes htmlspecialchars()). V adminu tato cesta navíc figuruje ve vykonávání několika administračních úkonů jako např. generování miniatur - vždy jako cesta k vybraným fotkám.
Pokud je v $_GET['folder'] předána cesta, která neexistuje, nebo se pomocí ../../.. snaží dostat pod úroveň fotogalerie, je přepsána na prázdný řetězec, což je interpretováno jako výchozí úroveň ("titulní stránka") fotogalerie, která nabídne seznam složek pro procházení.
Ještě jednou se tedy ptám – je výše uvedené třířádkové testování oné proměnné pro relativní cestu dostatečně crackuvzdorné? Víte někdo o nějakém triku nebo hodnotě, která by takto mohla být přes URL podstrčena a dokázala by obejít tuto kontrolu a způsobit nějakou škodu?
Díky.
* Alternativou by mohla být funkce iconv().
* Řešit takto převod na "cestinu" výčtem znaků nikdy nebude dokonalé, protože vždycky se najde nějaká další výjimka, která bude obsahovat znak, jež není ve výčtu. Řešení pomocí konvertovací funkce tedy chválím. ;-)
Tip pro diskuzi s reakcemi v PHP
To mám opravdu nejradši, když si někdo nepřečte, co píšu, a navíc to dezinterpretuje.
Ukázala jsem na nejdůležitější rys skriptu (co do návrhu a moje řešení ochrany) a zeptala jsem se na jeho bezpečnost a v druhé otázce na nějaká další možná úskalí, která u tohoto návrhu hrozí.
CZechBoYi, pokud se nechceš příště ztrapnit, tak buď čti příspěvky fóra celé, nebo neodpovídej vůbec.
Zdravím.
Udělala jsem pro klienta fotogalerii v PHP.
V jednom k tomu určeném adresáři jsou podadresáře s JPGčkama (i do více úrovní) a také skript, který je zobrazuje a umožňuje uživateli těmito podadresáři procházet.
Rozhodla jsem se k tomu, že podadresáře (vlastně i celá relativní cesta k obrázkům) se předávají jako parametr v URL, případně být zadaný nemusí a pak se zobrazí úvodní stránka galerie. (Toto bych nechtěla měnit.) Teď se zabývám bezpečností.
Chci zajistit, aby podstrčením nějaké hodnoty se nikdo nedostal někam, kam by neměl (z tohoto pohledu kamkoli pod úroveň adresáře s fotogalerií). To řeším takto:
if($_GET['folder'])
if(!is_dir($_GET['folder']=substr(realpath($_GET['folder']),strlen(realpath('.'))+1)))
unset($_GET['folder']);
//... dál pracuji s proměnnou $_GET['folder'] coby s cestou k obrázkům
//... dál pracuji s proměnnou $_GET['folder'] coby s cestou k obrázkům
Skript hledá a zobrazuje pouze JPG soubory - jiné soubory, ať už obrázky či úplně jiné typy, tam admin stejně nedává
otázka: Je toto dostatečná ochrana?
otázka: Napadá vás ještě něco, na co bych si měla dát pozor?
No pozor - ono to zase tak jednoduchý není. Když takto označím různé položky (s různým počtem mezer mezi nimi), bude zatraceně složité udělat, aby při přetahování zbylé položky "probublávaly" mezi těmito mezerami.
Každopádně díky za odpověď.
Zdravím.
Hledám JavaScriptovou knihovnu (např. nadstavbu jQuery), která by uživateli umožňovala pomocí přetahování myší řadit pod sebou vypsané položky/prvky (tedy to, co se většinou uvádí jako vlastnost "sortable"), ale navíc s možností označit si více těchto položek a pak je přetahovat najednou (jako blok).
Poradíte? (pokud tedy něco takového někdo udělal)
Díky
© 2003–2024 Programujte.com