GoldenLine
Zaloguj się
Maciej Filipiak

Maciej Filipiak właściciel, VizMedia

Temat: pliki na hasło

Witam

Mam problem, parę niezgrabnych pomysłów na jego obejście, ale szukam najbardziej profesjonalnego podejścia do stworzenia sklepu plików.

Zadanie:
Jak w temacie, plik, jako towar nabyty. Klient płaci za możliwość pobrania pliku.

Problem:
Jaką wykorzystać technologię, żeby zachować maksimum bezpieczeństwa.
Plików jest dużo, pobrać można tylko te, za które się zapłaci.

Aplikacja sklepu ma działać na kontach deweloperskich, więc raczej tworzenie dynamicznie kont FTP nie wchodzi w rachubę. Dostęp do shella ewentualnie tak, ale ograniczony.
Operacji zakupu i pobrań spodziewam się b. dużo, więc musi to być w pełni automat.
W tej chwili aplikacja tworzona jest w oparciu o Zend Framework.

Jeżeli macie w tej kwestii jakieś doświadczenie, bardzo proszę o podsunięcie pomysłu.
Link do wypowiedziLink
Mirosław O.

Mirosław O. netBOMB.pl

Temat: pliki na hasło

przenieś download o poziom wyżej czyli poza 'wykonywalne www' i steruj tym co i komu pozwalasz pobrać.
Link do wypowiedziLink
Maciej Filipiak

Maciej Filipiak właściciel, VizMedia

Temat: pliki na hasło

Mirosław O.:
przenieś download o poziom wyżej czyli poza 'wykonywalne www' i steruj tym co i komu pozwalasz pobrać.


tak, to jest właśnie ta "nie elegancka" opcja, którą miałem na myśli.

pliki są na innym dysku - za pomocą php mogę je ściągnąć do widocznego na www katalogu i udostępnić na czas pobierania.

Tylko że to generuje 3 krotnie większy ruch na dysku, chciałem tego uniknąć.

chyba, ze coś innego masz na myśli...
Link do wypowiedziLink
Mirosław O.

Mirosław O. netBOMB.pl

Temat: pliki na hasło

co w niej jest nieeleganckiego?
Link do wypowiedziLink
Michał Ścioch

Michał Ścioch 6ka Sp. z o.o.,
prezes zarządu

Temat: pliki na hasło

Dobrze Ci przedmówca radzi - zbuduj w PHP pośrednią warstwę (klasę, zestaw klas, moduł czy co tam Ci pasuje do frameworka) która całkowicie odseparuje użytkowników od fizycznych plików na dysku. Wtedy nie ma znaczenia gdzie te pliki leżą, byleby tylko kod PHP miał do nich dostęp. A użytkownik dostanie tylko binarny strumień wysłany do przeglądarki, opatrzony odpowiednim nagłówkiem mime-type, żeby przeglądarką wiedziała co ma z tym zrobić.

Bo nieeleganckie (i przed wszystkim mało bezpieczne) to są właśnie jakieś wynalazki z dynamicznym ftp czy udostępnianie fizycznych katalogów na serwerze przez http.
Link do wypowiedziLink
Tomasz Wójcik

Tomasz Wójcik inżynier informatyk,
specjalizacja: sieci
komputerowe

Temat: pliki na hasło

Wyrzucenie plików poza public_html po to żeby nie można ich było bezpośrednio zlinkować, ale można też .htaccess i "deny from all"

Nieeleganckie, bo pliki masz w różnych miejscach na serwerze zamist np. jednego kataloguTomasz Wójcik edytował(a) ten post dnia 18.12.07 o godzinie 22:37
Link do wypowiedziLink
Mirosław O.

Mirosław O. netBOMB.pl

Temat: pliki na hasło

Tomasz Wójcik:
Nieeleganckie, bo pliki masz w różnych miejscach na serwerze zamist np. jednego katalogu

Jeżeli to twój serwer (tudzież masz odpowiednie możliwości) to nic nie stoi na przeszkodzie aby ustalić sobie taka strukturę katalogów na jaką ma się ochotę. Zabawy z htaccess to ZAWSZE jakieś ryzyko ;)
Link do wypowiedziLink
Andrzej Zawadka

Andrzej Zawadka
Projektant/Programis
ta

Temat: pliki na hasło

Jeśli bardzo nie chcesz skorzystać z powyższego który notabene też uważam za dobry to może coś takiego. Mianowicie podczas uploadowania pliku na serwer zmieniasz jego nazwę na unikatową i wystarczająco skomplikowaną i wrzucasz do katalogu dostępnego przez serwer WWW. Oczywiście warto wyłączyć listowanie tego katalogu przez powyższy serwer. Następnie do bazy danych zapisujesz sobie listę odpowiedników "właściwa nazwa<=>unikatowa nazwa" i na podstawie tej listy udostępniasz klientom strumień danych z właściwie ustawionymi nagłówkami "Content-Type" i "Content-Disposition"
Link do wypowiedziLink
Maciej Filipiak

Maciej Filipiak właściciel, VizMedia

Temat: pliki na hasło

podoba mi się pomysł z nagłówkiem mime, muszę trochę doczytać, bo jeszcze tego nie robiłem.

A co myślicie o trzymaniu dużej ilości plików bezpośrednio w mysql ?

doświadczenie mam jedynie z m$-sql, nie ma co porównywać,
czy mysql wytrzyma ? czy lepiej nie ?
Link do wypowiedziLink
Michał Ścioch

Michał Ścioch 6ka Sp. z o.o.,
prezes zarządu

Temat: pliki na hasło

Maciej Filipiak:
A co myślicie o trzymaniu dużej ilości plików bezpośrednio w mysql ?

IMHO bez sensu, bo jaka z tego korzyść? Raczej dodatkowe problemy.
Link do wypowiedziLink
Filip Lynx Adamczyk

Filip Lynx Adamczyk Programista
PHP/Javascript

Temat: pliki na hasło

Michał Ścioch:
Maciej Filipiak:
A co myślicie o trzymaniu dużej ilości plików bezpośrednio w mysql ?

IMHO bez sensu, bo jaka z tego korzyść? Raczej dodatkowe problemy.
Dokładnie, był już tu nawet o tym temat, w zasadzie nie ma z tego żadnych korzyści, tylko same problemy. Wysyłanie strumienia danych to chyba najlepszy pomysł.

Pozdrawiam.
Link do wypowiedziLink

konto usunięte

Temat: pliki na hasło

Jeżeli są to pliki do pobrania, to najłatwiej mime...

Trzeba tylko naprawdę dobrze ustawić mime (dla różnych przeglądarek i nie tylko), bo inaczej może być problem z download managerami i choćby z Safari.

Jeżeli miałyby służyć do streamingu, to warto pomyśleć o innych rozwiązaniach, bo rozwiązanie to nie pozwala np. odczytać konkretnego miejsca w pliku (np. ostatnich kilku bajtów bez ściągnięcia całości) i mogą występować przekłamania na mp3 we flash'u. Format flv całkiem dobrze działa, ale już bajerek taki, jak w YouTube - oglądanie filmu od dowolnego miejsca bez ładowania początku - bez pewnych modyfikacji jest prawie niemożliwe.

Jakimś pomysłem jest też wykorzystanie tworzonego dynamicznie mod-rewrite i dodawanie linii z przekierowaniem do konkretnego pliku na czas ściągania ;)
Link do wypowiedziLink
Andrzej Zawadka

Andrzej Zawadka
Projektant/Programis
ta

Temat: pliki na hasło

Sławomir Łukjanow:
Jeżeli są to pliki do pobrania, to najłatwiej mime...

Trzeba tylko naprawdę dobrze ustawić mime (dla różnych przeglądarek i nie tylko), bo inaczej może być problem z download managerami i choćby z Safari.

Jeżeli miałyby służyć do streamingu, to warto pomyśleć o innych rozwiązaniach, bo rozwiązanie to nie pozwala np. odczytać konkretnego miejsca w pliku (np. ostatnich kilku bajtów bez ściągnięcia całości) i mogą występować przekłamania na mp3 we flash'u. Format flv całkiem dobrze działa, ale już bajerek taki, jak w YouTube - oglądanie filmu od dowolnego miejsca bez ładowania początku - bez pewnych modyfikacji jest prawie niemożliwe.

Jakimś pomysłem jest też wykorzystanie tworzonego dynamicznie mod-rewrite i dodawanie linii z przekierowaniem do konkretnego pliku na czas ściągania ;)

Czy pisząc o innym sposobie strumieniowania miałeś np. na myśli "chunked encoding" ("Transfer-Encoding: chunked") gdzie nie podaje się danych jako jeden kawałek tylko sieka na pakiety podając na początku każdego pakietu długość danych danego kawałka a każdy kawałek jest zakończony CRLF. Daje to ciekawe możliwości, ostatnio zainteresował mnie ten temat, ale ponieważ do mojego rozwiązania wystarczył zwykły strumień gdzie znałem wielkość danych więc mogłem od razu ustawić "Content-Length" dlatego nie kontynuowałem badań. Fajnie było by zrozumieć jak są dane przesyłane w formatach używanych przez YouTube lub RealPlayera itp. Jeśli masz na to jakieś materiały lub linki to proszę podziel się z ogółem.
Link do wypowiedziLink
Maciej Filipiak

Maciej Filipiak właściciel, VizMedia

Temat: pliki na hasło

o tak, wszelkie linki mile widziane :)
Link do wypowiedziLink

konto usunięte

Temat: pliki na hasło

Prawda jest taka, że jako zespół właśnie analizowaliśmy różne rozwiązania (m.in. cięcie na małe bloki danych). Ze względu na zbyt wolne przetwarzanie i ograniczenia PHP już jakiś czas temu odrzuciliśmy go jako rozwiązanie docelowe. W tym momencie jeszcze go wykorzystujemy, ale pracujemy nad tym, żeby to zmienić. Myśleliśmy też nad napisaniem własnego daemona na serwerze (wzorując się na działających rozwiązaniach) i własną obsługę po stronie Flash'a. To jednak kosztowałoby zbyt dużo czasu i pieniędzy.

Oczywiście możemy długo się zastanawiać, jak to zrobił YouTube, ale jeżeli ktoś nie zna ich rozwiązań od środka, to będzie to tylko wróżenie z fusów.

My pracujemy nad własnymi modułami do Apache'a i Lighttpd, które będą się tylko komunikowały z PHP (w celu uzyskania odpowiedniego parametru sesji) i na zasadzie zwracanych parametrów dawały dostęp do konkretnego pliku (lub nie) na porcie 80 (w dodatkowej domenie). Uznaliśmy to rozwiązanie za najlepsze, bo obsługa plików serwerów WWW jest już dopracowana, a dopisanie dodatkowego modułu stosunkowo proste.

W ogóle brakuje nam programistów PHP (jeżeli jest ktoś zainteresowany - pełen etat, Gdańsk, to proszę o PM), więc wszyscy, którzy mogliby się zająć tymi dodatkowymi modułami są oddelegowanie do pisania w PHP i sprawa modułów stoi.

Sam chętnie poczytam tutaj o innych sposobach rozwiązania tego problemu.

Pozdrawiam Wszystkich i życzę Wesołych Świąt :)
Link do wypowiedziLink
Andrzej Zawadka

Andrzej Zawadka
Projektant/Programis
ta

Temat: pliki na hasło

Ciekawe rzeczy robicie, ja już trochę mam dosyć kolejnych tabelek, zapytań SQL, formatek "Usun/Edytuj/Dodaj" brrr, ale co zrobić jeść trzeba.
Masz rację że podawanie danych strumieniowych przez PHP na pewno nie jest optymalnym rozwiązaniem i specjalizowany serwer będzie wydajniejszy. Robiłem kiedyś takie rozwiązanie do centralizacji danych w rozproszonym systemie bazodanowym starego typu nie posiadającego najnowszych bajerów (replikacja itp.) To był taki typowy klient/serwer oparty na gniazdach i protokole strumieniowym TCP. Nadmienię tylko że pomimo zastosowania bardzo oszczędnego protokołu komunikacji (dane pocięte w pakiety), nie udało się uzyskać takiej wydajności w przesyłaniu danych jaką miał np. popularny serwer FTP. W tym akurat rozwiązaniu nie miało to aż takiego znaczenia ale w systemach strumieniowej transmisji dźwięku i obrazu każde opóźnienie może wpłynąć na poziom zrozumienia przekazu, naprawdę ciekawe jak oni to robią że to tak nieźle działa np. w Skype, pewno jeszcze jest tam jakaś kompresja, plus inteligentne buforowanie danych.
Sławomir Łukjanow:
Prawda jest taka, że jako zespół właśnie analizowaliśmy różne rozwiązania (m.in. cięcie na małe bloki danych). Ze względu na zbyt wolne przetwarzanie i ograniczenia PHP już jakiś czas temu odrzuciliśmy go jako rozwiązanie docelowe. W tym momencie jeszcze go wykorzystujemy, ale pracujemy nad tym, żeby to zmienić. Myśleliśmy też nad napisaniem własnego daemona na serwerze (wzorując się na działających rozwiązaniach) i własną obsługę po stronie Flash'a. To jednak kosztowałoby zbyt dużo czasu i pieniędzy.

Oczywiście możemy długo się zastanawiać, jak to zrobił YouTube, ale jeżeli ktoś nie zna ich rozwiązań od środka, to będzie to tylko wróżenie z fusów.

My pracujemy nad własnymi modułami do Apache'a i Lighttpd, które będą się tylko komunikowały z PHP (w celu uzyskania odpowiedniego parametru sesji) i na zasadzie zwracanych parametrów dawały dostęp do konkretnego pliku (lub nie) na porcie 80 (w dodatkowej domenie). Uznaliśmy to rozwiązanie za najlepsze, bo obsługa plików serwerów WWW jest już dopracowana, a dopisanie dodatkowego modułu stosunkowo proste.

W ogóle brakuje nam programistów PHP (jeżeli jest ktoś zainteresowany - pełen etat, Gdańsk, to proszę o PM), więc wszyscy, którzy mogliby się zająć tymi dodatkowymi modułami są oddelegowanie do pisania w PHP i sprawa modułów stoi.

Sam chętnie poczytam tutaj o innych sposobach rozwiązania tego problemu.

Pozdrawiam Wszystkich i życzę Wesołych Świąt :)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Opcja przypomnij hasło




Wyślij zaproszenie do
Anuluj