«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
Аноним 2019/08/08 17:39:50  №1450060 1
>>1447890

>>Так писать не стоит, это не keyword arguments из Питона и имена переменных не учитываются никак.
> А как понимать что за аргумент был передан?

Можно было бы добавить комментарий, но я думаю, лучше ничего не писать. Так как при рефакторинге ты можешь поменять имена аргументов, но забыть поменять комментарий и он начнет запутывать. Подсказывать должна IDE или переход к функции и просмотр ее заголовка глазами.

> Нужно тогда заранее определять переменные и передавать их?

Можно и так.

> Разве не нужно проверить что выдаются кукисы? Они ведь нужно для правильной работы приложения.

Можно проверить, что какая-то кука выдается, но ее наличие не равносильно авторизации, так как код может выдавать куку с некорректным значением, которая не пройдет проверку позже. Или это может быть кука для учета статистики, которая выдается всем подряд. А у тебя проверяется наличие 4 определенных кук. При изменении алгоритма авторизации, имен кук твои тесты сломаются. Потому я бы их вообще не проверял. То есть лучше не полагаться тут на знание механизма авторизации.

> Проверка авторизации выполняется тестом проверки доступа к разлогиниванию

Можно так, но я боюсь, что кто-то потом сделает этот метод доступным для всех и тест начнет врать.

>>Также, не надо копипастить огромные полотна кода, можно было сделать вспомогательную функцию для отправки запросов.
> Я как раз хотел спросить где хранить вспомогательные для тестов функции делать класс tests/Utils.php?
Можно сделать папку tests/Support/ или tests/Helper/

>>Соответственно тесты будут вида canLoginWithValidPassword, cannotLoginWithWrongPassword.
> Нужно разбить одну функцию на две?
Да, можно сделать два теста.

>>Далее, это ненадежный способ проверки, ведь речь тут о безопасности:
>>> if 'private.message.to.' in uri:
> Почему тот метод не надёжный?

Я немного ошибся, в данном случае уязвимости не возникает. Она бы могла возникнуть в таком случае:

if 'private.message.to.' in uri and is_anonymous:
return True

так как тут аноним мог бы получить доступ к методам вроде admin.view.private.message.to...

Потому лучше не использовать in вместо starts_with.

>>Микрооптимизация: регулярку можно скомпилировать один раз в начале скрипта и использовать скомпилированную версию.
> Зачем компилировать регулярку в начале скрипта?

Компиляция и разбор регулярки занимает крошечное, но время. Делая ее один раз в начале программы, мы экономим процессорное время. В PHP, например, есть кеш компилированных регулярок для оптимизации. Если ты вызовешь функцию preg_match() с одной регуляркой несколько раз, компиляция делается только один раз.

> М да, для группового чата так и нужно сделать. Вообще отправка 1000 уведомлений сделано, потому что, представим, пользователь очень популярен и каждый день получает 100 а может и 1000 новых сообщений от уникальных пользователей, и в итоге ему на всех нужно подписываться, что перенагрузит клиентское приложение. Гораздо лучше перенести эту нагрузку на серверную часть.

Да, тут надо подумать. Допустим, у нас есть 10 больших конференций, в каждой 1М пользователей:

- когда мы шлем уведомления каждому участнику, мы имеем 1М коннектов к wamp серверу и 1М подписок, а при обновлении в одной конференции шлем с PHP-приложения WAMP-демону 1М сообщений, которые он передает пользователям.
- когда мы используем свой канал обновлений для каждой конференции, мы имеем 1М коннектов и 10М подписок, а при обновлении в конференции PHP-код шлет единственное сообщение, которое демон разошлет 1М подписчиков

Но теперь представим, что из 1М участников онлайн только 100K:

- в первой схеме мы имеем 100k коннектов и 100k подписок, но при обновлении PHP-код по прежнему шлет 1М сообщений демону, так как PHP код не знает число подключенных пользователей
- во второй схеме PHP-код шлет одно сообщение демону, а тот рассылает его в 100K копий.

То есть, на мой взгляд, вторая схема работает лучше, позволяя убрать нагрузку с PHP-приложения. Конечно, нагрузка на демон получается неслабая, но он простой и легко масштабируется на несколько машин.

Есть еще вариант: поллинг. Для огромных чатов, клиент может периодически спрашивать у сервера про наличие обновлений в чате. Но это создает большую нагрузку на PHP код и базу, лучше наверно грузить WAMP-демон, он легко масштабируется, в отличие от базы.

Кстати, я как-то читал про протокол Телеграма, там сделано чуть интереснее. Там есть соединение с сервером, и клиент может слать API запросы (например: получить информацию о контакте, получить N сообщений из чата), и получать ответы. Но также сервер может слать клиенту уведомления по своей инициативе. Там нет явной подписки, так как сервер и так знает, какие у пользователя контакты и в каких группах он состоит. То есть по сути там пользователь, вступая в группу, автоматически подписывается на обновления в ней, и эта подписка не пропадает при отсоединении и переподсоединении. Аналогично сервер шлет информацию об обновлении информации в профиле контакта.

Но у Телеграма полностью самописный сервер.

> Только мне кажется что менять ключ не обязательно, потому что пользователь всё равно не сможет ни получить ни отправить сообщения, потому что API/WAMP его не авторизует для этого.

Речь о ситуации, когда пользователь авторизовался, вступил в чат, подписался на обновления в нем. Затем его выгоняют из чата, но авторизация на WAMP-сервере пройдена и подписка на обновления чата осталась.

> Да, об этой проблеме я уже осведомлён. Например, пользователь отсоединился на долгое время (несколько месяцев или год) и какой-то его собеседник или многие собеседники решили отредактировать или прочесть большое количество сообщений. И когда пользователь вновь откроет клиент, нужно обновить все эти сообщения. Очевидно, что нельзя подхватывать всё это большое количество сообщений сразу, и нужно подгружать их sequential, т.е. стримить.

Мне кажется, это не очень большая проблема. Сколько будет таких непрочтенных сообщений на практике? Ну тысячу, вряд ли больше. Тысячу записей можно легко передать в одном ответе API. Плюс, клиент может действовать по-умному, запрашивая обновления только когда пользователь попробует открыть чат.

> Да, это неудобно когда что-то редиректиться или выдается пустая страница.

Ну, этот редирект идет внутри JS-приложения и не виден пользователю. Под "пустой страницей" я имел в виду пустой чат с полем ввода сообщений.

> и если её ещё не существует, то мы просто не запрашиваем сообщения, а после отправки сообщения и её создания нас уведомит об этом WAMP и мы её реактивно подхватим.

Это на медленном соединении или в офлайне будет плохо работать: ты шлешь сообщение и оно появляется в диалоге с большой задержкой. Лучше было бы конечно локально его сохранить, отобразить, а затем пытаться отправлять в фоновом режиме.

>>Единственное, я не советую привязываться к текущей директории, чтобы ничего не ломалось, ...
> Текущая директория это какая?
Это та, что возвращается вызовом os.getcwd(), текущая директория процесса. В linux/win с каждым процессом связана "текущая" директория.

> Чтобы зашифровать голосовое/видео сообщение и сохранить его на сервер. Или не только сам контент сообщения, но и приложения к нему, например фотографию. Любая информация должна быть зашифрована.

Так можно делать это без сохранения в файл. Открываем исходный файл, читаем начало, шифруем, шлем на сервер. Берем следующий блок, шифруем, шлем на сервер. И так далее.

> Зашифрованные файлы весят больше?

Если мы отправляем файл с локального диска на сервер, то нам незачем создавать на диске зашифрованную копию этого же файла. Так как он у нас есть в расшифрованном виде.