Реализация аутентификации крошечными шагами

Когда мы начали проект, который сейчас мы называем «Arkency Ecommerce», под зонтиком RailsEventStore — он фактически начинался как система управления заказами (OMS), а не как реальная электронная коммерция.

Я всегда думал, что OMS — это очевидная часть платформ электронной коммерции. Недавно я узнал, что это не всегда так, и даже Shopify рекомендует посмотреть на некоторые другие системы OMS в качестве дополнения к их электронной коммерции.

Интересно.

В любом случае, когда наш проект вырос, мы сосредоточились на «панели продаж» или «панели OMS». Пользователь, вероятно, был сотрудником отдела продаж. Никакой аутентификации для этого не было. Можно предположить, что это для внутреннего пользования компании, спрятанное в интранете.

Через некоторое время мы создали «Представление клиента». Сначала он тоже был без аутентификации. Мы только добавили «список выбора», чтобы выбрать, в качестве какого клиента вы «вошли в систему».

Однако даже тогда мы просто использовали параметр URL, чтобы запомнить, под каким клиентом мы вошли в систему. Кроме того, функциональность была и остается очень ограниченной. Это был просто список заказов.

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

Одним из моих недавних изменений было расширение аутентификации с помощью хранения cookies, пока еще без паролей.

Мне нравится концепция крошечных шагов или, как я люблю это называть, «начать с середины».

Мы начали без аутентификации, но сосредоточились на том, как это будет выглядеть. После того, как мы «увидели это»/»почувствовали это», мы могли решить, что делать дальше.

Это роскошь открытых исходных кодовых баз, не ограниченных сроками и клиентами.

Маленькие шаги позволяют увидеть две перспективы.

Перспектива кода

Мы можем начать с некоторых взломов кода (соединение моделей чтения) и выиграть немного времени, чтобы подумать, как это должно быть отражено в архитектуре. Только когда мы почувствуем, чем пахнет, мы сможем придумать лучшую архитектуру.
В данном случае это было осознание того, что «клиентская панель» — это как отдельное приложение. На уровне приложения это должно быть отражено каким-то образом. Я твердо убежден в двух уровнях архитектурного разделения в типичных веб-приложениях.
Один уровень — это прикладной уровень. Второй — уровень домена.

Часто люди путают эти два уровня и пытаются их объединить. Что бы ни было разделением приложения, оно становится разделением домена. Это печально, поскольку практически невозможно сделать такое разделение в одном измерении.

Перспектива пользовательского интерфейса

Игра с пользовательским интерфейсом позволяет переосмыслить, где мы находимся с функциями и какие следующие истории нужно реализовать. Использование пользовательского интерфейса позволяет мне задуматься о том, какие следующие крошечные шаги необходимо добавить.
Обратите внимание, что аутентификация не является самой важной функцией в этой области. Она будет очень важна, когда мы начнем работать, но до этого мы можем спрятать ее за флагом функции, если захотим. Мы все знаем, как создать аутентификацию. Это не самая рискованная область. Но мы не знаем, что именно нужно поместить в панель клиента, чтобы она была пригодна для использования. Это более рискованно.

Текущая кодовая база

module Client
  class ClientsController < ApplicationController
    layout "client_panel"

    def index
      @clients = ClientOrders::Client.all
      render "clients/index"
    end

    def login
      cookies[:client_id] = params[:client_id]
      redirect_to client_orders_path
    end

    def logout
      cookies.delete(:client_id)
      redirect_to clients_path
    end
  end
end

module Client
  class OrdersController < ApplicationController

    layout 'client_panel'

    def index
      render html: ClientOrders::OrdersList.build(view_context, cookies[:client_id]), layout: true
    end

  end
end

Как вы видите, это только установка cookies, без каких-либо проверок пользователя/пароля.

Это будет следующей реализацией, которая позволит использовать пароли для входа в систему. Что интересно в этом подходе «крошечных шагов», так это то, что мы можем начать, даже не позволяя выбирать пароль. С точки зрения пользователей мы можем начать с идеи генерирования паролей для клиентов, создания их учетных записей и только потом (позже) позволить им выбирать/менять пароли. Это еще 3 «истории», которые нужно реализовать.

Что касается кода, некоторые из вас могут найти это интересным:

render html: ClientOrders::OrdersList.build(view_context, cookies[:client_id]), layout: true

Я пошел на реализацию представления в Rails с необычным подходом — написал шаблон на Ruby вместо ERB.

Но это тема для другого поста в блоге.

Спасибо!