при авторизации кладите в cookie например id пользователя, name, еще какую либо инфу (которую не жалко если уйдет налево)
генерируете тонкен на основе id+infa+private_key этот же токен кладете в куку вместе с данными по пользователю
Далее при переходе между страницами смотрите куку, читайте id, info, token, на стороне сервера заново вычисляете token2 id+info+private_key и сравниваете с token который в куках, если они не совпадают то ,была подмена в куках - пользователя на страницу авторизации, если совпадают то пользователь достоверен на 90%.
Если пользователь совершает какие-либо действия - (сохранение, заказ итд на запись в БД) то можно дополнительно обращаться к БД в таблицу с пользователями и по ID вытаскивать данные проверять что есть тот за кого себя выдает.
Плюсы метода:
при переходе от одной страницы к другой вам не надо каждый раз лезть в БД и вытаскивать пользователя, все данные есть в куках
Минусы: можно посмотреть что есть в куках (но эту проблему можно решить шифрованием)
unlik, все просто
.reviews__avatar это внешний контейнер для аватара, внутри него есть картинка, по сути вашим кодом вы закруглили внешний контейнер, а картинка квадратная, следовательно она отображается как квадратная
overflow:hidden скрывает все что выходит за рамки контейнера(картинка)
более простой вариант закруглить саму картинку reviews__avatar-pic{border-radius:50%;}
причем тут тип поля, если он обрабатывает бинарник mysql_real_escape_string )))
картинка не строка, ее не надо экранировать, если паритесь за безопасность, во время загрузки файла, не копируйте его, а создайте новый image на основе загруженного, без всякого exif лишнего и встроенного в картинку кода
FeNUMe, попал в руки один сайт, где была ошибка, когда в url был #? в любом порядке хоть кодами (url_encode) хоть без, оказалось .htaccess падал на таких конструкциях
поэтому черт его знает что там в htaccess, передал POST и радуйся, тем более текст, у url тоже есть ограничение на длину
еще как вариант закодировать в base64 чтоб ничего не терялось
$AC->request($url, 'GET', NULL, NULL, NULL);
точно после выполнения нет остановки работы скрипта?
проблема где-то тут $AC->request ...
как я понял, пока сайт не распарсится, то признак в БД не появится, засеките по времени сколько парсится 1 сайт,
нет ли принудительной остановки или ошибок при парсинге
Если парсится асинхронно, то логично что каждый раз будут одни те же данные в цикле, как вариант присваивайте статус сайту что он начал парсится до обращения к $AC->request($url, 'GET', NULL, NULL, NULL);
тогда цикл пойдет дальше!
c foreach ошибок нет, видимо они где-то дальше, покажите код с ошибкой, где ругается
ну и включите отображение ошибок для теста ini_set('display_errors','1'); в php до цикла, далее еще раз запрос и смотреть response формы в network
посмотрите в инспекторе prntscr.com/igsyye
1 открыть инспектор, перейти на вкладку network
2 выполнить запрос
3 выбрать запрос в списке по посмтреть prntscr.com/igszcx response
teodor7teodor7, я бы хранил, т.к. больше чем уверен, что потом понадобятся эти даты, например в таблицу можно добавить признаки различные, опоздал экскурсовод, была отменена, сколько пришло людей итд, и по ним делать аналитику. Даже элементарно определить в какие дни экскурсия пользуется огромной популярностью(например чтоб поднять цену в эти дни), а в какие дни нет)
хранить на 5 лет смысла нет, на год вполне, через год снова расставите дни, нажмете кнопку и скриптом запишите в БД даты
генерируете тонкен на основе id+infa+private_key этот же токен кладете в куку вместе с данными по пользователю
Далее при переходе между страницами смотрите куку, читайте id, info, token, на стороне сервера заново вычисляете token2 id+info+private_key и сравниваете с token который в куках, если они не совпадают то ,была подмена в куках - пользователя на страницу авторизации, если совпадают то пользователь достоверен на 90%.
Если пользователь совершает какие-либо действия - (сохранение, заказ итд на запись в БД) то можно дополнительно обращаться к БД в таблицу с пользователями и по ID вытаскивать данные проверять что есть тот за кого себя выдает.
Плюсы метода:
при переходе от одной страницы к другой вам не надо каждый раз лезть в БД и вытаскивать пользователя, все данные есть в куках
Минусы: можно посмотреть что есть в куках (но эту проблему можно решить шифрованием)
А вообще читайте про авторизацию на токенах...