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.
- 1444 megtekintés
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?
- A hozzászóláshoz be kell jelentkezni
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á...
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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
--
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Akkor nem voltam elég világos:
A felhasználóktól származó privát adatként kezelendő képről van szó, éppen ezért bármely URL (akármilyen bonyolult) szintű elérést szeretnék tiltani az arra nem jogosultaknak.
Ja és nem porno oldal ;)
- A hozzászóláshoz be kell jelentkezni
Akkor marad a php-n keresztüli kiszolgálás session alapján eldöntve a jogosultság kérdését.
Most már biztos hogy az... :)
Ja és cache-re egy lehetséges megoldás, bár IE-nél semmi sem biztos:
http://dtbaker.com.au/random-bits/how-to-cache-images-generated-by-php…
- A hozzászóláshoz be kell jelentkezni
Pusztán információelméleti szempontból egy bonyolult url-t mitől könnyebb kitalálni, mint a jelszót?
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
Honnan tudod a kofferem zárkombinációját?
- A hozzászóláshoz be kell jelentkezni
"Ilyen ostoba kombinációt még nem hallottam életemben! Egy hülye adna ilyen zárkombinációs számokat a csomagjának!"
- A hozzászóláshoz be kell jelentkezni
URL rewrite?
Egyébként miért érdekes annyira a cache? Átlag user úgy hagyja a browsert, ahogy van, nálam pl. 125 MB (fene tudja, hogy ez-e a default). Ez egy napi meló alatt simán lecserélődik. (5-6-szor :)
- A hozzászóláshoz be kell jelentkezni
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ő.
- A hozzászóláshoz be kell jelentkezni
Ha reloadolsz, lehet hogy a statikus képet is újratölti? Nem tudom, csak kérdezem.
- A hozzászóláshoz be kell jelentkezni
Nem, az nem tölti újra tapasztalataim szerint.
- A hozzászóláshoz be kell jelentkezni
A reloadnak pont az a lényege, hogy újratölti.
- A hozzászóláshoz be kell jelentkezni
Ez igaz. Bár akkor nem tom mire jó a shift+reload.
És minek töltsön újra nem megváltozott képeket? De talán pont ez a kettősség (inkább filozófiai kérdés) okozza a cache körüli nehézségeket.
- A hozzászóláshoz be kell jelentkezni
.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.
- A hozzászóláshoz be kell jelentkezni
Sajnos a FilesMatch csak valós filokra illeszkedik, de ha mod_rewrite-ben regexpet használok, akkor az a jó filenevet adja, mégis php-t hív meg, szóval ilyen szempontból jó, de mégis durcázik a cache.
- A hozzászóláshoz be kell jelentkezni
Esetleg php-ból elintézni a dolgot?
http://prog.hu/tudastar/113579-6/Cache-eles+kenyszeritese+header+proble…
- A hozzászóláshoz be kell jelentkezni
"Tehát az 50mb max korlát"
Milyen korlát?
- A hozzászóláshoz be kell jelentkezni
A user oldalon beállított (vagy default) cache limit. Lehet, h nem 50mega, de nekem az is elég.
- A hozzászóláshoz be kell jelentkezni