Diskuze: Povolení obrázků pro web se zákazem přímého odkazu
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Člen
Zobrazeno 21 zpráv z 21.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Ahoj, čeho se vlastně snažíš dosáhnout s těmi obrázky? Co znamená zákaz přímého odkazu a co povolení pro web?
Ne, to opravdu jednoduše nejde. Můžeš to vzdát. Pokud není obrázek
dostupný z adresní řádky, není dostupný ani z webu.
Pokud by to bylo klíčové, dá se to udělat třeba tak, že bys to zobrazoval
jako BLOB s klíčem, který jde použít jen jednou, ale potom se rozbije
cokoliv není první načtení stránky, prostě mnoho věcí. Ale nezapomeň,
že vždy může uživatel udělat screenshot.
Jestli se nesnažíš zobrazovat třeba nějaká umělecká díla, vykašlal
bych se na to.
Freedep:
Petr Čech:
Jednoduše, nebo vůbec? Ne, umělecká díla nemám, ale chci se pokusit
eliminovat podvádění (povědšinou prováděné pomocí google vyhledávání
obrázků), v poznávací hře.
Pvní nápad byl nějak blokovat cestu, aby google nemohl načíst obrázek z adresy (a to určitě nějak jde, z uživatelského pohledu jsem to už někde potkal), ale pokud by se povedlo to co jsem nastínil na začátku, byl bych radši.
Další možnosti co mě teď napadly, možná by šlo obrázek překrýt průhledným divem, aby bylo pro uživatele obtížnější zjistit cestu, nebo ho pomocí grafické knihovny z php vylepšit tak, aby ho google nepoznal. Screenshotu se samozřejmě nevyhnu.
priehladny div uzivatelovi nezabrani, aby si zobrazil zdrojovy kod stranky a nahliadol, kde je ulozeny dany obrazok...
a ako napisal Peter Cech, tak to, co chces, je velmi zlozite, lebo ked k danemu suboru (v tomto pripade k obrazku) nie je pouzitelny link, tak sa ti nenacita ani na webstranke
a navyse ani nikto nepouziva taketo praktiky, lebo implementacia je narocnejsia, nez vysledny efekt
Nikdy jsem to nedělal, je mi to tak trochu proti srsti, ale mělo by jít
ukládat obrázky přímo do DB, pak je ručním zadáním v adresním řádku
nezobrazíš...
tady něco takového řeší...
http://www.onlamp.com/…p_mysql.html
Jde o to, že jakmile to uživatelovi ukážeš, on si vždy cestu najde a ty s tím nemáš šanci cokoliv udělat. Existuje pár opatření, ale jak jsem již řekl, moc tomu nezabráníš:
Tak ono stačí mít obrázky někde ve skryté složce a vždy, když si uživatel vyžádá stránku, která obsahuje obrázky 1, 2 a 3, tak si uložit session, že teď k těm obrázkům má přístup. V praxi by to fungovalo tak, že když si načte patřičnou stránku, tak bude moct po nějakou malou dobu ty obrázky otevírat i z adresního řádku, ale kdyby to poslal kamarádovi, nebo by na to odkazoval odněkud jinud, tak nebude mít přístup. Myslím, že tak to řeší blog.cz, pak třeba můžeš vidět, že když obrázky hledáš přes google, tak se ti tam ukáže ta hláška "klikni zde pro plné rozlišení". To právě proto, že nemáš u nich nic uloženo, že jsi tu stránku navštívil...
To se často řeší tak, že dají pro náhled obrázek jen v menším rozlišení a taky do něj ještě vloží nějaký vodotisk.
Proc neudelas v htaccess jednoduchou podminku na referrer? Pak budou obrazky na webu, ale prime linky nepojednou
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?povolenadomena\.cz [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?dalsipovolenadomena\.cz [NC]
RewriteRule \.(gif|png|jpe?g|js|css)$ - [F,NC,L]
Jiří Fencl:
zkusil jsem
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(anime\.|dorama\.|manga\.|neanime\.|postavy\.|odpocet\.|faq\.|hadej\.|j-music\.)mujportal\.cz [NC]
RewriteRule \.(gif|png|jpe?g|js|css)$ - [F,NC,L]
a pak pro jistotu i
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://anime\.mujportal\.cz [NC]
RewriteCond %{HTTP_REFERER} !^http://dorama\.mujportal\.cz [NC]
...
RewriteRule \.(gif|png|jpe?g|js|css)$ - [F,NC,L]
s těmito výsledky:
přesto chci věřit, že to nejakým podobným způsobem půjde
Zkus jeste procist dokumentaci promo od apache a zkusit uvozovkovat - me to jde i bez nich, ale nepises nic o konfiguraci serveru
Dobře, mám pocit, že vám uniká,, jak fungují prohlížeče, komunikace klient/server a co všechno může klient, proto se pokusím vnést trochu světla do toho, proč to není nic jednoduchého.
Ze všech předcházejících důvodů vyplývá, že to nejde nikdy udělat
100% a určitě ne pomocí klasických obrázků (<img>).
Dá se udělat něco, co jsem psal předtím, ale vždy to půjde obejít.
plny suhlas s tymi dovodmi...
server ozaj nedokaze rozlisit, ci dany obrazok bol nacitany bud cez stranku,
alebo iba pomocou URL odkazu, o tom rozhoduje jedine klient, cize ani .htaccess
tu nebude fungovat a zaroven .htaccess je specialitkou servera Apache, ine
webservery nemusia pouzivat tento subor a navyse moze byt v konfiguracii aj
vypnuta podpora tohto suboru,..
Ok.
Server jede na debianu a .httaccess soubory běžně používáme, takže v tom
problém nevidím.
Vím že všemu nezabráním - sám mám linux a takové Shift + PrintScreen
prostě neobejdu.
Na drubou stranu nevidím důvod proč bych to neměl zkusit uživatelům
ztížit.
Asi nejde požadovat od prohlížeče aby cashe neuchovával, že?
Tohle tema mam rad.
Chapu to spravne, ze ty ty obrazky poskytujes i jinym webum pro zobrazeni? Nebo
to jsou tvoje weby, ty portaly o kterych mluvis?
Libi se mi kam miri Petr Cech. Prijde mi ze jasne vystihuje podstatu
problemu.
Hodne komplexne kanonem na komara se to da resit i takhle:
Obrazky nacitas javascriptovou funkci, ktera zasle jmeno souboru na tvuj
backend, ten vytvori jedinecny endpoint s omezenou platnosti (casove nebo poctem
nacteni), kde vystavi budto obrazek, nebo treba jen obrazek v base64 nebo necem
takovym, nebo jako binarni data. JSkova funkce dostane zpet to url a stahne
obrazek. Tim by sis osetril to, ze proste kouknou do zdrojaku a copy pastnou url
obrazku do google images.
Kdyz to udelas v kombinaci s canvasem, tak nepujde ani obrazek ulozit na lokalu a uploadnout na google images rucne.
Screenshot neosefis, bohuzel. ALE mohl bys, kdybys trosku ustoupil pohodlnosti. Trochu jsem patral a zjistil jsem, ze snapchat resil screenshotovani tak, ze na iOSu screenshot vyvolava zruseni vsech touch eventu, takze oni vynutili aby se user dotykal screenu nebo tak neco. A kdybys to udelal stejne. Pises ze je to hra. Tak by to tolik vadit nemuselo, kdyz to das jako soucast game UX. Sleduj, das JSkovou funkci, ktera zobrazi cernej obdelnik, samozrejme se uz bude na pozadi stahovat ten obrazek ze serveru a tak zejo. Ale jakmile user bude chtit zobrazit obrazek, musi na nej kliknout a drzet mys stisknutou. Tim nemuze porizovat screenshot mysi, ale muze klavesnici, bohuzel nejde ani odchytit stisk klavesy printscreen.
[tohle ber jen jako joke]
ALE napadlo me jeste neco, kdybys udelal to, ze JSkem budes problikavat obrazek
a cernou obrazovku hodne casto, je celkem slusna sance, ze kdyz user udela
printscreen, sem tam se mu objevi prazdne misto (https://jsfiddle.net/…ll/rqzjy45p/) - akorat asi bude
problem s epeleptikama.
[konec joke]
Takze kdyz pouzijes to rozumne co jsem napsal ja a Petr Cech, v podstate bys mel odfiltrovat masivni vetsinu pokusu o obejiti problemu.
Tohle se bohužel na straně serveru asi nevyřeší. Ve chvíli kdy má uživatel obrázek zobrazený v prohlížeči je už mimo kontrolu, přesně jak psal Petr Čech.
Pokud se jedná o poznávací hru a chceš to ztížit hráčům, můžeš omezit čas na odpověď, generovat náhodnou sadu obrázků/otázek, zakázat right click a podobně. Ale počítej s tím, že pokud uživatel bude chtít tak si cestu najde.
Myslím, že vodoznakem a pro stažení generují náhodnou url.
Taskkill:
doménu (je jen jedna) má kompletně na starosti kamarád, včetně instalace
serveru
já mám přístup k ftp a mohu měnit scripty a .httaccess
portály jsou vytvořené z vybraných složek v kořenovém adresáři právě
pomocí .httaccess, a všechny jsou moje
Myslím si, že v tomhle případě, je asi nejlepší řešení blob.
Zobrazeno 21 zpráv z 21.