képet csak az arra jogosultnak

Volna egy oldal, ahol sok-sok nagy (min 5MB) képet kéne kiszolgáltatnom, de csak arra jogosultaknak. Az oldal php és mysql alapokon dolgozik. A felhasználókezelés session alapú. És még egy nagyon fontos kitétel, hogy a kliens oldalon jól cachelhető kéne, hogy legyen a kép pont a nagy mérete miatt.
A kép sqlben tárolását a cache miatt kerülném, s a mysql szerver se egy bajnok, hiszen ez egy hobbyproject. A képeket inline kell megjelenítenem az oldalban, mindig azonos névvel.

Kérdésem, hogy tudtok-e ajánlani valami jó megoldást (htaccess...), vagy esetleg meggyőzni arról, h sql alapon is jól fog ez nekem teljesíteni.

Hozzászólások

Altalaban a hobbinak, mint olyannak, az a jellemzoje, hogy az ember elvezettel szedi ossze a szukseges ismereteket, es nem masoktol var megoldasokat. pl. szted mitol lesz egy kep "jol cacheelheto"? Vagy elgondolkozhatnal rajta, hogy ha egyszer a "felhasznalo kezeles session alapu" akkor megis mit akarsz a .htaccess -szel? Meg eleve megis mire szamitasz a kliens oldali cachelesnel "sok-sok" 5+ megas kepnel? Teleirod a felhasznalok lemezet a kepeiddel?

Természetesen arra jó a projekt, h tanuljak belőle, és van is megvalósítási ötletem (ahogy írtam sql), de ennek eddigi tapasztalataim alapján vannak hátrányai. Ha új ötletet vagy valakinek valós tapasztalatát kapom, akkor egyszerűen hálás vagyok.
htaccess nyilván nem megy sessionnal, ezért se ez az út, de ha mégis valakinek van ilyen irányú ötlete, mert ám netet bújva vannak félmegoldások erre, ezért is voltam kíváncsi esetleges tapasztalatora.
A képek meg a felhasználóktól származnak, ezért nekik nem szemét, s ezért is kell, h csak ők férjenek hozzá...

http://weblabor.hu/cikkek/allomanyokkiszolgalasaphpbol talan ez hasznodra valik!

A webrooton kivul tarold a kepeket! Kerdes, hogy kerulnek a szerverre a kepek? Ftp? Webes feltoltes? Kik teszik fel? Felhasznalok vagy az admin? Akarhogy is celszeru a kepeknek uj, egyedi nevet adni (valami hash -t). Az uj nevet, az eredeti nevet, a kep meta infoit tarolod sql-ben. A kepeket php -bol szolgald ki, igy a hozzaferes szabalyozas megoldva!

Köszi, ez a cikk tényleg jó!
A képek sajnos web alapú feltöltéssel a user által kerülnek fel, ezen nem tudok változtatni. Az egyedi nevek természetesen vannak most is, és a metaadatok is sqlben.
Sajnos a cikk is nehézségként kezeli a fájlneveket, és a cache-t:( De majd letesztelem alaposan.
Kösz

Képeket nem tárolunk adatbázisba.
A fájlnevet én úgy oldottam meg, hogy az user által adott fájlnév, majd _ és a dátum/idő.
Ezt tároltam adatbázisba, meg az időt és dátumot, a file típusát, és hosszát.
Így minden fájlnak külön neve van, és vissza is kaphatod az eredeti fájlnevet.
Esetleg eltárolhatod a file mellé a táblába, hogy mely csoport férhet hozzá.
Majd felveszed az usereket, csinálsz csoportokat, belerakosgatod és már kész is vagy.
Már csak a gui marad

pch
--
http://www.buster.hu
--

Fontos a fájlnevek megőrzése? Ha nem, akkor egy [md5|sha1](eredeti_fajl_nev.datum.ido) hívással nagy valószínűséggel egyedi nevet fogsz tudni generálni. Session alapú felhasználókezelésnél pedig session változóban tárolt [láthat_képet] változó értéke alapján lehetne egy módon a képmegjelenítést szabályozni. Persze ehhez adatbázisban is tárolni kell ezt a változót a felhasználó adatai mellett.

--
A gyors gondolat többet ér, mint a gyors mozdulat.

Kellően hosszú random név a képeknek és könyvtárlistázás tiltása vagy megakadályozása (.htaccess vagy üres index.html/php).
A random nevet adatbázisban tárolod és csak arra jogosultak férnek hozzá.
Mit értesz inline megjelenítés alatt?

"A random nevet adatbázisban tárolod és csak arra jogosultak férnek hozzá."

Itt az arra jogosultakat hogy gondolod megoldani? Szerintem itt ugyanott vagyunk, h session / file szintű jogosultság szinkronizálási nehézség van.

Az inline az annyi, h img tagban hívom meg, és ha ott egy olyan url van, ami image.php?id=52342 akkor a file nem lesz cachelve rendesen, mert a headeres névátírás csak a download esetén megy megbízhatóan.

Felhasználó azonosító alapján gondolnám megoldani a jogosultságot, lenne egy fájl táblád amiben a fájl eredeti neve és a random név mellett szerepelne a tulajdonos azonosítója is. Így rendesen lesznek cache-elve a fájlok, később bővítheted a táblát hogy esetleg milyen felhasználókkal/csoportokkal van megosztva az adott kép. Mi a nehézség?

A kérdésfelvetés jogos, de ezt egy pereskedő usernek és a nemes jogászának mondhatod. (szerintem)
Másik, meg, hogy ha a hash-t vm algoritmus alapján generálom (márpedig mi más alapján generálnám), akkor egy hash ismeretével sokkal közelebb van egy brute force megoldással, mint az elméletileg végtelen emberi ötlet által generált random jelszó (nyilván az 123456 jelszó más eset, de ő ne is pofázzon adatlopás miatt).

Igen, lehet, h az url rewrite fog segíteni, mert az este próbálgattam a fent leírtakból összevadászni vmt, de sajnos nem a kívánt eredményt adta. Ha reloadot nyomok, akkor mindenképp újratölti, ha a meghívó oldalt újra begépelem, akkor mintha cacheből szedné.
Jelenleg abba reménykedek, h egy ize.hu/kep_1.jpg -t rewrite-val ize.hu/img.php?id=1-ra átírom, s akkor talán jobban azt hiszi a böngésző, h ő egy kép, s lehet bőszen cachelni.
Az kiötlött alkalmazás egy web alapú képekkel dolgozó alkalmazás lenne. Tehát fontos, h bárhol folytatható legyen a munka, bármely böngészőből, ezért kell feltölteni a képeket. És a használat során kb 10 db 5mb-os képeket rendszeresen cserélgeti a megjelenítés, de vissza-visszatér a már használt képre, ezért kéne a cache, hogy ne kelljen mindig letöltenie... Tehát az 50mb max korlát legalább az adott munkamenet idejére vsz elegendő.

.htaccess:

# 480 weeks
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=290304000, public"
</FilesMatch>

Ezzel felülírod a headerben küldött cache szabályokat, a FilesMatch részhez neked más fog kelleni, ami megfelel a ize.hu/img.php?id=1 url-nek.

--
http://sandor.czettner.hu