Самообучение по созданию сайтов.

Бывает

 

Не всё так просто, что?

А вы типо живёте без jquery, других API, и сами пишете весь код с нуля.

 

А вы введите в гугл "Безопасность сайта", там пятью минутами как-то и не пахнет. Это если вы знаете весь алгоритм, вам легко прогуглить каждый отдельный эллемент.

 

Забей, помогать - это не удел рубаккита, лучше гугли какие-то норм уроки, может видео. На ютубе кучу таких каналов видел, где видео одно идёт по пол часа, и там наверняка базу можно получить хорошую.

 

Все равно на форуме помощь, по идее, лучше, так-как сталкиваются несколько людей, и если один посоветует что-то неправильно, то другой может его подправить и т.п.

Пойду на тостер спрошу, часто его в гугле вижу. Как я понял,
алгоритм регистрации:
- Пользователь вводит логин, пароль +все необходимые проверки против даблов.
- Капча, которая работает через API.
- Происходит password_hash пароля и запись в бд +mysql_real_escape_string.

алгоритм авторизации:
- Пользователь вводит логин, пароль.
- Подсчитывается количество неудачных попыток и капча, в случае превышения лимита.
- Происходит password_hash и сравнение с бд +mysql_real_escape_string.
- В случае успеха, записывается в бд сессий новый id и в саму сессию.

при просмотре:
- Сравнивается, есть ли такой id сессии в бд.

 

Серьезно? С такими древними уроками далеко не уйти. Давно как устарело юзать обычный mysql.

 

Вот на жуй. Накатил тебе простенький ексампл с регой https://cloud.mail.ru/public/EbWw/S4HwTECjP.
Дальше сам изучай.

 

А по чём злиться то? Я за этим сюда и писал, что-бы написать что-то современное, а не какую-то древнюю херь, которой сеть кешит. И сделать это с минимальными затратами сил.
Нет, это не эксплуатация вас, что-бы вы написали что-то за меня, а это вопрос, где искать актуальную информацию.

Достаточно было просто сказать, что PDO создаст подключение и безопасные запросы к БД, а ещё, что шифровать надо не md5, который во всех туторах, а другим (вроде как в монуале php написанно что sha1 теперь не актуален, и надо шифровать через функцию password_hash в php)

 

А ещё, как я понял, token, это такое значение, которое надо передвать при запросах, для сверки, против CSRF?

 

Ага, против CSRF во всех формах.

 

Юзать сразу bcrypt, мне прост влом было обновлять локал php).

 

Когда забожил по лаунчеру с нуля! Определенно в статус запишу к себе!
Одни пишут плагины совершенно не зная java, другие сайты, не зная php. © Alexandrage

 

Никто во внимание не берёт JWT или через социальные сети, тоже мне современность.
Как по мне сессия изжила себя, а так же для того что бы делать шардинг приходится делать костыли вроде сессий в базе.

 

Так и что в итоге? Современные разработчики сами пишут всю регистрацию, в том числе и через соц. сети?
Или всё-таки есть какое-то API?

 

Сказал человек, который хочет выучить php и создавать свои сайты .
Ты бы определился сперва, хочешь ты быть разработчиком, или простым юзером на готовом решение. Если второе, могу предложить начать от сюда например http://rubukkit.org/threads/mcshop-v4-cms-edition.132781/#post-1430019.

 

Мне для развития: а что сейчас более удобнее использовать?

 

Да чего же вокруг да около ходите то? Конкретный же вопрос: как разработчики делают сайты?
Допустим, я куратор фирмы и заказываю у кого-то сайт. Допустим, сайт для заказа пиццы.
Меня интересует что делает разработчик: использует какие-то API или сам всё делает с нуля.

Это был пример, я задал конкретный вопрос:

А насчёт того, чего я хочу:

 

Я этого не говорил, если ты используешь фреймворк то тебе не нужно беспокоится о наличии нужных компонентов, а если отсутствует ты можешь сам написать обработчик, залить на git получив признание и поддержку community. Если ты пишешь сам то тебе стоит заранее думать что тебе нужно и продумывать на будущее развитие. Лично я в этом вопросе использую комбинированные варианты.

Как я уже выше писал можно использовать JWT (Json Web Token), вдаваться в детали реализации не буду но скажу что он хранит в payload (полезную нагрузку) скажем данные пользователя

Код:

{
  "id": 1234,
  "role": "moder",
  "roles" : ["edit", "new", "!delete"]
}

Если изменить данные внутри payload то токен не будет валидным (единственный вариант это уже украсть сам ключ с сервера).
Из-за того что приходится делать разделение сервисов на разных серверах нельзя хранить дубликаты данные на каждом сервере (репликация не вариант) и ещё нужно сделать единую схему авторизации в микросервисах API для пользователей сайта и мобильных приложений без нужды делать запросы на основной сервер. А на главном сервере стоит GraphQL которые объединяет микросервисы и он служит для аунтефикации пользователей и транзакций в базе.

 

Короче одноразовый токен с некоторой полезной информацией, который валиден на всех дочерних сервисах, так?

 

Смотря как и у кого. Могут тот же dle тебе поставить со шаблоном под заказ.