Конструкторское Бюро

Миграция критических программ и сервисов КПИ в облако AWS

2023-02-12T09:53:32.354Z

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

В начале года Андреем Губским, ИТ-консультантом и специалистом в разработке программного обеспечения, и командой сотрудников бюро, при содействии Министерства цифровой трансформации, была проведена миграция критически важных сервисов университета в облако Amazon. Это позволило сохранить работоспособность многих подразделений КПИ, несмотря на тяжелую ситуацию с электроснабжением.

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

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

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

Расписание занятий КПИ

2022-06-09T10:00:04.857Z

Многие из вас знакомы с электронным расписанием rozklad.kpi.ua. В свое время это был хороший и полезный сервис, который и сейчас облегчат жизнь многим студентам и преподавателям, но время не стоит на месте, требования к удобству и возможностям системы меняются. Поэтому мы рады представить вам предварительную версию нового расписания schedule.kpi.ua!

Новая версия имеет более удобный интерфейс, который корректно отображается как на экране компьютера, или ноутбука, так и на экране планшета, или телефона.

Есть поддержка темной и светлой темы:

Вторым важным отличием является архитектура расписания. Теперь это не монолит, а набор из нескольких сервисов.

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

Детали разработки

Новое расписание состоит из трех основных компонентов:

API – REST API предоставляет информацию в JSON-формате, разработан на ASP.NET Core 6
UI – новый адаптивный UI разработан на базе фреймворка react
Парсер – отвечает за подгрузку информации о расписании занятий из внутренней информационной системы КПИ, разработан на .NET 6
База данных – расписание использует собственную базу дынных, в котоорй хранится как актуаьное состояние расписания, так и исторические данные. В качестве СУБД была выбрана PostgreSQL.

Каждый сервис разворачивается в виде docker контейнера, что при необходимости облегчит процесс переноса на новый сервер, или дата-центр.

Внедрение REST API позволяет теперь использовать API расписания сторонним разработчикам. Так, например, одним из студентов КПИ было разработано мобильное приложение под iOS.

Open Source

Пользовательский интерфейс расписания доступен на GitHub в виде проекта с отрытым исходным кодом под лицензией BSD 3-Clause License.

Что дальше?

В планах на будущее:

интеграция расписания с системой "Электронный кампус КПИ"
экспорт расписания в календарь пользователя
доработка интерфейса
реализация других идей и предложений

Присоединяйтесь к разработке!

Чат "Электронный кампус"

2022-01-13T15:24:08.599Z

Чат "Электронный кампус" создан командой разработки проекта для оказания помощи пользователям системы.

Правила чата

Приветствуются вопросы "по делу";
Не приветствуется флуд и обсуждения на отвлеченные темы;
Запрещена нецензурная лексика, оскорбления, переход на личности;

Прежде чем задавать вопрос, убедитесь что его нет в разделе FAQ.

Если вы забыли пароль, предварительно воспользуйтесь системой восстановления пароля.

Полезные ссылки

👉🏻 Войти в чат

Отображение объявлений на главной странице

2022-01-10T12:27:06.502Z

Импортировано из старого блога. Оригинальная дата публикации – 24 мая 2019

С сегодняшнего дня, объявления будут доступны сразу на главной странице электронного кампуса:

Управление объявлениями пока остается в старой версии.

Вам кажется, что вы не можете войти в систему “Электронный кампус”. Что делать?

2022-01-10T12:20:35.449Z

Импортировано из старого блога. Оригинальная дата публикации – 24 мая 2019

Время от времени, мы получаем вопросы от пользователей, что делать, если после перехода на старую версию системы, отображается сообщение “Accessing error”?

Зачастую это происходит из-за проблем с обработкой cookies. Чтобы убедиться, что проблема действительно в этом, попробуйте открыть вкладку браузера в анонимном режиме (например, хорошо подходит для этого Chrome) и повторно пройдите авторизацию.

Если в анонимном режиме все работает корректно, тогда проблема однозначно связана с cookies-файлами и их нужно очистить.

Подробнее про работу с cookies-файлами в различных браузерах:

– Chrome

– Firefox

– Safari

– Edge

Обновление системы модуля авторизации электронного кампуса

2022-01-10T12:17:32.460Z

Импортировано из старого блога. Оригинальная дата публикации – 19 апреля 2019

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

Это самое крупное обновление системы за последнее время.

Почему мы это сделали

Ранее, за авторизацию отвечал модуль располагающийся по адресу login.kpi.ua. С момента его разработки прошло довольно большое время. При это возможности оперативно вносить изменения и закрывать уязвимости не было.

Старая система авторизации была написана на PHP версии 5.3, на которой и работала до вчерашнего дня. При этом, на сегодня, актуальная версия PHP — 7.3. Однако просто обновить версию PHP было невозможно — некоторые из частей модуля авторизации были завязаны на ту функциональность, которую новая версия PHP уже просто не поддерживает. Очевидно, что использование настолько старого ПО, уже само по себе чревато большим количеством уязвимостей.

В связи с этим, и было принято решение о замене системы авторизации.

Как авторизация работает теперь

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

Для справки: API реализован на базе ASP.NET Core 2.2 с использованием JWT-токенов для авторизации.

Помимо серверной части, обновлению подверглась и UI часть системы. Сейчас, при входе в кампус, вы попадете на новую страницу авторизации (на самом деле некоторые из вас уже видели эту страницу, однако она работала в тестовом режиме и не использовалась для входа в систему по умолчанию):

Успешно авторизовавшись, вы попадаете на дашборд, с которого можете перейти в: собственно в основное приложение электронного кампуса, редактор профиля, или просмотреть документацию к системе. Со временем, в новый интерфейс будут перенесены многие из модулей основной системы:

Немного технических деталей: новый UI реализован на базе фреймворка React, поддерживает адаптивность. Исходный код доступен в открытом доступе: https://github.com/kpi-ua/ecampus.kpi.ua

Почему эти изменение важны

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

Обратная связь

Мы всегда стараемся прислушиваться к нашим пользователям. В случае возникновения с проблем с авторизацией, или новым UI — вы всегда можете оставить свой багрепорт в репозитории проекта: https://github.com/kpi-ua/ecampus.kpi.ua/issues Пулреквесты также приветствуются! ;)

Также, мы всегда внимательно читаем все письма, которые приходят на нашу почту: ecampus@kpi.ua

Не забудьте ознакомиться с обновлениями лично!

Электронный кампус КПИ. Технологический стек.

2022-01-10T12:14:05.047Z

Импортировано из старого блога. Оригинальная дата публикации – 19 мая 2019 года.

Информационно-телекоммуникационная система «Электронный кампус» — прикладное программное обеспечение, которое является элементом информационно-телекоммуникационной среды университета и используется для информационной поддержки повседневной деятельности студентов, преподавателей, сотрудников университета, а так же для информационной поддержки всех видов инновационной деятельности в университете (далее ИТС ЭК).

ИТС ЭК объединяет внутренние информационные ресурсы (учебные, методические и другие), предоставляет централизованный доступ к ним на основе единых системных и технологических решений и обеспечивает их использование для эффективного управления и планирования научно-образовательным процессом.

Технологический стек

PHP 5.3 — скриптовый язык общего назначения, применяется для разработки веб-приложений. В настоящее время, актуально версией языка является PHP 7.1

Smarty — компилирующий обработчик шаблонов для PHP, один из инструментов, позволяющих отделить прикладную логику и данные от представления в духе концепции Model-view-controller.

Модуль авторизации электронного кампуса

Обновленный модуль авторизации позволяет пользователям электронного кампуса управлять своим аккаунтом (смена пароля, обновление персональных данных, обновление аватарки), восстановить утерянный пароль, а также авторизовываться в системе используя:

– имя пользователя и пароль;

– аккаунт Facebook, привязанный к тому же адресу электронной почты, что и указан в профиле пользователя;

– аккаунт в мессенджере телеграм.

Код модуля авторизации доступен на GithHub аккаунте КПИ.

Технологический стек

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

API системы «Электронный кампус» v3.0

API электронного кампуса позволяет реализовать интеграцию между электронным кампусом и другими системами КПИ (например проект directory.kpi.ua большую часть информации получает именно из API). Также, API используется разработчиками мобильных приложений для iOS и Android. API электронного кампуса реализовано на базе архитектуры — REpresentational State Transfer. Это архитектурный стиль взаимодействия компонентов распределённого приложения в сети, который представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой системы.

Технологический стек

ASP.NET Core 2.2 — кроссплатформенная, высокопроизводительная среда с открытым исходным кодом для создания современных облачных приложений.

JWT — открытый стандарт (RFC 7519) для создания токенов доступа, основанный на формате JSON. Используется для передачи данных для аутентификации в клиент-серверных приложениях. Токены создаются сервером, подписываются секретным ключом и передаются клиенту, который в дальнейшем использует данный токен для подтверждения своей личности.

Azure BLOB Storage — это высокомасштабируемое облачное хранилище, которое идеально подходит для хранения изображений, текстовых файлов и файлов c видео. В Azure BLOB Storage хранятся аватарки пользователей электронного кампуса.

Общие компоненты системы

MySQL — свободная реляционная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle. Капитан очевидность подсказывает, что в базе данных хранятся данные электронного кампуса.

nginx — веб-сервер общего назначения, который уже длительное время обслуживает серверы многих высоконагруженных проектов. Согласно статистике Netcraft nginx обслуживал или проксировал 26.22% самых нагруженных сайтов в апреле 2019 года.

Введение в OAuth 2

2021-11-21T16:27:27.043Z

Оригинальная публикации: https://www.digitalocean.com/community/tutorials/oauth-2-ru

Введение

OAuth 2 представляет собой фреймворк для авторизации, позволяющий приложениям осуществлять ограниченный доступ к пользовательским аккаунтам на HTTP сервисах, например, на Facebook, GitHub и DigitalOcean. Он работает по принципу делегирования аутентификации пользователя сервису, на котором находится аккаунт пользователя, позволяя стороннему приложению получать доступ к аккаунту пользователя. OAuth 2 работает в вебе, на десктопных и мобильных приложениях.

Эта статья предназначена для разработчиков приложений и предоставляет обзор ролей, типов авторизации и типичных сценариев использования OAuth 2.

Начнём с ролей OAuth!

Роли OAuth

OAuth определяет четыре роли:

Владелец ресурса
Клиент
Сервер ресурсов
Авторизационный сервер

Далее мы рассмотрим каждую из ролей.

Владелец ресурса: Пользователь

Владельцем ресурса является пользователь, который авторизует приложение для доступа к своему аккаунту. Доступ приложения к пользовательскому аккаунту ограничен “областью видимости” (scope) предоставленных прав авторизации (например, доступ на чтение или запись).

Сервер ресурсов / авторизации: API

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

С точки зрения разработчика приложения API сервиса одновременно выполняет и роль сервера ресурсов и роль сервера авторизации. Далее мы будем считать эти две роли одной, и называть её Сервис или API.

Клиент: Приложение

Клиентом является приложение, которое хочет осуществить доступ к аккаунту пользователя. Перед осуществлением доступа приложение должно быть авторизовано пользователем, а авторизация должна быть одобрена со стороны API.

Абстрактное описание протокола

Теперь, когда у нас есть представление о ролях, используемых в OAuth, рассмотрим диаграмму их взаимодействия друг с другом.

Рассмотрим описание последовательности шагов на этой диаграмме:

Приложение запрашивает у пользователя авторизацию на доступ к серверу ресурсов.
Если пользователь авторизует запрос, приложение получает разрешение на авторизацию (authorization grant).
Приложение запрашивает авторизационный токен у сервера авторизации (API) путём предоставления информации о самом себе и разрешении на авторизацию от пользователя.
Если подлинность приложения подтверждена и разрешение на авторизацию действительно, сервер авторизации (API) создаёт токен доступа для приложения. Процесс авторизации завершён.
Приложение запрашивает ресурс у сервера ресурсов (API), предоставляя при этом токен доступа для аутентификации.
Если токен действителен, сервер ресурсов (API) предоставляет запрашиваемый ресурс приложению.

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

Регистрация приложения

Перед тем, как начать использовать OAuth в вашем приложении, вам необходимо зарегистрировать своё приложения в сервисе. Это делается путём регистрации в разделе “developer” или “API” сайта сервиса, где вам необходимо предоставить следующую информацию (возможно, включая некоторые детали о вашем приложении):

Название приложения
Сайт приложения
Redirect URL или callback URL

Redirect URL - это URL, на который сервис будет перенаправлять пользователя после авторизации (или отказа в авторизации) вашего приложения.

Идентификатор клиента и секрет клиента

После регистрации приложения сервис создаст учётные данные клиента - идентификатор клиента (client ID) и секрет клиента (client secret). Идентификатор клиента представляет собой публично доступную строку, которая используется API сервиса для идентификации приложения, а также используется для создания авторизационных URL для пользователей. Секрет клиента используется для аутентификации подлинности приложения для API сервиса, когда приложение запрашивает доступ к аккаунту пользователя. Секрет клиента должен быть известен только приложению и API.

Разрешение на авторизацию

В абстрактном описании протокола выше первые четыре шага касаются вопросов создания разрешения на авторизацию и токена доступа. Тип разрешения на авторизацию зависит от используемого приложением метода запроса авторизации, а также от того, какие типы разрешения поддерживаются со стороны API. OAuth 2 определяет четыре разных типа, каждый из которых полезен в определённых ситуациях:

Код авторизации (Authorization Code): используется с серверными приложениями (server-side applications).
Неявный (Implicit): используется мобильными или веб-приложениями (приложения, работающие на устройстве пользователя).
Учётные данные владельца ресурса (Resource Owner Password Credentials): используются доверенными приложениями, например приложениями, которые являются частью самого сервиса.
Учётные данные клиента (Client Credentials): используются при доступе приложения к API.

Далее мы рассмотрим эти типы разрешения на авторизацию, примеры их использования.

Тип разрешения на авторизацию: Код авторизации

Код авторизации является одним из наиболее распространённых типов разрешения на авторизацию, поскольку он хорошо подходит для серверных приложений, где исходный код приложения и секрет клиента не доступны посторонним. Процесс в данном случае строится на перенаправлении (redirection), что означает, что приложение должно быть в состоянии взаимодействовать с пользовательским агентом (user-agent), например, веб-браузером, и получать коды авторизации API, перенаправляемые через пользовательский агент.

Опишем процесс на диаграмме:

Шаг 1: Ссылка с кодом авторизации

Сначала пользователю предоставляется ссылка следующего вида:

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

Рассмотрим компоненты ссылки:

https://cloud.digitalocean.com/v1/oauth/authorize: входная точка API авторизации (API authorization endpoint).
client_id=CLIENT_ID: идентификатор клиента приложения (с помощью этого идентификатора API понимает, какое приложение запрашивает доступ).
redirect_uri=CALLBACK_URL: URL, на который сервис перенаправит пользовательского агент (браузер) после выдачи авторизационного кода.
response_type=code: указывает на то, что приложение запрашивает доступ с помощью кода авторизации.
scope=read: задаёт уровень доступа приложения (в данном случае - доступ на чтение).

Шаг 2: Пользователь авторизует приложение

Когда пользователь нажимает на ссылку, он должен сперва осуществить вход в систему для подтверждения своей личности (если он, конечно, ещё не залогинен). После этого сервис предложит пользователю авторизовать или отказать в авторизации приложению для доступа к аккаунту пользователя. Пример такого диалога представлен ниже:

На этом скриншоте экрана авторизации DigitalOcean мы можем видеть, что приложение “Thedropletbook App” запрашивает доступ на чтение к аккаунту “manicas@digitalocean.com”.

Шаг 3: Приложение получает код авторизации

Если пользователь выбирает “Авторизовать приложение”, сервис перенаправляет пользовательский агент (браузер) по URL перенаправления (redirect URL), который был задан на этапе регистрации клиента (вместе с кодом авторизации). Ссылка будет выглядеть похожим образом (в данном примере приложение называется “dropletbook.com”):

https://dropletbook.com/callback?code=AUTHORIZATION_CODE

Шаг 4: Приложение запрашивает токен доступа

Приложение запрашивает токен доступа у API путём отправки авторизационного кода и аутентификационной информации (включая секрет клиента) сервису. Ниже представлен пример POST-запроса для получения токена DigitalOcean:

https://cloud.digitalocean.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

Шаг 5: Приложение получает токен доступа

Если авторизация прошла успешно, API возвращает токен доступа (а также, опционально, токен для обновления токена доступа - refresh token). Весь ответ сервера может выглядеть следующим образом:

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"mark@thefunkybunch.com"}}

Теперь приложение авторизовано! Оно может использовать токен для доступа к пользовательскому аккаунту через API сервиса с заданными ограничениями доступа до тех пор, пока не истечёт срок действия токена или токен не будет отозван. Если был создан токен для обновления токена доступа, он может быть использован для получения новых токенов доступа, когда истечёт срок действия старого токена.

Тип разрешения на авторизацию: Неявный

Неявный тип разрешения на авторизацию используется мобильными и веб-приложениями (приложениями, которые работают в веб-браузере), где конфиденциальность секрета клиента не может быть гарантирована. Неявный тип разрешения также основан на перенаправлении пользовательского агента, при этом токен доступа передаётся пользовательскому агенту для дальнейшей передачи приложению. Это, в свою очередь, делает токен доступным пользователю и другим приложениям на устройстве пользователя. Также при этом типе разрешения на авторизацию не осуществляется аутентификация подлинности приложения, а сам процесс полагается на URL перенаправления (зарегистрированный ранее в сервисе).

Неявный тип разрешения на авторизацию не поддерживает токены обновления токена доступа (refresh tokens).

Процесс выглядит следующим образом: приложение просит пользователя авторизовать себя, затем сервер авторизации передаёт токен доступа к пользовательскому агенту, который передаёт токен приложению. Далее мы опишем процесс в деталях.

Шаг 1: Ссылка для неявной авторизации

При неявном типа разрешения на авторизацию пользователю предоставляется ссылка, запрашивающая токен у API. Эта ссылка выглядит почти так же, как ссылка для предыдущего способа (с кодом авторизации), за исключением того, что запрашивается токен вместо кода (обратите внимание на response type “token”):

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

Шаг 2: Пользователь авторизует приложение

Шаг 3: Пользовательский агент получает токен доступа с URI перенаправления

Если пользователь выбирает “Авторизовать приложение”, сервис перенаправляет пользовательский агент по URI пренправления приложения и включает в URI фрагмент, содержащий токен доступа. Это выглядит примерно вот так:

https://dropletbook.com/callback#token=ACCESS_TOKEN

Шаг 4: Пользовательский агент следует по URI перенаправления

Пользовательский агент следует по URI перенаправления, сохраняя при этом токен доступа.

Шаг 5: Приложение выполняет скрипт извлечения токена доступа

Приложение возвращает веб-страницу, которая содержит скрипт для извлечения токен доступа из полного URI перенаправления, сохранённого пользовательским агентом.

Шаг 6: Токен доступа передаётся приложению

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

Тип разрешения на авторизацию: учётные данные владельца ресурса

При этом типе разрешения на авторизацию пользователь предоставляет приложению напрямую свои авторизационные данные в сервисе (имя пользователя и пароль). Приложение, в свою очередь, использует полученные учётные данные пользователя для получения токена доступа от сервиса. Этот тип разрешения на авторизацию должен использоваться только в том случае, когда другие варианты не доступны. Кроме того, этот тип разрешения стоит использовать только в случае, когда приложение пользуется доверием пользователя (например, является частью самого сервиса, или операционной системы пользователя).

Процесс с учётными данными владельца ресурса

После того, как пользователь передаст свои учётные данные приложению, приложение запросит токен доступа у авторизационного сервера. Пример POST-запроса может выглядеть следующим образом:

https://oauth.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

Если учётные данные корректны, сервер авторизации вернёт токен доступа приложению. Теперь приложение авторизовано!

Внимание: DigitalOcean в настоящее время не поддерживает тип разрешения на авторизацию с использованием учётных данных владельца ресурса, поэтому ссылка выше ведёт на воображаемый авторизационный сервер “oauth.example.com”.

Тип разрешения на авторизацию: Учётные данные клиента

Тип разрешения на авторизацию с использованием учётных данных клиента позволяет приложению осуществлять доступ к своему собственному аккаунту сервиса. Это может быть полезно, например, когда приложение хочет обновить собственную регистрационную информацию на сервисе или URI перенаправления, или же осуществлить доступ к другой информации, хранимой в аккаунте приложения на сервисе, через API сервиса.

Процесс с учётными данными клиента

Приложение запрашивает токен доступа путём отправки своих учётных данных, своего идентификатора клиента и секрета клиента авторизационному серверу. Пример POST-запроса может выглядеть следующим образом:

https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

Если учётные данные клиента корректны, авторизационный сервер вернёт токен доступа для приложения. Теперь приложение авторизовано для использования собственного аккаунта!

Пример использования токена доступа

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

Ниже представлен пример запроса к API с использованием curl. Обратите внимание, что он содержит токен доступа:

curl -X POST -H "Authorization: Bearer ACCESS_TOKEN""https://api.digitalocean.com/v2/$OBJECT"

Если токен доступа валиден, API обработает полученный запрос. Если срок действия токена доступа истёк или токен некорректен, API вернёт ошибку “invalid_request”.

Обновление токена доступа

После истечения срока действия токена доступа все запросы к API с его использованием будут возвращать ошибку “Invalid Token Error”. Если при создании токена доступа был создан и токен для обновления токена доступа (refresh token), последний может быть использован для получения нового токена доступа от авторизационного сервера.

Ниже представлен пример POST-запроса, использующего токен для обновления токена доступа для получения нового токена доступа:

https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

Заключение

На этом мы завершаем наш обзор OAuth 2. Теперь у вас есть общее представление о том, как работает OAuth 2, а также о том, когда и как использовать существующие типы разрешения на авторизацию.

Если вы хотите узнать больше об OAuth 2, рекомендуем ознакомиться со следующими статьями:

Миграция API системы электронный кампус на .NET 6

2021-11-18T15:40:17.782Z

8 ноября платформа .NET обновилась до шестой версии. Это важное событие, поскольку данная версия платформы является LTS-версией, что означает, что она будет поддерживаться довольно продолжительное время и будет считаться стандартной версией к распространению.

Использование LTS-версий компонентов программных систем в свою очередь позволяет уменьшить технический долг и облегчить поддержку таких системы в долгосрочной перспективе. Именно поэтому мы мигрировали API системы "Электронный кампус" на .NET 6 и будем использовать эту версию платформы до момента релиза следующей LTS-версии.

О новых возможностях .NET 6 можно детальнее узнать в этой публикации, а более подробно ознакомиться с жизненным циклом платформы .NET – здесь.

Сертификат *.kpi.ua может быть временно невалиден в ближайшие несколько дней.

2021-10-28T13:48:22.655Z

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

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

#кпи

#кпикампус

#ssl

#kpi