[rvsky]

W jaki sposób rozwiązujecie chat albo wiadomości prywatne na #webdev?
Ja myślałem o rozwiązaniu że wszystko jest w bazie, ale co jeżeli zacznie brakować pamięci itp?
Jakiś pomysł?
#php #mysql #naukaprogramowania

[xDrope]

@rvsky: nosqlem ( ͡° ͜ʖ ͡°)

[rvsky]

nosql

@xDrope: tzn?

[fervi]

@rvsky: Przechowujemy nieszyfrowane w plikach txt :>

[rvsky]

@fervi: ( ͡°( ͡° ͜ʖ( ͡° ͜ʖ ͡°)ʖ ͡°) ͡°)

[fervi]

@rvsky: Myślałem o tym by tak robić. Najszybsza rzecz. Staram się jak najwięcej rzeczy przetrzymywać bo wiadomo - szybkie, tanie i przyjemne ( ͡° ͜ʖ ͡°)

[mk321]

wszystko jest w bazie

@rvsky: a jak inaczej? Jak chcesz, żeby było zapisywane (archiwizowane lub do odczytania później), to nie masz wyjścia. Jak nie potrzebujesz tego i może być na żywo, to wysyłaj bezpośrednio do użytkownika (w stylu P2P lub tylko pośredniczyć przez serwer).

ale co jeżeli zacznie brakować pamięci

@rvsky: tekst zajmuje mało. Musiałoby być masę użytkowników i ogromny ruch, żeby zająć kilka GB miejsca. Jakbyś miał taki ruch,

[mk321]

Przechowujemy nieszyfrowane w plikach txt :>

@fervi: proponuję te pliki trzymać w głębokim ukryciu na serwerze. Tzn. będą w publicznym serwerze w katalogu, którego tylko ty nazwę znasz. Aplikacja mobilna będzie pobierać te pliki, ale link będzie zaszyty w kodzie aplikacji tak, żeby nikt go nie zobaczył. ( ͡° ͜ʖ ͡°)

[fervi]

@mk321: Możliwości jest parę, pytanie czy bezpieczne. A gdybyś rozmowy przechowywał tak:

Plik PHP
php die; ?

Odpalenie pliku PHP powoduje wywalenie się kodu, a reszta chyba jest bezpieczna jak w bazie danych (czyli jakiś błąd to i tak wykradną)

[stash]

@fervi: Prościej trzymać takie pliki powyżej roota web aplikacji i wtedy nie trzeba robić takich podchodów.

[mk321]

@fervi: ta, a jak się parser PHP wywali (ale serwer HTTP nadal będzie działać), to zaserwuje cały plik do przeglądarki.

[fervi]

@stash: Oczywiście. Sposobów jest parę - pytanie czy pliki będą szybsze niż np. SQLite. W teorii bazy danych ogarniają się tak, by jak najszybciej chodzić. Z drugiej strony jeśli chcemy pobrać wszystkie rozmowy użytkownika X to musimy wszystkie rekordy przejechać, a w pliku oddzielnym może być szybciej.

[stash]

@fervi: SQLite to jest zwykła baza na plikach tylko z pewnym interfejsem. Jak ktoś poważnie podchodzi do tego tematu to i tak musi zrobić pośredni cache na czymś w stylu memcache/redis żeby nie zajechać IO dysków.

[stash]

ta, a jak się parser PHP wywali (ale serwer HTTP nadal będzie działać), to zaserwuje cały plik do przeglądarki.

@mk321: Nie będzie tak. Masz aplikację podpiętą pod domenę super-chat.pl pod ścieżką /var/www/super-chat/web/. Jak będzie trzymał swoje pliki w ścieżce /var/www/super-chat/rozmowy/ to nawet jak wysypie się interpreter PHPa to i tak nikt nie będzie mógł odczytać tych plików.

[plushy]

Odpalenie pliku PHP powoduje wywalenie się kodu, a reszta chyba jest bezpieczna jak w bazie danych (czyli jakiś błąd to i tak wykradną)

@fervi: A hasła trzymajmy w bazie danych niezaszyfrowane bo przecież baza danych ma hasło i obcy nie wejdzie. Nie mówię że twoje rozwiązanie jest mniej bezpieczne od przechowywanie tego w bazie danych jeśli dobrze zaimplementujesz ale jednak jest dziwaczne a przez to łatwiej że się coś spieprzy.

@

[mk321]

@stash: jeżeli będzie trzymał w katalogu poza ścieżką web to tak. Ale wtedy jaki sens miało by to php die; ? jak i tak nie byłoby dostępu z zewnątrz?

Tak kawałek kodu ma sens wtedy jak trzyma plik w katalogu web i nie chce, żeby dało się go podejrzeć z przeglądarki (i to zadziała dopóki PHP się nie wywali).

[rvsky]

@plushy gotowca tj?

[stash]

jeżeli będzie trzymał w katalogu poza ścieżką web to tak. Ale wtedy jaki sens miało by to php die; ? jak i tak nie byłoby dostępu z zewnątrz?

@mk321: To nie ja zaproponowałem takie rozwiązanie z trzymaniem rozmów.

[fervi]

@plushy: Wszystko jest kwestią teoretyczną. SQLite nie ma haseł, ale za to jest diabelnie szybki. Niektóre rzeczy trzymam w plikach PHP / TXT, gdyż np. nie mają znaczenia dla użytkownika.

Ale wtedy jaki sens miało by to php die; ? jak i tak nie byłoby dostępu z zewnątrz?

@mk321: Moim zdaniem nawet jak nie ma znaczenia większego to i tak warto. Linijka, która nie szkodzi (w teorii), a kij wie

[stash]

Linijka, która nie szkodzi (w teorii), a kij wie czy nie może pomóc. Hakierzy lubią wpisywać różne rzeczy w textbox

@fervi: Jeśli ta linijka ma być dodatkowym zabezpieczeniem przed atakiem na aplikację to już dużo wcześniej coś poszło mocno nie tak.

[fervi]

@stash: Jesteś tylko człowiekiem, nasze strony mają pewnie wiele podatności, bo czegoś zapomnieliśmy itd. A nie robimy stron dla urzędników RP, a często dla firm (ew. po prostu strony z wykorzystaniem komercyjnym) i jeśli takie małe gówienko może zapobiec kradzieży danych, to powinniśmy stosować. Oczywiście ten "znacznik" rzadko kiedy się przydaje, ale lepiej zapobiegać niż płacić bitcoiny ( ͡° ͜ʖ ͡°)