- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Зачем.
Есть.
да, про это говорили, мне кажется что это уже будет защитой от подмены токена в случае разных Айпи
для каждого свой ключ чтобы банить моментально. Ну это просто шиза моя.
а поводу если есть контент для незалогиненых то тут почитать можно https://qna.habr.com/q/686086
для каждого свой ключ чтобы банить моментально. Ну это просто шиза моя.
а поводу если есть контент для незалогиненых то тут почитать можно https://qna.habr.com/q/686086
По факту мне достаточно CORS что бы апишку не могли тащить сторонние ресурсы. Но так как планируется еще мобильные аппликухи - скорее всего будет JWT-token для проверки валидности. Но это все вне рамках моего вопроса. Меня интересует работа с фронтом для залогиненого пользователя и безопасность использование токена
По факту мне достаточно CORS что бы апишку не могли тащить сторонние ресурсы. Но так как планируется еще мобильные аппликухи - скорее всего будет JWT-token для проверки валидности. Но это все вне рамках моего вопроса. Меня интересует работа с фронтом для залогиненого пользователя и безопасность использование токена
ну если приложение android не стоит в планах тогда cors наверно поможет) я думал под андроид api делаете
ну если приложение android не стоит в планах тогда cors наверно поможет) я думал под андроид api делаете
Рано об этом говорить, сначала надо веб запустить, если выстрелит - тогда буду заниматься мобильными приложениями
Рано об этом говорить, сначала надо веб запустить, если выстрелит - тогда буду заниматься мобильными приложениями
сейчас все в андроиде сидят, лучше сразу андроид делать чтобы время не терять. Если не залетит то наработки для дргуго проекта можно будет использовать.
тут главное api сделать грамотно а само приложение можно исполнителя найти, не так дорого уже сегодня если сравнивать с годами ранее
Если сайт под РФ, "взломает" его закон, что авторизоваться и регистрироваться можно только через российские сервисы (я.почта, госуслуги).
В 2024-м создавать сайты с регистрацией - так себе идея.
блин, получается авторизация через телегу так себе идея(
сейчас все в андроиде сидят, лучше сразу андроид делать чтобы время не терять. Если не залетит то наработки для дргуго проекта можно будет использовать.
тут главное api сделать грамотно а само приложение можно исполнителя найти, не так дорого уже сегодня если сравнивать с годами ранее
Я, например, сижу в Айфоне))) Мобильная версия веба сразу есть. Чтобы писать приложение - нужно все обкатать сначала. Уже был опыт разработки, когда под андроид писали, заказали, оплатили работу, а когда запустили сервис - пришлось многое менять в апишке и получились выкинутые деньги за апликуху.
Правда сейчас я в состоянии сам написать и под андроил и под айфон. Но мне интереснее сделать веб сейчас
пришлось многое менять в апишке
ага, мое мнение, что апи это основная часть работы.
Его полюбому надо делать самому и прям максимально стабильное и самостоятельно обкатанное. И документация чтобы на уровне простейшего понимания была.
Исполнителя под приложение можно найти не задорого.
Пароль хранится в базе в хэшированном виде, тут вроде все надежно и просто
md5? При сливе базы пароли легко восстановить через базу соответствия хэшей популярных паролей.
Пароли надо хранить в зашифрованном виде md5(pass + salt) где salt - уникальная для каждого пользователя строка, хранящаяся в базе. Таким образом, даже если пароль у пользователя 123, то хэширование пароля с уникальной солью даёт 100% невозможность узнать пароль при сливе базы.
md5? При сливе базы пароли легко восстановить через базу соответствия хэшей популярных паролей.
Пароли надо хранить в зашифрованном виде md5(pass + salt) где salt - уникальная для каждого пользователя строка, хранящаяся в базе. Таким образом, даже если пароль у пользователя 123, то хэширование пароля с уникальной солью даёт 100% невозможность узнать пароль при сливе базы.
Никто не использует md5 для хэширования паролей давно) Что-то ты подзастрял в прошлом) Давно уже в ходу SHA1/2/3 Про соль думаю, не знают только вбемастера местные, которые в пример ставят вордпресс на любой вопрос. Вопрос был не про хранение пароля в базе, а как обеспечить безопасную работу с данными на фронте, иначе говоря - авторизацию.