Модели данных для аутентификации пользователей в web-приложениях

Я пытаюсь выяснить является ли тезис "Пока же создание очередного web-приложения зачастую начинается с проектирования собственной структуры данных для аутентификации пользователей" заблуждением или нет.

Это же очевидно, разве нет?

С лупой на слона

Really?

https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0

С лупой на слона

Потому что статья про web-приложения. И если приглядываться внимательнее, то на картинке — персонажи из компьютерной игры Far Cry (компьютерная графика бросается в глаза даже тем, кто в принципе не знает, что такое компьтерная графика). Зачем вы с коллегой kk86 в статье про web-приложения с КДПВ из компьютерной игры начали обсуждать необходимость интеллекта в охоте на мамонтов — это вопрос из раздела "загадочные тайны безграничной Вселенной". Ну, коллега, допустим, блеснул знанием английского. А чем блеснули вы?

С лупой на слона

Спасибо, коллега! Приятно видеть, что в PHP-среде есть подвижки в этом направлении. Вытащил в том или ином виде структуры данных для каждого из модулей:

yii2-user:

/**
 * User ActiveRecord model.
 *
 * @property bool    $isAdmin
 * @property bool    $isBlocked
 * @property bool    $isConfirmed
 *
 * Database fields:
 * @property integer $id
 * @property string  $username
 * @property string  $email
 * @property string  $unconfirmed_email
 * @property string  $password_hash
 * @property string  $auth_key
 * @property string  $registration_ip
 * @property integer $confirmed_at
 * @property integer $blocked_at
 * @property integer $created_at
 * @property integer $updated_at
 * @property integer $last_login
 * @property integer $flags
 *
 * Defined relations:
 * @property Account[] $accounts
 * @property Profile   $profile
 *
 * Dependencies:
 * @property-read Finder $finder
 * @property-read Module $module
 * @property-read Mailer $mailer
 *
 * @author Dmitry Erofeev <[e-mail]>
 */

FOSUserBundle:

    /** @var mixed */
    protected $id;
    /** @var string */
    protected $username;
    /** @var string */
    protected $usernameCanonical;
    /** @var string */
    protected $email;
    /** @var string */
    protected $emailCanonical;
    /** @var bool */
    protected $enabled;
    /** @var string The salt to use for hashing. */
    protected $salt;
    /** @var string Encrypted password. Must be persisted.*/
    protected $password;
    /** @var string Plain password. Used for model validation. Must not be persisted. */
    protected $plainPassword;
    /** @var \DateTime */
    protected $lastLogin;
    /** @var string Random string sent to the user email address in order to verify it.*/
    protected $confirmationToken;
    /** @var \DateTime */
    protected $passwordRequestedAt;
    /** @var Collection */
    protected $groups;
    /** @var array */
    protected $roles;

Laravel:

        Schema::create('users', function (Blueprint $table) {
            $table->increments('id');
            $table->string('name');
            $table->string('email')->unique();
            $table->string('password', 60);
            $table->rememberToken();
            $table->timestamps();
        });

ZfcUser:

    CREATE TABLE user
    (
        user_id       INTEGER PRIMARY KEY AUTO_INCREMENT NOT NULL,
        username      VARCHAR(255) DEFAULT NULL UNIQUE,
        email         VARCHAR(255) DEFAULT NULL UNIQUE,
        display_name  VARCHAR(50) DEFAULT NULL,
        password      VARCHAR(128) NOT NULL,
        state         SMALLINT
    ) ENGINE=InnoDB;

По ним можно видеть, какую функциональность в дополнение к аутентификации (не)предлагает соотв. модуль для соотв. фреймворка. Вполне возможно с одним фреймворком можно (будет) использовать разные модули с различными схемами данных, обеспечивающими различный функцонал (базовый, расширенный, специализированный). И вполне возможно, различные модули для различных фреймворков будут имплементировать одинаковые структуры данных. И вполне возможно, что эти структуры данных будут одинаковы не только для различных модулей различных PHP-фреймворков, но и для аналогичных модулей Java/C#/Python/… фреймворков.

Какая разница, на чем написан server side, если он работает с MySQL/Postrgres/MongoDB/Oracle/… и решает одни и те же задачи (authentication, password management, etc.)? Структуры данных должны соответствовать решаемым задачам, а не тому языку, на котором происходит обработка этих данных.

С лупой на слона

Что статья про web-приложения, а не про кроманьонцев.

С лупой на слона

Если вы хотите что-то узнать — задайте вопрос. В ваших комментах нет ни одного вопроса.

С лупой на слона

Спасибо за дополнения, коллега Vlad_fox.

Я, возможно не очень явно, тему тестирования затрагивал в "Там на неведомых дорожках...". TDD входит в конфликт с первыми двумя пунктами — приспосабливаемость (раз уж "адаптивность" устойчиво ассоциируется с версткой) и неопределенность. Поэтому у меня к нему очень настороженное отношение. Безусловно полезная вещь при наличии ресурсов и ясного представления о предмете разработки. При недостатке ресурсов или отсутствии ясного понимания что и как делать TDD становится обузой или тормозом. Но тестирование в том или ином виде (и лучше автоматическом) быть обязано — иначе "асфальт не натоптать" (если только толпы пользователей не запустить).

Необходимость использования готовых фреймворков и библиотек я пытался отразить в пунктах "Модульность" и "Муравейник". Тоже, наверное, достаточно неявно. Пока что мы даже на уровне данных еще не имеем каких-либо стандартов для даже таких древних "велосипедов", как аутентификация. Хотя, казалось бы, почему бы не выработать одну-две-три схемы для подобной структуры? Сколько я различных названий видел для первого поля аутентификационной формы — login, user, username, email. Можно ведь описать в XSD типовые структуры данных (одно- и двух-факторная аутентификация, с уникальным email'ом у пользователя или группой email'ов, с физическим представителем юридческого лица и т.д.) и преобразовывать структуру в SQL/NoSQL/Files/InMemory/… В Java подобные попытки делались. Я понимаю, что зафункционалить все стандартно на различных языках программирования невозможно, но на уровне структур данных можно найти консенсус, разве нет? Хотя наверно, проще написать свой "велосипед" на тему аутентификации, чем всем вместе договориться использовать единую схему данных.

С лупой на слона

Приятно наблюдать, как вы разбиваете в пух и прах выссказывания вашего оппонента, хоть и не очень хорошо понимаете, о чем это он.

С лупой на слона

Было бы любопытно сравнить предлагаемые структуры данных, обеспечивающие аутентификацию, допустим, в Asp.Net MVC и в cookiecutter.

С лупой на слона

Отсутствие у кроманьонцев развитой транспортной системы как бы тоже намекает, что с плохой дыхалкой мамонта не догнать, а без развитой мускулатуры разобранную тушку к месту поедания не переместить. Хотя я и допускаю, что особо высокоинтеллектуальные кроманьонцы вполне могли создавать ситуации, когда мамонты добровольно приходили на порог их жилищ и самоубивались, дабы совершенно исключить применение грубой физической силы со стороны древнейшей интеллигенции. Остальным же, не столь интеллектуальным, приходилось убалтывать последних неандертальцев понапрягаться физически вместо себя. Возможно от этого, кстати, неандертальцы и вымерли — от перенапряжения. Когда-нибудь британские ученые осветят и этот вопрос.

С лупой на слона

Я надеюсь, мы все-таки говорим за аутентификацию — она несколько до проблемы авторизации стоит. Сначала мы узнаем, с кем имеем дело, а у же потом — какие у него права доступа и к чему.

Cookiecutter Django is a framework for jumpstarting production-ready Django projects quickly

Допускаю, что cookiecutter прекрасно решает эту проблему для Django-проектов. Это как Ruby on Rails, только Django. А если ваш заказчик настаивает, чтобы backend вашего web-приложения был написан на PHP/Java/C#/JavaScript/… — какие фреймворки с готовой аутентификацией вы мне посоветуете? Или, допустим, ваш заказчик хочет иметь в своем web-приложении двухфакторную аутентификацию (через SMS — самый распространенный вариант)? Это ведь тоже уже достаточно "велосипед" — кукикаттер имеет решение этой проблемы хотя бы для Django-проектов?

С лупой на слона

Говорят, эту проблему решают фреймворки. Или нет? :)
нет :(

Расширенная регуляризация нейронных сетей в интернет-магазинах — с помощью… напалма

Мощный поток сознания! Зашел прочитать про интернет-магазины и оказался погребен под лавиной ссылок, терминов и имен собственных. Как-то из всего этого извлек, что все эти штучки применимы только для крупных магазинов с кол-вом продаж over 100500 и выдохнул с облегчением — не мой сегмент. Потому как без тяжелых наркотиков такое не вкуривается, а с тяжелыми — здоровье не позволяет. Завидую я вашему здоровью, коллега!

Hype Driven Development

Правильно :) Мне, по-большому счету, все равно, кто расставил эти буквы в слова в таком порядке, меня, по-большому счету, интересует прежде всего информация, которая передается при помощи этих слов. Это https://habrahabr.ru/, а не http://yapishu.net/

Hype Driven Development

Коллега poxu, вы сбиваете фокус внимания со вкуса вина на цвет бутылки, в которую его разлили. Вам есть что сказать за само вино?

Блеск и нищета php. Эволюция языка от 4.x к 7.1

Да, очень похоже на то, что нужно :)

<?php
require 'vendor/autoload.php';

$i = 0;
$app = function ($request, $response) use ($i) {
    $response->writeHead(200, array('Content-Type' => 'text/plain'));
    $response->end("Hello World $i\n");
    $i++;
};

$loop = React\EventLoop\Factory::create();
$socket = new React\Socket\Server($loop);
$http = new React\Http\Server($socket, $loop);

$http->on('request', $app);
echo "Server running at http://127.0.0.1:1337\n";

$socket->listen(1337);
$loop->run();

Блеск и нищета php. Эволюция языка от 4.x к 7.1

Слой REST/JSON-сервисов в web-приложениях, если удастся вывести PHP из сферы действия Apache/Nginx и поднимать как standalone сервер (типа ExpressJS, Tomcat/java, WSGI/python). Ну или в рамках Apache/Nginx запускать PHP-приложения со стадиями инициализации приложения, обработки запросов, завершения приложения (типа servlet'ов). Делать вот это все на каждый GET/POST запрос с web'а — весьма расточительно, не говоря уже о сборке HTML'а на стороне сервера. В web-разработке позиции PHP весьма сильны, но с фронта всех теснит JS — остается back.

Scrum от военного летчика: Искусство делать вдвое больше дел в два раза быстрее

Он поперхнулся, а затем разрыдался: «Я не могу передать вам то счастье, что я испытал. Это изменило всю мою жизнь»

До этого момента читалось с интересом, а после — в памяти всплыло слово "секта".

Как насчёт класть каждую функцию в свой файл?

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

… для проекта, который не будет устанавливаться другим людям

вообще не дискутировал на тему. В своем pet-проекте каждый волен писать код настолько феерично, насколько он чувствует потребность.

Как насчёт класть каждую функцию в свой файл?

В таком случае — берите выше! Коллега saggid заново изобрел декомпозицию, которая является краеугольным камнем в разработке сложных систем. Посыл абсолютно тот же, а глобальность аналогии просто зашкаливающая. Круче может быть только изобрести заново двоичную систему.

Дъявол кроется в деталях, если что.