Приветствую! Есть задача переадресовывать все запросы на протокол https, кроме файлов robots.txt и sitemap.xml. То есть, чтобы эти файлы были доступны и по http, и https.
Nginx - это далеко не моя область. Вроде бы он не поддерживает несколько условий в if, но как бы сделать что-то в этом роде?
Приветствую! Задача вроде бы и не сложная, но справиться не получается.
Есть два домена:
new.com // основной
old.com // припаркованный
Суть состоит в том, чтобы на клиентской части была переадресация с new.com -> old.com, а в админке (директории "/admin/") оставался работать домен new.com. В htaccess уже есть следующие прописанные правила:
В данном случае, нужно:
1. В таблицу `products` записать/обновить: Название, Цену, Кол-во, а вместо названия бренда - его ID из соответствующей таблицы (напр., `brand`). Если такого бренда не существует, то предварительно записать его.
2. Варианты цветов, записать в другую таблицу. Пусть это будет `product_option`, куда записывается id товара, и id цвета. Как и с брендами, если цвета не существует, то его нужно сначала внести в таблицу `colors`.
Имеет ли смысл записывать все данные сначала во временную таблицу и писать процедуру для всех вышеперечисленных действий или же просто обрабатывать в цикле на уровне PHP каждую строку? Второй способ смущает тем, что для каждой строки реальных данных, возможно придётся делать до ~20 запросов. Сервер (VDS) слабенький: одно ядро 3.2 ГГц, 1Gb оперативки. Поэтому первый вариант, по чисто субъективному мнению, должен быть менее расточительный. К примеру, для тех же брендов, получится всего два запроса:
1. Первым запросом запись/обновление в таблицу `brand` - INSERT ... ON DUPLICATE KEY UPDATE
2. Вторым запросом - замена названий на идентичные им ID
Вроде бы и проще, и менее затратно по ресурсам, однако так ли оно на самом деле - не знаю.
В общем, хотелось бы послушать, как справлялись те, кто с данной задачей уже сталкивался и какие способы проверил на практике. Спасибо.
Кроме flexbox, как предложил выше SAD, можно для контейнера задать display: table;, а для дочерних div-ов - display: table-cell;. Ну и ширина контейнера 100% и для центрального div-а - 300px;
От меня действительно никто не требовал переделывать авторизацию и всё, что с ней связано и за это, я думаю, мне не заплатят, НО я пять лет обходил стороной эту тему, уговаривая себя тем, что мол "если кому-то очень надо будет, то он всё равно взломает". Может оно так и есть, но пусть это уже будет профи, чем какой-то сопляк-школьник... не так обидно будет ))
DeepVarvar пишет:
может лучше взять серьезный фреймворк?
Нет уж, переписывать всю CRM - на это моего энтузиазма не хватит ))
DeepVarvar пишет:
Перенести хранение сессии в БД
Я так понимаю, что тут будет в помощь session_set_save_handler() или есть другие варианты?
Мелкий пишет:
всё-таки надо прочитать и понаписать текста
В общем и целом понял, но иллюзий не строю и понимаю, что тут надо копать гораздо глубже.
Собственно, господа, всем низкий поклон за ответы, очень полезно и моё "белое пятно" по этой теме начало потихоньку закрашиваться
В двойной сверке с данными, которые хранятся на сервере, нет необходимости.
обезопасить себя от CSRF атак.... токены. Желательно одноразовые.
Спасибо, понял.
teddy пишет:
Deonis пишет:
$_SESSION['login'] === true;
Так это, вроде бы, не надёжно.
Лучше проверить например на isset, потому что данного ключа может просто не существовать.
Тут я засомневался немного в другом ключе, в плане идентификации пользователя, который работает в данной сессии. Наверно, это уже относится к XSS, но если украсть сессию, то обычное булевое значение, указывающее на то, что юзер залогинен, даст полный доступ ко всем его данным. Хотя, это рассуждения с дилетантской точки зрения.
Но в целом, спасибо за советы.
P.S. Впрочем, забудьте. А то у меня создается ощущение, что я клянчу.
DeepVarvar пишет:
И как это тебя оправдывает?
Я не ищу оправданий, т.к. они мне не нужны. Я объяснял ситуацию и не более того.
DeepVarvar пишет:
Работа то -- твоя.
Естественно! Поэтому я и не просил, чтоб кто-то делал её за меня. Вы видели где-то в моем вопросе что-то вроде кода, с просьбой поправить его? Вопрос риторический. А если вы считаете, что делиться личным опытом или указывать на какие-то конкретные ошибки с конструктивным пояснением - это приравнивается к "сделайте за меня", то пардоньте, что потревожил.
Я просто пытаюсь разобраться. Организация безопасности - это моё самое слабое место, т.к. я к этому практически не имел отношения (до сегодняшнего дня). Мне досталась "в наследство" CRM, с которой я пытаюсь разобраться и, по возможности, оптимизировать её. На данный момент было организовано так:
1. Если пользователь не аутентифицирован, то генерируется случайный хеш, который используется, как токен в форме логина.
2. После успешной авторизации, этот хеш записывается в БД и в сессию.
3. При любом запросе, хеш из сессии сверяется с хешем в БД. Если гуд, то пользователь авторизован и работа продолжается, если нет, то выбрасывается на страницу логина.
4. Кроме того, этот хеш используется в формах в скрытых полях. Как я понимаю - это для защиты от CSRF.
Вот я и пытаюсь разобраться: нет ли тут чего лишнего и сделано ли по уму, может можно что-то упростить, а может надо кардинально что-то поменять, если допущены грубые ошибки.
Приветствую, господа! У меня есть пара маленьких вопросов в плане безопасности, а точнее её усилении. После успешной аутентификации, пользователю в сессию записывается токен, который подставляется во все формы и сверяется на сервере. Есть ли смысл записывать токен в БД и при каждом запросе сверять его еще и там? Вот сижу и думаю: если на одну чашу весов положить такую дополнительную меру, а на другую - мучит БД при каждом запросе, то сто́ит ли игра свеч? Да и вообще, имеет ли смысл использовать токен после успешной авторизации, если работа ведется по SSL? Может быть достаточно просто проверять: есть сессия или нет?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 298
