Главная страница Случайная страница Разделы сайта АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
💸 Как сделать бизнес проще, а карман толще?
Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже.
Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал.
Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее. ✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать». Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами! Второй подход
О чём речь Итак, secureshare.pw — сервис одноразовых ссылок. Т.е. это средство безопасной передачи конфиденциальных данных другому человеку. Суть в том, что секретные данные пользователя сохраняются в базе данных сервера, а пользователю даётся одноразовая ссылка, по которой доступны эти самые данные. Ссылка действительна только один раз и сразу после первого просмотра данные уничтожаются. Можно не бояться того, что ссылка останется в истории сообщений вашего IM-сервера, в списке отправленных писем, в access-логах сервера, на скриншотах мониторов. К тому времени, когда злоумышленник доберётся до этой ссылки, она будет уже бессмысленна. Первый подход Базовый функционал системы очень прост. Всё, что нужно — сохранить данные из формы в базу данных, и выдать юзеру ссылку, однозначно идентифицирующую эти данные. Например, добавить в get-параметр primary key. После показа данных выполнить элементарный DELETE-запрос, и готово. После первого подхода система в точности так и работала. Но как-то это несерьёзно, не так ли? Второй подход Ну, давайте подумаем, что тут не так. Первое, что бросается в глаза — primary key прямо в get-параметрах запроса. То есть, если перебирать все числа по очереди, можно насобирать много чужих секретов (была в январе история со взломом файлов ICQ). Решение достаточно очевидно — использовать вместо числа что-то большое и неподбираемое. Скажем, sha1-хеш (в md5 нашли коллизии и его уже не рекомендуется использовать). Отлично, добавляем в БД новое поле, делаем по нему UNIQUE индекс, и генерируем его случайным образом для каждого нового пользовательского секретика. Уже лучше.
|