Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
1) Скорость загрузки не более 0,1 сек
4) Ежедневные отчёты . в день минимум 3 Pusha
Сайт должен быть полностью самописным , разработан безупречно
У всех свой стиль ведения дел, но я просто хочу обратить внимание на слишком сильный акцент на внешней стороне дела, что может вызвать у исполнителя симметричный ответ в виде формального подхода - "0.1 сек есть, 3 пуша есть, ну а что функции не работают так про это ничего и не писали"
Скорость загрузки, действительно, не всегда зависит от разработчика. Может это интеграция с сервисом в далеком забугорье, может очень хитрый фильтр на миллионе записей. Без четкого описания среды ("фильтров 2, такого-то типа, записей не более 100, до БД пинг 1 мс") такие требования выглядят, как микроменеджмент.
Push'ы - тут еще интереснее, это из разряда "требовалось не менее 100 000 строк кода, мы добили разницу цитатами из Пушкина". Редко бывает задача, которую разбить на несколько коммитов ну никак нельзя. Иногда бывает, что целый день (а то и несколько) копаешь-копаешь в поисках непонятного бага, а кода - нет. Потом один коммит с исправлением на одной строчке, за которым десятки часов поисков. И за это вы будете штрафовать? Или будете требовать отчетов?
А "самописный" - это даже не технический термин, формально я написал вызов Eloquent - и это уже мой, "самописный", код, так что вовсе не ясно, что подразумевается под этим словом.
В общем, я посоветовал бы найти отличного спеца и оставить всю техническую часть на его совести, тем более вы, видимо, не видите разницы между push и commit, то есть у вас нет хорошего технического background'а, и если будете пытаться таким спецом рулить (всякие там "митапы" и "созвоны") - он или уйдет, или будет "сидеть на з/п", в итоге у вас в любом случае проект не выгодит.
У вас смешалось все в кучу.
Во-первых, вы пишете данные в формате .csv (comma-separated values), а не .xls или .xlsx (это именно родные Excel-форматы, не CSV). Поэтому давайте имени файла расширение .csv.
Во-вторых, Excel (по крайней мере старые версии точно, старее 2015 или около того) читает CSV только в кодировке ОС, т.е. на русской Windows это CP1251 (как вы правильно заметили). Но! У CP1251 не может быть префикса BOM (EF BB BF) - это признак файла в кодировке UTF-8. Нельзя один файл кодировать одновременно как UTF-8 и CP1251. BOM в вашем случае нужно убрать, оставить только mb_convert_encoding().
Наконец, при записи данных полезно их оборачивать в кавычки, чтобы в результате было не имя;фамилия, а "имя";"фамилия" - это защитит их, если в значении будут спецсимволы. Хотя в вашем случае это точно не главная проблема, а проблема в расширении файла и кодировке.
хотя везде пишут что это проблема и нужны библиотеки специальные
Все правильно, пишут как раз про .xls/.xlsx, которые закрытые бинарные форматы от MS.
$text = '';
foreach ($arrayData as $key => $value) {
$text .= "\"$value\";\"$key\"\r\n"; // <<<
}
$files = fopen($_SERVER['DOCUMENT_ROOT']."/file_text.csv","w+b"); // <<<
//fwrite($files, "\xEF\xBB\xBF"); // <<<
$text = mb_convert_encoding($text,"windows-1251");
fwrite($files, $text);
fclose ($files);Anatolii
Просьба не создавать дубликаты тем, а поднимать существующие.
Я на Laravel не писал уже много лет, так что о нем конкретно говорить не могу, но вообще, когда читаю статьи про фреймворки, ощущение, что народ 90% рабочего времени пишет модели, формы и классы (или печатает со скоростью 10 знаков в минуту), и поэтому кодогенераторы и магические dependency injection (и другие injection, вроде свойств в Eloquent) приносят такое невероятное облегчение и хайп. Особенно меня вымораживают кодо-комментарии (@dataSource и пр.) — ладно там в юнит-тестах, но в основном коде, это ж маразм, основывать логику на комментариях!
В моей работе как-то все наоборот. Да, есть модели (сильное название — класс со свойствами), но вообще не вижу никаких проблем от руки написать такой класс на каждую таблицу (даже если их 20-30 штук). Это делается даже «не приходя в сознание». И не ломаешь голову, откуда пришло то или иное свойство. Явное лучше скрытого. С методами аналогично — руки не отсохнут написать, что первый аргумент это User $user. На такие рутинные операции тратится может 5% времени. Остальные 95% — никакой фреймворк не облегчит, потому что это собственно и есть бизнес-логика, где требуется продумывание и планирование и только потом код.
А вот шаблонизаторы, если они легкие и прозрачные, сильно облегчают жизнь — писать HTML на голом PHP не продуктивно. ORM — если очень-очень легкая, то имеет место быть для всяких User::find(123), однако обязательно должен быть и прямой доступ к SQL (в виде подготовленных запросов), иначе придется переписывать пятиэтажные (JOIN) запросы с WHERE, HAVING, ORDER BY и LIMIT из человекочитаемого SQL в человеконечитаемые вызовы методов. ORM такие запросы эффективно сгенерировать вряд ли сможет, да и будешь уверен, что после очередного обновления и изменения внутренней логики ORM твой запрос не стал в 10 раз медленнее, потому что она его поняла как-то не так. Отлаживать удобнее, опять же.
Нужно смириться, что код писать придется так или иначе, и что «удобства» добавляют огромное число неконтролируемого тобой кода, который ни отладить (из-за объема и из-за магии), ни понять.
Вместо фреймворков, ИМХО, лучше тянуть (качественные) пакеты, потому что они не навязывают способ работы и воспринимаются как черный ящик — вызывай вот это вот так-то для получения такого-то результата и больше ни о чем не думай. Их можно воспринимать как стандартные функции PHP. Ирония в том, что пакеты как раз стараются писать без привязки к фреймворкам…
Как решить эту ошибку используя php 7.1 ?
Разобраться, почему в переменной не тот формат данных, который нужен. Скорее всего там, как и написано, не число, а временное представление типа "2019-06-01T...". Можно попробовать их посмотреть через отладчик, а не через dd(), или через var_dump(). Еще можно отключить error_reporting() для E_WARNING и/или E_NOTICE, но это очень плохой путь - разве что для отладки.
Но делаю диплом и в комиссии сказали если у тебя логины уникальные то пусть он используеца как идентификатор.
Не троллинга ради, но если у нас готовят ИТ вот с таким подходом - это просто тушите свет... Надо понимать, что члены комиссии никогда не участвовали в реальной разработке. У меня даже нет слов это прокомментировать, одни эмоции.
С формальной точки зрения делать логин первичным ключом верно, но это настолько против всех устоявшихся практик, что действительно, разве что в дипломе такой подход и увидишь. Причем причин-то менять практики нет - мало ли, логин будет перемещен в другую таблицу, да и вообще, с числовым ключом работать намного проще и быстрее (часто строка требует преобразования в число для использования в индексе). А если логин будет изменен (некоторые форумы, к примеру, это позволяют) - это повлечет за собой изменение его во всех связанных таблицах. И это только то что сразу приходит на ум.
Делать ПК на "обычных" данных хорошо разве что в pivot-таблицах, где поле с автоинкрементом совершенно излишне.
Первое: перечисление типа 5,6,7,10,15,16,17,21,29 преобразовать в 5-7,10,15-17,21,29
<?php
$s = '5,6,7,10,15,16,17,21,29';
$a = [];
$prev = $start = null;
foreach (json_decode("[$s,0]") as $n) {
if ($n - 1 !== $prev) {
$start === null or $a[] = $start === $prev ? $start : "$start-$prev";
$start = $n;
}
$prev = $n;
}
echo join(',', $a);Второе: перечисление типа 5-7,10,15-17,21,29 преобразовать в 5,6,7,10,15,16,17,21,29
<?php
$s = '5-7,10,15-17,21,29';
$a = [];
foreach (explode(',', $s) as $pair) {
list($start, $end) = explode('-', $pair) + ['', ''];
$end === '' and $end = $start;
while ($start <= $end) { $a[] = $start++; }
}
echo join(',', $a);А как установить swap постоянно ?
Дописать в /etc/fstab:
/swapfile none swap defaults 0 0Но как только пытаюсь уточнить поле даты, оно сразу меняется.
Что понимается под "уточнить"?
Внешние ключи именно для того и придуманы, чтобы их нельзя было просто обойти - они нужны для сохранения целостности базы. Если задача такая, что внешний ключ мешает - то что-то не то в самой задаче.
Например, если у тебя ключ на каком-то id (в другой таблице), то перед изменением записи надо создать запись в той второй таблице, чтобы такой id действительно существовал, тогда внешний ключ не будет "мешать".
Информации слишком мало, чтобы дать более точный ответ.
Затем , если страницу не трогать несколько минут и сделать Refresh опять тормоза .
Если это не какое-то внутреннее кэширование Laravel, то похоже на встроенный opcache в PHP, который кэширует (предкомпилирует) скрипты в памяти вместо загрузки каждый раз с диска, что очень сильно ускоряет работу проектов с кучей скриптов (как то Laravel, форумы, вики-движки и т.д.).
По умолчанию opcache не "протухает", но, возможно, на вашем сервере настройки нестандартные или памяти слишком мало - см. php.ini, группу [opcache]. Там много полезных переменных - максимальное число файлов, используемая память, время обновления и т.д.
garrip91
Тема закрыта. Я вам писал, почему. За повторный пост такого же характера будет бан - первый на этом форуме за все 7 лет его истории.
[pool www] child 9221 exited on signal 11 (SIGSEGV - core dumped) after 1506.246210 seconds from start
А точно та ошибка? "after 1506.246210 seconds" говорит, что скрипт висел 25 минут, прежде чем упал, а вы писали: "При этом, если обновить страницу, то страница корректно отображается." - 25 минут точно ждали?
Есть сведения, что сегфолт можно вызвать зациклившейся регуляркой, например.
Это надо очень-очень постараться. Возможно, в системе несовместимые библиотеки, PHP был собран не на тех, которые есть сейчас. Лучше попробовать все удалить (со всеми зависимостями), обновить apt/yum/что там у вас, и поставить заново из пакетов.
На одном проекте хорошо разобрался и реализовал FullText (мускл 5.7 InnoDB) и в итоге при размере БД в 6КК строк в основном в трех таблицах (1гиг с индексами), ищет почти мгновенно.
У меня в одном проекте с ~5 млн строк (в одной таблице) поначалу тоже был FULLTEXT-индекс от MySQL, но, видимо, у нас разная структура данных и/или поиска. У меня каждый документ это где-то 50 индексируемых слов, а каждый запрос может содержать десяток слов в разной конфигурации (т.е. с операторами). На MySQL в какой-то момент времени поиск стал занимать секунды, перешел на Sphinx - поиск сократился до долей секунды (на 2 порядка).
Еще большой плюс Sphinx (либо отдельной системы хранения вроде Redis только для поиска) в том, что добавлять/обновлять данные в огромной таблице с FULLTEXT под нагрузкой нереально. У меня импорт 100к записей, если не отключать сайт, занимал часы, при этом хоть сайт и был скорее жив, чем мертв (для пользователей), но все жутко тормозило из-за параллельного обновления индекса. А Sphinx - это отдельная надстройка, он может легко обновляться частично и/или на лету без особых проблем с производительностью.
Минус только в том, что изначально связку Sphinx и MySQL нужно настроить, но зато дальше полет нормальный.
хочу спросить кто какие плагины использовал для Laravel 5
Насчет плагинов ничего не могу сказать (проект не на Laravel), но зачем они нужны, если у Sphinx такой же интерфейс, что и у MySQL?
<?php
$persons = [
'name'=>[
0=> 'Vasya',
1=>'Petya',
2=>'Kolya'
],
'street' =>[
0=>'Lenina',
1=>'Marksa',
2=>'Engelsa'
]
];
// ----
$elegant = array_map(function ($name, $street) {
return compact('name', 'street');
}, $persons['name'], $persons['street']);
// ----
var_dump($elegant);Так на https://laracasts.com нет субтитров. Или они появляются, когда покупаешь подписку?
Честно говоря уже не помню, возможно ты прав. Но если там нет английских субтитров - значит нигде нет.
Хотел бы спросить, как можно просматривать курсы от Laracast с английскими субтитрами?
Купить подписку на laracasts.com и смотреть там.
Заказчик хочет получить веб-программиста и аудит безопасности в одном флаконе? При разницы з/п у обоих примерно в 20 раз...
но на будущее хочется всё-таки собрать инфу по безопасности.
Это не то, что можно просто "собрать" и вызубрить. Нужно понимать работу всех компонентов, в том числе нижележащих - PHP, веб-сервера, протоколов. Я на пару пунктов отвечу для интереса, но это только вершина айсберга.
Проверка на удаленное выполнение произвольного кода;
Если не использовать eval($_GET['x']); то RCE в PHP получить не получится, к счастью.
Проверка на наличие инъекций (внедрение кода);
Внедрение кода в SQL?..
В любом случае, если использовать ORM, то шанс получить инъекцию очень мал, но остается, ведь "сырые" выражения никуда не деваются. Правда, некоторые любят использовать целые сырые запросы в сложных случаях, когда ORM снижает читабельность - тогда риск больше.
Проверка веб-ресурса на наличие «XSS» / «CSRF» уязвимостей;
Странно, что две совершенно разные проблемы объединены в один пункт.
XSS - когда в шаблоне нет экранирования пользовательского ввода (который может прийти не только напрямую из GET/POST, но и косвенно через БД, к примеру). Тогда можно вставить свой код на страницу, утащить cookie с сессией и другие пользовательские данные, вроде кредиток.
XSS бывают отраженной и хранимой, об этом писать не буду.
CSRF - возможность выполнить действие "за" пользователя без его явного согласия. Например, есть маршрут вида "GET //my.site/delete/account". Кто-то авторизовался на вашем сайте, перешел на "вредоносный" ресурс, где стоит картинка с этим URL: <img src=".../delete/account">. Результат - браузер запросил картинку, это вызвало удаление аккаунта.
Решается добавлением скрытого token к подобным маршрутам: //my.site/delete/account?csrf=token. Вредоносный сайт token знать не будет, поэтому запрос на удаление будет отклонен.
Внедрение XML-сущностей;
Еще более странно, что этот класс отдельно от XSS. По сути то же самое, только вставка своего ввода не в HTML, а в XML. На большинстве сайтов XML нет, RSS, к сожалению, умер, поэтому про это можно не думать.
Попытки произвести Remote File Inclusion / Local File Inclusion;
Это, к счастью, вымерло окончательно благодаря автозагрузке классов.
require $_GET['lang'].'.php';
RFI - когда lang=http://my.site/inc.php
LFI - когда lang=/tmp/upload/f78a.tmp
То есть можно выполнить произвольный PHP-код на сервере. Очень опасная штука.
Проверка на перенаправление на другие сайты и открытые редиректы;
Имеем форму логина и переменную типа "page". По смыслу, когда человек вошел на сайт, его перекидывает обратно на данную "page". Однако без дополнительных проверок, если page - любой URL, то получаем "open redirect": /login?page=http://my.site/xxx
Это плохо для SEO. Также это может сбить с толку пользователя, если my.site внешне неотличим от исходного сайта - можно, к примеру, подсунуть пользователю "форму входа", он подумает, что ошибся в пароле и введет свои данные снова, только на этот раз - на подставном сайте.
Сканирование директорий и файлов, используя перебор и «google hack»;
Я просто оставлю это здесь: https://habr.com/post/70330/
Проверки ресурса на возможность открытого получения конфиденциальной и секретной информации;
Файлы во всяких форумах и CMS часто сохраняют в какую-то общую папку без защиты доступа. Если у тебя есть ссылка (имя файла) - то даже не имея прав просматривать форум/раздел CMS ты можешь получить файл. Это не обязательно плохо, т.к. к примеру может использоваться для расшаривания файлов другим людям, но многие сайты этим грешат. Чтобы этого не было, используют специальные ссылки с хэшем, см. к примеру nginx: http://nginx.org/ru/docs/http/ngx_http_ … odule.html
Отдавать статику через PHP плохая идея из-за производительности. На форуме уже была тема.
Другая проблема - перебор идентификаторов. Я сделал заказ 1234, и если нет проверок на права (а их очень часто забывают) - я могу открыть ту же страницу с заказом, но дописав в параметр не 1234, а 1235. И увижу заказ другого человека.
Решается тоже добавлением хэша/секретной строки.
Атаки класса «race condition»;
Про это можно целую книгу написать. Вкратце, есть маршрут заказа некоего товара. Если программист не озаботился защитой от гонки, то там будет что-то такое:
if ($user->balance >= $order_total) {
create_order();
$user->balance -= $order_total;
$user->save();
}
Итого, сделав 2 и более запросов одновременно (а это не так сложно, имея быструю сеть в дата-центре) я могу загнать пользователя в минус, не имея достаточно денег на балансе.
Данный конкретный пример решается оборачиванием всего маршрута в транзакцию, но этот пример мне просто пришел в голову с ходу, а на практике гонка встречается в самых разных формах и может вылиться в крупные суммы для ресурса, если постоянно не держать эту возможность в голове.
Подбор паролей.
Без деталей можно только гадать, что имелось в виду - повесить CAPTCHA, ограничить число попыток ввода с IP или что-то более умное вроде атак по времени на токены, может даже BREACH...
В целом, насчет возможности подбора паролей переживать не стоит, это самая малая проблема для сайта - пользователи, которые не парятся о своих паролях, найдут способ любые ваши ограничения ("один знак, заглавная буква и цифра" = "aA1!") и их все равно взломают, а те, которые парятся, сгенерируют такой пароль, что его даже без CAPTCHA можно брутфорсить до конца времени.
Меня больше волнуют банки, которые не позволяют использовать больше 16 знаков в пароле, или которые ограничивают набор символов только цифрами (привет, ВТБ).
$path = mkdir('/images/avatars/'.utf8_decode($user_id),0755,true);
А что вы хотите получить от mkdir? https://secure.php.net/manual/ru/functi … turnvalues
Можно как-то отправить с сервера запрос и получить ответ.
Нельзя, в целях защиты от спама не все сервера отвечают, когда ящик существует, когда нет, и крайне редко сообщают, когда письмо попало в спам (вернее, иногда сообщают, но не-сообщение далеко не означает, что письма в спаме нет).
Единственный вариант - вставлять картинку в HTML-письмо, которая отдается скриптом, и записывать, кто сообщения читал. Но, к счастью, есть нормальные почтовые клиенты, которые блокируют все удаленные рисунки...
Так что 100% гарантии дать невозможно.
Во время активации каждой организации уходило уведомление.
Кому? Каждой из 2 млн предприятий? Так это натуральный спам, естественно за него и хостер будет блокировать, и в спам такие письма попадать будут.
Есть такая структура таблицы orders
Довольно странная структура, "заказ" обычно это набор товаров, а здесь получается, что "заказов" нет, но есть запись "id товара" на каждого пользователя (а не на каждый заказ!).
Нужно, чтобы заселектились записи только те, в которых предыдущие записи с такими же user_id имеют эквивалентный product_id.
В СУБД как такового нет порядка строк, и уж тем более нельзя производить операции над строками в зависимости от их порядка (т.е. "выбрать если предыдущая строка ..."). Для этого вводится новое поле и используется GROUP BY.
То есть если бы в orders, как это обычно бывает, был бы id заказа (order_id), то задача решается простым SELECT ... GROUP BY order_id, без подзапросов и прочих трюков.
Как грамотно проверить ограничение на загрузку и выдать предупреждение пользователя.
Никак. В формах не предусмотрено стандартных механизмов для оповещения браузера о максимальном размере загружаемого файла (на самом деле - размере передаваемых данных в форме, например, если ты вставишь в textarea N мегабайт текста, результат будет тот же). Соответственно, ошибка произойдет только тогда, когда пользователь отправил форму и браузер переслал на сервер max+1 байт.
Мораль такова: для мелких файлов (пара мегабайт) можно использовать традиционный способ загрузки (через форму с POST) - здесь потеря данных и времени не так критична; для больших файлов - только JavaScript, с предварительной проверкой на клиенте до отправки формы. Из минусов - некоторые очень старые браузеры идут лесом.
1) для строковых полей размер поля не указан. в sqlite у строк нет размера ?
Да, и более того, в SQLite даже нет строгих типов полей - тип поля можно вообще не указывать, в строковом поле можно хранить числа и т.д.
2) Могут ли быть какие проблемы если при разработке использовал mysql, а для тестирования взять sqlite ?
У них разный синтаксис (" вместо ` для колонок, и пр.), у MySQL больше функций и других расширений стандарта (GROUP_CONCAT, AUTO_INCREMENT, работа с кодировками) и т.д.
Если в проекте ничего из этого не используется, то проблем не будет, но редко встретишь проект, который можно просто взять и запустить на любой другой СУБД - в обычном случае под СУБД понимается именно и только MySQL, и люди используют ее нестандартные функции, даже не зная, что они нестандартные (в этом нет ничего плохого, т.к. 90% проектов с MySQL никогда не уходят).
Я вычитал что для тестирования sqlite как раз и хорош - так как он однопользовательский ...
Он не однопользовательский, SQLite может работать в многопользовательском режиме. По всей видимости, там где ты это читал имелось в виду, что он не умеет писать в базу одновременно двумя клиентами (т.е. если выполнить UPDATE в двух одновременных запросах, то первый запрос начнет выполнение UPDATE, второй заморозится и будет ждать, когда первый закончит, после чего выполнит свой UPDATE). То есть операции записи идут последовательно, даже если они друг друга не затрагивают (например, UPDATE разных таблиц).
Это влияет только на производительность. SQLite не упадет из-за того, что приходят одновременные запросы на запись, он просто будет работать медленнее MySQL. Для локальной разработки это не критично.
3) А для каких приложений(кроме тестирования) sqlite может быть удобен ?
Там, где нагрузка на БД не большая. SQLite лучше MySQL и других мощных СУБД в том, что его не нужно устанавливать и что-либо настраивать на сервере. Больше того, он может даже работать с БД в памяти, т.е. даже прав на запись на диск у него может не быть.
Для решений, где главное - простая установка (а лучше вообще отсутствие установки) - это самое то. Извлек скрипты и тут же начал работать.
SQLite используют очень много крупных проектов - Firefox, Android и т.д. Это проверенное решение.
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)