[PHP] rename()

walther ma nakazil bezpecnostou a vyssim zaujmom o nu, prave si riesim upload obrazkov v systeme co si programujem a mam tam aj nastavene nejake opravnenia k fotkam. Zaujimala by ma funkcia rename() aspon tu som na to pouzil a chcel by som vediet ci neexistuje nieco vykonnejsie, alebo je to postacujuce a nemusim sa bat ze v pripade niekolko tisic fotiek by bola pomalsia, do toho sa moc fakt nevyznam.

Po nahrati fotky sa mi ulozi fotka do 1000x1000px, ak je vecsia tak sa na tieto rozmery v jeho pomere zmensi a ulozi do adresara avatar/full, dalej sa z originalu urobi dalsia zmensenina, resp stvorcovy vyrez a zmensi na 200x200px a ulozi do adresara avatar. Obe fotky maju takyto tvar, rozdiel je len /avatar/obrazok.jpg alebo /avatar/full/obrazok.jpg

http://www.qlp.sk/avatar/full/1_460a369 ... 963694.jpg

Zaujimalo by ma ci takato velka dlzka nie je zbytocna, ak je to sumak a pri takejto dlzke sa nemusim bat ze by sa niekto k fotke ktora by mala to najvyssie opravnenie, teda by bola dostupna len urcitym uzivatelom, tak ci rename() nebude pomalsi ak budem mat v oboch adresaroch x tisic fotiek, popripade ak to bude mat nejaky vplyv na vykon, ako to co najlepsie spravit? Kazdu zmenu opravnenia k fotke alebo profilu sa cez rename zmeni aj nazov fotky v tych dvoch adresaroch a tiez sa aktualizuje v databaze. Generovat fotky cez php a tak urcovat opravnenie fotky nechcem, pride mi to ako zbytocna zataz phpcka, popripade ako riesite opravnenie fotiek vy ak to nejde cez php? Da sa to nejak efektivnejsie spravit? Napadlo ma spravit aj to, ze kazde prehlasenie by sa kazda fotka vzdy prepisala, to je uz asi kravina ze? ide mi o vytazenie, ci to bude viditelne na rychlosti. Neviem ci som to dobre opisal co ma zaujima

To, či bude prístup ku konkrétnemu súboru pomalý (ak je v adresári veľmi veľa súborov) záleží od použitého súborového systému (a prípadne nastavenia toho súborového systému).

Inak nie je nutné, aby bola cesta, ktorá sa používa pri HTML rovnaká, ako je umiestnenie na disku, takže nie je napr. problém mať tie súbory rozdelené do adresárov (a časť názvu sa použije ako adresár/adresáre, takže súbor abcdefghijk.jpfg by mohol byť v ab/cd/efghijk.jpg; samozrejme ak chceš, môžeš mať tú cestu aj v url, niektoré stránky to tak robia).

PS: A ani napr. mega.co.nz nemá tak dlhé názvy ani v prípade, že je v URL aj heslo.

Aha, cize ak by som to premenoval nejak inac tak je to teda jedno, napadlo ma to ukladat do adresarov /avatar/prvych100/ /avatar/prvych100/full/, /avatar/prvych100-200/ /avatar/prvych100-200/full/ atd, malo by to vplyv na rychlost ak by som tam mal 10000 fotiek takto prerozdelenych a pouzil rename() ci je to zajedno a nie je to az tak vysoky pocet suborv aby som zaregistroval premenovanie v pripade zmeny opravnenia k fotke? Nemam to ako moznost nasimulovat a 10000 suborov sa mi moc na hostingu generovat nechce ja len ci sa s takym niecim niekto nezaoberal, ci ta rychlost premenovania bude pozorovatelna v pripade 100 a 10000 ci 100000 fotiek

Cize mozem kludne tie nazvy skratit? nema zmysel ich mat az tak dlhe? Mne je to ako jedno, ide mi tym len o bezpecnost a co najmensiu moznost uhadnutelnosti odkazu danej fotky v pripade ze ma niekto najvyssie sukromie svojej fotografie. Viem ze najlepsie by to bolo generovat cez php, ale to bude iste spomalenie webu skrz zatazovania phpcka takym niecim, si aspon teda myslim...

Ako som písal, rýchlosť závisí od použitého súborového systému a jeho nastavení. Niektoré súborové systémy ukladajú názvy do stromov, takže nájdenie konkrétneho názvu je rýchle. Ak súborový systém ukladá názvy do zoznamu, tak sa môže stať, že pri hľadaní konkrétneho názvu, bude nutné prejsť celý zoznam.

Pri tých názvoch by som pravdepodobne použil SHA-2 (ak sa ale nepoužije salt, tak nebude problém zistiť, či je na serveri uložený konkrétny obrázok, pretože stačí vygenerovať SHA a otestovať URL; ak je to problém, tak ) a pri názve by som použil malé/veľké písmená a čísla, aby bol názov kratší (a nie len 16 znakov, ako tam máš teraz; pri použití 62 znakov by bol názov zhruba o 1/3 kratší).

ok diky, skusim si zistit aky system je pouzity, lebo to bolo ako prve co ma napadlo ze co v pripade ak tam budem mat v buducnosti ja neviem dajme tomu 20000 obrazkov, tak nejaky vplyv na rychlost to urcite musi mat a radsej to spravim teraz ako by som to mal riesit potom a len nadavat ze preco som to nespravil dokladne na zaciatku Ja pri tych nazvoch pouzivam na generovanie nazvu hash_pbkdf2 s sha512 z mojho vytvoreneho stringu ktory je vzdy unikatny, najprv je id profilu, potom hash a za tym unixtimestamp, myslim ze mat na zaciatku id a na konci unixtimestamp nie je nejake bezpecnostne riziko asi, kedze hash je dostatocne dlhy a neviem ako by som nim generoval aj velke znaky, pozriem dokumentaciu ci to vobec vie, kedze tou funkciou ukladam aj hesla a vtedy som sa nikde nedocital ze by pracoval aj z velkymi pismenami...? a ako to myslis ze nebude problem zistit ci je ulozeny obrazok?

Pri tej funkcii môžeš získať aj surové dáta (a nie len reťazec v šestnástkovej sústave) a z tých údajov potom môžeš vygenerovať reťazec v akejkoľvek sústave (netuším ale, či je v Php funkcia, ktorá priamo podporuje generovanie reťazca v base62 z binárnych dát).

Ak mám nejakú fotku (napr. som ju našiel na internete) tak z nej môžem vygenerovať hash a potom url (a ak server vráti 404, tak tam obrázok s takým hash nie je, prípadne server používa iný algoritmus na generovanie url).

ja nerobim hash z fotky, generujem si vlastny vzdy unikatny aj pri nahrani totoznej fotky, cize inac ho mimo nejakej bruteforce metody neziska ze?

Ak je naozaj náhodný, tak ho nemá ako získať a v takom prípade stačí oveľa kratší názov (útok, ktorý by napr. našiel aj výrazne kratší názov v rozumne krátkom čase by si si určite všimol).

Tak ja aspon dufam ze je nahodny, netusim ako si to overit v praxi ze by som pri dvoch rozdielnych stringoch ktore cez tu funkciu spravim hash tak ze by boli totozne preto som to poistil este tym unixtimestampom na konci

Práve si prezradil, ako generuješ ten hash, takže príliš bezpečné to nie je.

Každopádne do toho hash môžeš počítať aj iné údaje, ako len samotný obsah toho súboru (a teda to id používateľa a timestamp mohol byť priamo súčasťou hash hodnoty).

neprezradil, ved nevies aky je string pred vytvorenim hashu, len som uviedol ze na koniec toho suboru za poslednym _ je unixtimestamp co by asi kazdeho napadlo ak si ho pozrie a pred prvym _ je len jedno cislo, tak to tiez kazdeho napadne ze je to id profilu ak si otvori obrazok pri nejakom profile kedze url profilu obsahuje id aby som nemusel riesit unikatne nazvy profilov a aby mohlo byt xy profilov s menom napriklad marek. Samozrejme string ktory cez tu funkciu zahasuhjem je xy veci tak aby to niekoho nemohlo napadnut, tiez tam uvadzas aj pocet iteracii a pri zmene tej hodnoty je hash iny, takze bez postupu by ako sa generuje asi nema sancu nikto ako ho generovat, mna len zaujimalo ci je to dostacujuce zabezpecenie alebo ako to robite vy. Mna toto riesenie napadlo z fasbuku, tam to je tiez nejak tak riesene asi predpokladam, aj ked tam to ide isto cez nejaky jazyk kedze tam funguje aj opravnenie ci mas ako priatel pristup k fotke. Ale tak tomu sa chcem vyhnut, tak preto som tam zvolil taku dlzku, ale asi je to fakt moc zbytocne dlhe. Mna hlavne zaujimal ten vykon ci to bude pomalsie pri zmene opravnenia a premenovaniu danych dvoch fotiek, malej a velkej ak by som tam mal ja neviem 10000 ci 50000 fotiek, ale napisal som na support hostingu, mozno poradia nejake optimalne riesenie alebo napisu ze je to jedno, netusim...

// Spojený príspevok Str 31.12.14 13:04

Tak si to podla toho urob, priečinky pomenuj a_
a fotku v tom a_HASH.jpg...

Cosi som si spravil po par dnoch co som sa k tomu dostal, cez generovanieadresara('nejakyobrazok.jpg') si vygenerujem ako by mala vyzerat cesta adresara k obrazku, cize toto vytvori n/e/j, cez existenciaadresara('n/e/j') skontrolujem vsetky tri urovne ci existuju, ak nie tak sa vytvoria a v poslednej sa navyse vytvori adresar full pre velky obrazok, ak menim opravnenia, tak pri zmene nazvu obrazka opet volam tuto funkciu, nasledne cez rename presuniem obrazok do tejto novej cesty a staru cez kontrolaprazdnehoadresara('n/e/j') postupne odstranim pokial sa v tom adresare nic nenachadza, to iste plati aj pri zmazani danej fotky. Je to optimalne riesenie, ci mi vie niekto dat nejaky hint ako to spravit efektivnejsie? Nizsie mam tie funkcie ktorymi to robim

Keď potrebuješ adresár, tak ho vytvor bez testovania, či existuje (ak existuje, tak tá funkcia zlyhá, čo nie je problém). Každopádne ani to nerieši race-condition pre prípad, že iný proces vymaže adresár po testovaní/vytváraní a pred samotným presunom súboru.

Taktiež adresáre môžeš mazať bez testovania, pretože rmdir môže vymazať len prázdne adresáre (a podľa návratovej hodnoty vieš, či bol adresár vymazaný, takže podľa toho vieš, či má zmysel pokračovať s vymazávaním nadradených adresárov). Bez uzamykania táto časť môže spôsobovať problémy (ako som už písal vyššie).

Inak rename môže niekedy zlyhať (napr. ak nie je možné vymazať súbor z pôvodného miesta), takže by asi bolo rozumné mať aj zálohu v podobe kopírovania súborov.

Takze mi to staci mat takto? a bez uzamykania? Co tym presne myslis? Ako by som to mal teda spravit aby nenastal problem pri takej konkretnej situacii? Ako napadlo ma mat vytvorene tie adresare ale to je vyse 45 tisic adresarov ak to mam 3 vrstvy a to mi pride ako uplna blbost, tak preto to chcem riesit aj vytvaranim adresarov pokial neexistuju a zmazanim ak je posledny adresar prazdny.

Pri tom rmdir prestaneš mazať hneď ak tá funkcia vráti FALSE (pretože takmer určite sa nebudú dať vymazať ani nadradené adresáre). Pri tom vytváraní adresára by ale bolo vhodné, aby sa niečo stalo, ak sa adresár nedá vytvoriť.

Netuším, či existuje nejaké jednoduché a zároveň univerzálne riešenie toho problému. Trochu som pozeral rôzne projekty a žiadny z tých, čo som pozeral nemá niečo také riešené príliš bezpečne (ak sa používa viac adresárov).

No hej, len ja sa chcem zbavit kazdeho adresara pokial je prazdny, proste tam nechcem mat ziadny prazdny adresar v ziadnej vrstve, preto kontrolujem kazdy, ak by som kontroloval len posledny, tak by som aj tak musel kontrolovat nadradeny, dalsi nadradeny atd. Tym tvojim navrhom by som predsa tiez musel kontrolovat ci sa da dany nadradeny adresar zmazat, alebo nechapem potom ako to myslis

Ten problem o ktorom pises nemoze nastat pri nejakom moc aktivnom pouzivani takehoto riesenia, ze by tam nonstop prebiehali procesy s vytvaranim, presuvanim a mazanim? ze by to robilo sucasne ja neviem 10000 ludi tak by mohol nastat takyto problem? Lebo k takemu pripadu nedojde si myslim nikdy, pre bezne pouzivanie to asi nema moc vyznam riesit ci? Cely den som s tym dnes zabil ako to nejako najlepsie riesit, moc som toho ani nenasiel na nete, alebo som zle hladal, tak preto som si vymyslel take svoje riesenie.

V momente, keď vytvoríš nový adresár (kvôli tomu, aby so doň presunul súbor) bude ten adresár prázdny a teda je možné, že bude vymazaný. Tento konkrétny prípad sa dá riešiť tak, že sa nebudú mazať adresáre, ktoré boli aktuálne vytvorené, to ale nerieši problém, keď sa bude presúvať súbor do už existujúceho adresára, ktorý bol vytvorený dávnejšie. Táto možnosť sa dá zase vyriešiť tak, že sa pokúsiš presunúť súbor bez testovania a vytvárania adresárov a len ak presun zlyhá, pokúsiš sa vytvoriť nový adresár.

Problém ale je, že tých problémových miest tam môže byť viac, takže ten kód môže byť dosť komplikovaný.

Jasne uz chapem ako to myslis, no skusim to nejak spravit aby sa s tym pocitalo aj ked vobec netusim ako, napadol ma memcache, ze by som pri nahravani a presuvani ukladal do memcache tu danu hierarchiu a pri mazani ju kontroloval ci sa pouziva a ak ano, tak ju nedovoli zmazat, to ma len tak narychlo napadlo, ze ci by sa to nedalo vyuzit...