Single sign-on на omniauth и rails / Хабр

Accounts#get_info

Возвращаем хеш в формате json, как и было условлено — только первые значения параметров, если те представлены массивом.

data_hash = grant.account.info
hash = Hash.new
hash['id'] = grant.account.id
data_hash.each do |key, value|
	if value.kind_of?(Array)
		hash[key] = value[0]
	else
		hash[key] = value
	end
end
render :json => hash.to_json

Adapting our provider

Now’s the time to adapt the provider to deal with OAuth 2 exclusively, as well as understand how it will work with Rails 5 .

Authorization development support¶↑

If your authorization rules become more complex, you might be glad to use the authorization rules browser that comes with declarative_authorization. It has a syntax-highlighted and a graphical view with filtering of the current authorization rules.

By default, it will only be available in development mode. To use it, add the following lines to your authorization_rules.rb for the appropriate role:

has_permission_on:authorization_rules, :to=>:read

Then, point your browser to

Authorization rules¶↑

Authorization rules are defined in config/authorization_rules.rb (Or redefine rules files path via Authorization::AUTH_DSL_FILES). E.g.

Change your application’s secret token

If you’ve used the Rails Composer tool to generate the application, the application’s secret token will be unique, just as with any Rails application generated with the rails new command.

However, if you’ve cloned the application directly from GitHub, it is crucial that you change the application’s secret token before deploying your application in production mode. Otherwise, people could change their session information, and potentially access your site without permission. Your secret token should be at least 30 characters long and completely random.

Get a unique secret token:

rails secret

Edit the config/secrets.yml file to change the secret token.

Configuration file

To consolidate configuration settings in a single location, we store credentials in the config/secrets.yml file. To keep your credentials private, use Unix environment variables to set your credentials. See the article Rails Environment Variables for more information.

Add your credentials to the file config/secrets.yml:

Contributors¶↑

Thanks to John Joseph Bachir, Dennis Blöte, Eike Carls, Damian Caruso, Kai Chen, Erik Dahlstrand, Jeroen van Dijk, Alexander Dobriakov, Sebastian Dyck, Ari Epstein, Jeremy Friesen, Tim Harper, John Hawthorn, hollownest, Daniel Kristensen, Jeremy Kleindl, Joel Kociolek, Benjamin ter Kuile, Brad Langhorst, Brian Langenfeld, Georg Ledermann, Geoff Longman, Olly Lylo, Mark Mansour, Thomas Maurer, Kevin Moore, Tyler Pickett, Edward Rudd, Sharagoz, TJ Singleton, Mike Vincent, Joel Westerberg

Controller authorization¶↑

For RESTful controllers, add `filter_resource_access`:

class MyRestfulController < ApplicationController
  filter_resource_access
  ...
end

For a non-RESTful controller, you can use `filter_access_to`:

class MyOtherController < ApplicationController
  filter_access_to :all
  # or a group: filter_access_to [:action1, :action2]
  ...
end

Creating our oauth wrapper client

The process used to create an OAuth wrapper client is very simple. Create a new file called app.rb in the root folder and add the imports and the OAuth client definition:

The client_id and client_secret are exactly the same as the ones displayed in the step from the details page. Replace them accordingly.
Immediately below it, let’s add the endpoints:

Once the client is defined and okay, you can access OAuth 2 operations under the auth_code object, such as retrieving a token or authorizing an URL.

The GETs for page_1 and page_2 are just for you to check whether the session is working. They make sure the authentication worked and is keeping the session up.

Database

Use SQLite for development on Mac or Linux, unless you already have PostgreSQL installed locally. Use PostgreSQL if you plan to deploy to Heroku. You can easily change the database later if you select SQLite to start.

Database seed file

The db/seeds.rb file initializes the database with default values.

Debugging authorization¶↑

Currently, the main means of debugging authorization decisions is logging and exceptions. Denied access to actions is logged to warn or info, including some hints about what went wrong.

All bang methods throw exceptions which may be used to retrieve more information about a denied access than a Boolean value.

Declarative authorization¶↑

The declarative authorization plugin offers an authorization mechanism inspired by RBAC. The most notable distinction to other authorization plugins is the declarative approach. That is, authorization rules are not defined programmatically in between business logic but in an authorization configuration.

With programmatic authorization rules, the developer needs to specify which roles are allowed to access a specific controller action or a part of a view, which is not DRY. With a growing application code base roles’ permissions often change and new roles are introduced.

Then, at several places of the source code the changes have to be implemented, possibly leading to omissions and thus hard to find errors. In these cases, a declarative approach as offered by decl_auth increases the development and maintenance efficiency.

Plugin features

• Authorization at controller action level

• Authorization helpers for Views

• Authorization at model level

  • Authorize CRUD (Create, Read, Update, Delete) activities

  • Query rewriting to automatically only fetch authorized records

• DSL for specifying Authorization rules in an authorization configuration

• Support for Rails 4, with backwards compatibility through Rails 2

Requirements

See below for installation instructions.

Deploy to heroku

Heroku provides low cost, easily configured Rails application hosting.

Development

CanCanCan uses appraisals to test the code base against multiple versions
of Rails, as well as the different model adapters.

When first developing, you need to run bundle install and then bundle exec appraisal install, to install the different sets.

You can then run all appraisal files (like CI does), with appraisal rake or just run a specific set DB=’sqlite’ bundle exec appraisal activerecord_5.2.2 rake.

If you’d like to run a specific set of tests within a specific file or folder you can use DB=’sqlite’ SPEC=path/to/file/or/folder bundle exec appraisal activerecord_5.2.2 rake.

If you use RubyMine, you can run RSpec tests by configuring the RSpec configuration template like this:

See the CONTRIBUTING for more information.

Devise modules

The example in the GitHub repository uses Devise with default modules.

Documentation

Head to our complete Developer Guide to learn how to use CanCanCan in details.

Email

Choose Gmail for development if you already have a Gmail account. Choose SendGrid or Mandrill for production if your site will be heavily used.

Error “undefined method `authorize’”

If you change the Pundit policy file, you may get the error, “Undefined method `authorize’.”

The error may be due to Spring, the Rails application preloader. Spring keeps your application running in the background (the intent is to eliminate time needed to start the application during development). You may think you’ve restarted your application after making changes, but Spring has kept the application running. You can check if Spring is running:

$ bin/spring status

When you get the error “Undefined method `authorize’,” stop Spring and the problem will be resolved:

$ bin/spring stop

From the railsapps project

The RailsApps open source project offers starter applications and tutorials for Rails developers. Generate the applications with the Rails Composer tool.

All the code is explained in the Capstone Rails Tutorials. You can purchase the Capstone Rails Tutorials to support the project.

Generate authorization rules¶↑

To copy a default set of authorization rules which includes CRUD priveleges, run:

$ rails g authorization:rules

This command will copy the following to `config/authorization_rules.rb`. Remember to implement the requirements of this gem as described in the Installation section at the end of this README if you do not use the above installer.

Getting started

See the article Installing Rails to make sure your development environment is prepared properly.

Getting the tests ready

Since we’re using rspec, and as I mentioned, we’ll run some of the oauth-plugin ready tests, let’s also migrate the database for tests:

test.sqlite3 was created. As the plugin was built to deal with OAuth 1 and 2, we need to remove some files (more on this by the author). They are:

• spec/controllers/oauth_clients_controller_spec.rb
• spec/models/oauth_token_spec.rb

Grants#token

По переданным параметрам находим приложение и грант. Если все в порядке — выдаем токены гранта в формате json.

Help and contact¶↑

We have an issue tracker for bugs and feature requests as well as a Google Group for discussions on the usage of the plugin. You are very welcome to contribute. Just fork the git repository and create a new issue, send a pull request or contact me personally.

Maintained by

Steffen Bartsch TZI, Universität Bremen, Germany sbartsch at tzi.org

How to implement rails api authentication with devise and doorkeeper

by Axel Kee6 December 2020

If you are new to rails

If you’re new to Rails, see What is Ruby on Rails?, the book Learn Ruby on Rails, and recommendations for a Rails tutorial.

Installation of declarative_authorization¶↑

One of three options to install the plugin:

Then,

• provide the requirements as noted below,

• create a basic config/authorization_rules.rb–you might want to take the provided example authorization_rules.dist.rb in the plugin root as a starting point,

• add filter_access_to, permitted_to? and model security as needed.

Installer¶↑

Declarative Authorization comes with an installer to make setup easy.

First, include declarative_authorization in your gemfile.

#! Gemfilegem'declarative_authorization'

Next, bundle and install.

Local

You have several options for getting the code on your own machine. You can fork, clone, or generate.

Mit license

MIT License

Model security for crud operations¶↑

To activate model security, all it takes is an explicit enabling for each model that model security should be enforced on, i.e.

class Employee < ActiveRecord::Base
  using_access_control
  ...
end

Thus,

Employee.create(...)

Models¶↑

There are two distinct features for model security built into this plugin: authorizing CRUD operations on objects as well as query rewriting to limit results according to certain privileges.

See also Authorization::AuthorizationInModel.

Orders#accept

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

Orders#deny

Отменяем заявку, просто удаляем ее из сессии.

Orders#register

Если все параметры переданы верно (то есть запрос пришел именно от omniauth) — создаем в текущей сессии запись — «заказ на грант» и сохраняем в ней все параметры:

session[:grants_orders] = Hash.new if !session[:grants_orders]
session[:grants_orders].merge!(
	params[:client_id] => {
		redirect_uri: params[:redirect_uri],
		state: params[:state],
		response_type: params[:response_type],
		'omniauth.params' => session['omniauth.params'],
		'omniauth.origin' => session['omniauth.origin'],
		'omniauth.state' => session['omniauth.state']
	}
)

Orders#show

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

Our sponsors

Do you want to sponsor CanCanCan and show your logo here?
Check our Sponsors Page.

Head to our complete Developer Guide to learn how to use CanCanCan in details.

Providing the plugin’s requirements¶↑

The requirements are

Of the various ways to provide these requirements, here is one way employing restful_authentication.

Query rewriting through named scopes¶↑

When retrieving large sets of records from databases, any authorization needs to be integrated into the query in order to prevent inefficient filtering afterwards and to use LIMIT and OFFSET in SQL statements. To keep authorization rules out of the source code, this plugin offers query rewriting mechanisms through named scopes. Thus,

Employee.with_permissions_to(:read)

Questions?

If you have any question or doubt regarding CanCanCan which you cannot find the solution to in the
documentation, please
open a question on Stackoverflow with tag
cancancan

Rspec test suite

The application contains a suite of RSpec tests. To run:

$ rspec

Scaffold a model

Let’s start with some scaffolding so we can have a model, controller and view for CRUD, you can skip this section if you already have an existing Rails app.

then in routes.rb , set the root path to ‘bookmarks#index’. Devise requires us to set a root path in routes to work.

Now we have a sample CRUD Rails app, we can move on to the next step.

Scaffolding our notes crud

Since we won’t have any webpages ready at this time (i.e., there’s no longer an oauth-plugin), let’s create a simple CRUD API for you to see the data flowing through the authentication flows.

Setup doorkeeper gem

Add doorkeeper gem in the Gemfile :

and run bundle install to install it.

Next, run the Doorkeeper installation generator :

rails g doorkeeper:install

This will generate the configuration file for Doorkeeper in config/initializers/doorkeeper.rb, which we will customize later.

Next, run the Doorkeeper migration generator :

rails g doorkeeper:migration

This will generate a migration file for Doorkeeper in db/migrate/…_create_doorkeeper_tables.rb .

We will customize the migration file as we won’t need all the tables / attributes generated.

Open the …._create_doorkeeper_tables.rb migration file, then edit to make it look like below :

# frozen_string_literal: trueclassCreateDoorkeeperTables<ActiveRecord::Migration[6.0]defchangecreate_table:oauth_applicationsdo|t|t.string:name,null: falset.string:uid,null: falset.string:secret,null: false# Remove `null: false` if you are planning to use grant flows# that doesn't require redirect URI to be used during authorization# like Client Credentials flow or Resource Owner Password.t.text:redirect_urit.string:scopes,null: false,default: ''t.boolean:confidential,null: false,default: truet.timestampsnull: falseendadd_index:oauth_applications,:uid,unique: truecreate_table:oauth_access_tokensdo|t|t.references:resource_owner,index: true# Remove `null: false` if you are planning to use Password# Credentials Grant flow that doesn't require an application.t.references:application,null: falset.string:token,null: falset.string:refresh_tokent.integer:expires_int.datetime:revoked_att.datetime:created_at,null: falset.string:scopes# The authorization server MAY issue a new refresh token, in which case# *the client MUST discard the old refresh token* and replace it with the# new refresh token. The authorization server MAY revoke the old# refresh token after issuing a new refresh token to the client.# @see https://tools.ietf.org/html/rfc6749#section-6## Doorkeeper implementation: if there is a `previous_refresh_token` column,# refresh tokens will be revoked after a related access token is used.# If there is no `previous_refresh_token` column, previous tokens are# revoked as soon as a new access token is created.## Comment out this line if you want refresh tokens to be instantly# revoked after use.t.string:previous_refresh_token,null: false,default: ""endadd_index:oauth_access_tokens,:token,unique: trueadd_index:oauth_access_tokens,:refresh_token,unique: trueadd_foreign_key(:oauth_access_tokens,:oauth_applications,column: :application_id)endend

The modification I did on the migration file :

Similar examples and tutorials

This is one in a series of Rails example apps and tutorials from the RailsApps Project. See a list of additional Rails examples, tutorials, and starter apps. Related example applications may be useful:

Special thanks

Thanks to our Sponsors and to all the CanCanCan contributors.
See the CHANGELOG for the full list.

Template engine

The example application uses the default “ERB” Rails template engine. Optionally, you can use another template engine, such as Haml or Slim. See instructions for Haml and Rails.

Test the app

You can check that your application runs properly by entering the command:

$ rails server

Testing

If you are a beginner, select “None.”

Testing¶↑

declarative_authorization provides a few helpers to ease the testing with authorization in mind.

In your test_helper.rb, to enable the helpers add

require 'declarative_authorization/maintenance'

class Test::Unit::TestCase
  include Authorization::TestHelper
  ...
end

For using the test helpers with RSpec, just add the following lines to your spec_helper.rb (somewhere after require ‘spec/rails’):

require'declarative_authorization/maintenance'includeAuthorization::TestHelper

Now, in unit tests, you may deactivate authorization if needed e.g. for test setup and assume certain identities for tests:

The “layout:devise” command

Devise provides a utility command rails generate devise:views. The Devise command creates view files for signup, login, and related features. However, the views generated by Devise lack CSS styling.

Use the RailsLayout gem to generate Devise views with styling for Bootstrap or Foundation.

• $ rails generate layout:devise bootstrap3
• $ rails generate layout:devise foundation5

The command will create these files:

• app/views/devise/sessions/new.html.erb
• app/views/devise/passwords/new.html.erb
• app/views/devise/registrations/edit.html.erb
• app/views/devise/registrations/new.html.erb

Additionally, the command will update a file to append Sass mixins to accommodate Bootstrap or Foundation:

• app/assets/stylesheets/framework_and_overrides.css.scss

The Sass mixins allow any view to be used with either Bootstrap or Foundation (so we don’t have to maintain separate views for each front-end framework).

The views

Now, we only need the two .erb files in the views folder (please, make sure to create it) to serve the HTML responses.

Create two files:

• page1.erb: to display the message from the API and a link to check the session persistence.
• success.erb: to display the success message and a link to page1.

Troubleshooting

If you get an error “OpenSSL certificate verify failed” or “Gem::RemoteFetcher::FetchError: SSL_connect” see the article OpenSSL errors and Rails.

Use rvm

I recommend using rvm, the Ruby Version Manager, to create a project-specific gemset for the application. If you generate the application with the Rails Composer tool, you can create a project-specific gemset.

Web servers

If you plan to deploy to Heroku, select Unicorn as your production webserver. Unicorn is recommended by Heroku.

What is implemented — and what is not

This application extends the rails-devise example application to add authorization with Pundit. The rails-devise example application provides:

Авторизация

Метод authorize — самое темное место в схеме процесса — уж очень много нюансов нужно учесть, прежде чем выдать грант пользователю.

В идеале (при повторной авторизации) — соблюдаются следующие условия:

В этом случае пользователь авторизуется сразу же, и выполняется редирект в callback-метод сайта-клиента. Параметрами отсылаются код гранта и состояние state.

Если хотя бы одно из этих условий не выполнено — необходимо сперва уладить проблемы:

Эти действия подразумевают навигацию по сайту-провайдеру и даже по сайтам соц. сервисов (если пользователю нужно войти в систему). Последнее неспроста оказалось выделено — именно в этом месте omniauth показывает свои неприятные стороны.

Дело в том, что omniauth при переходе в authorize передает несколько параметров в url, а также прописывает несколько параметров в сессии сайта-провайдера. Это необходимо ему для корректного редиректа в callback-метод. Но если мы вдруг захотим воспользоваться omniauth на сайте-провайдере (например, при попытке войти в систему через соц. сервис) — omniauth сотрет свои данные из сессии. И редирект завершится ошибкой OmniAuth::Strategies::OAuth2::CallbackError — invalid_credentials.

Поэтому, во избежание подобных ситуаций, все параметры omniauth четко фиксируются в сессии и восстанавливаются уже перед самым редиректом.

Авторизация пользователей ruby on rails: писать свою или использовать gem-ы?

Контроллеры

AuthenticationsController

покрывает все нужды по аутентификации, включает следующие действия:

При выборе одного из сервисов аутентификации, выполняются стандартные для omniauth операции — венцом которых, в случае успешной аутентификации, является вызов callback-метода. В зависимости от ситуации он выполняет следующие действия:

Хеш данных при этом формируется в отдельном приватном методе get_data_hash() в зависимости от выбранного соц. сервиса.

Для добавления данных в конец массивов без дубликатов используется метод модели add_info (основан на операции объединения массивов):

def add_info(info)
    self.info.merge!(info){|key, oldval, newval| [*oldval].to_a | [*newval].to_a}
  end

А для привязки аутентификаций — add_authentications:

def add_authentications(authentications)
    self.authentications << authentications
  end

В результате, в сессии сохраняется id аккаунта, для которого был совершен вход — session[:account_id].

AccountsController на данном этапе содержит такие действия:

А также фильтр — обязательная проверка на наличие пользователя в сети (с редиректом на страницу входа login).

Очень хотелось добиться возможности действительно удобного и гибкого изменения данных. И такая задача до сих пор стоит и будет прорабатываться в будущем. Пока что — редактирование происходит двумя способами:

Модели

Чтобы Rails понимал info как хеш: в миграции указывается тип поля text, а в модель добавляется код:

serialize :info, Hash

Между моделями — связь один-ко-многим:

# /app/models/account.rb
has_many :authentications

# /app/models/authentication.rb
belongs_to :account

Обновление данных аккаунта

Среди всех данных, доступных omniauth из соц. сервисов, наиболее часто обновляется аватар пользователя. Чуть реже — ссылки на страницы (параметр urls), nickname и description в твиттере. В любом случае, возникает желание одним нажатием обновить их и в аккаунте… или оставить прежние — ситуации ведь бывают разные. Наш алгоритм для этого отлично подходит — записывает новые значения в конец массивов, не сохраняя дубликаты.

Общая схема

Рассмотрены будут три проекта:

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

Запускать будем на

localhost:4000

Структура стандартна для любых сайтов, использующих omniauth:

gem 'omniauth'
gem 'omniauth-accounts'

Rails.application.config.middleware.use OmniAuth::Builder do
	provider :accounts, ENV['ACCOUNTS_API_ID'], ENV['ACCOUNTS_API_SECRET'],
		client_options: {
			site: ENV['ACCOUNTS_API_SITE']
		}
end

match '/auth/:provider/callback', :to => 'auth#callback'

rails g controller auth --skip-assets

# auth_controller.rb
class AuthController < ApplicationController
	def callback
		auth_hash = request.env['omniauth.auth']
		render json: auth_hash
	end
end

Вот и все, минимально.

Производная от стандартной oauth 2.0 стратегии, в Gemspec указана зависимость omniauth-oauth2. Кода совсем немного, к тому же — подстраивать его под себя не имеет смысла, все необходимые стратегии данные передаются в параметрах инициализации (в примере — в виде переменных окружения). Это:

Получив эти данные, стратегия всю дальнейшую работу берет на себя. Из-за этого, правда, в ходе разработки могут происходить неприятные случаи, когда в определенной ситуации стратегия «теряется» — не может продолжить свое выполнение дальше как планировалось. С такими проблемами пришлось столкнуться и мне, и решение каждой было найдено — будет рассмотрено далее в статье.

Запускать будем на

localhost:3000

Сочетает в себе две половины:

Аутентификация на сайте-провайдере происходит с помощью стандартных стратегий omniauth.

Аутентификация на сайте-клиенте — с помощью кастомной стратегии.

Общее звено — аккаунт (account):

Привязка разных сервисов к одному аккаунту

Аналог ключницы на хабре — в системе создается запись в таблице аутентификаций и привязывается к текущему аккаунту. Используется в дальнейшем как ключ и как источник данных.

Ручное редактирование полей аккаунта

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

Слияние аккаунтов

Зашли в систему через gmail-ящик — система создала один аккаунт, с данными из gmail’а. В следующий раз зашли через фейсбук, и система снова создала новый аккаунт. Смотрим и понимаем, что в прошлый раз уже аккаунт себе создавали через… вспоминаем… gmail!

В gmail мы — Александр Половин, а в фейсбуке — Alex Polovin. И какие данные оставить в аккаунте?

Тут же при слиянии спросить у пользователя, что из этого оставить? Нет, это очень неудачная в плане юзабилити затея — пользователь ведь сливает аккаунты, чтобы поскорее снова зайти с помощью аккаунта на сайт, на который он заходил прежде, у него нет времени сейчас отвлекаться на диалоги вида «Заменить» и «Заменить все».

Моим решением стало добавление новых данных «про запас», как дополнительных значений полей аккаунта. По сути, все данные аккаунта хранятся в хеше, и этот хеш может принять следующий вид после слияния (добавим туда еще данные с условного твиттера — Половин Алекс):

{
	name: ['Александр Половин', 'Alex Polovin', 'Половин Алекс'],
	first_name: ['Александр', 'Alex', 'Алекс'],
	sir_name: ['Половин', 'Polovin'],
	...
}

Как видите, значения просто добавляются в массив для каждого поля. При этом они не дублируются — «Половин» из твиттера не сохранился дубликатом в «фамилии».

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

Создание связи между сайтом-клиентом и сайтом-провайдером

Стандартной практикой в этом случае является создание «приложения» на сайте-провайдере. Указываем имя и адрес сайта-клиента (вернее — адрес для callback-редиректа) — и получаем два ключа — id и secret. Их указываем в параметрах системы социальной аутентификации — будь то какой-либо плагин к cms, или гем для Rails. В нашем случае — ключи используются omniauth — ACCOUNTS_API_ID и ACCOUNTS_API_SECRET.

Внедрить поддержку приложений в сайт-провайдер несложно:

rails g scaffold Application name:string uid:string secret:string redirect_uri:string account_id:integer
rake db:migrate

# account.rb
has_many :applications

Модель при создании новой записи должна генерировать для нее ключи:

before_create :default_values
def default_values
	self.uid = SecureRandom.hex(16)
	self.secret = SecureRandom.hex(16)
end

И — во всех действиях на приложения должна стоять фильтрация по текущему пользователю. Например, вместо:

@applications = Application.all

используется:

@applications = Account.find(session[:account_id]).applications

Причем — обязательно добиваться того, чтобы пользователь был в сети — поставить фильтр:

before_filter :check_authentication
def check_authentication
	if !session[:account_id]
		redirect_to auth_path, notice: 'Вам необходимо войти в систему, используя один из вариантов.'
	end
end

Схема процесса

Аутентификация построена на oauth 2.0 — о принципах работы данного протокола можно узнать в этой статье на хабре, либо наглядно здесь.

Dependencies

Before generating your application, you will need:

• The Ruby language – version 2.3.1
• The Rails gem – version 5.0

See the article Installing Rails for instructions about setting up Rails and your development environment.

Заключение

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