core войти с кодом

Core войти с кодом

Коротко: перейдите по ссылке, которую прислал учитель. Если учитель прислал код, то зайдите на сайт urok.io и введите код в специальное окно.

Дальше введите свои данные в окне авторизации (они должны быть полными и верными, иначе учитель не сможет опознать вас) и вуаля, урок открыт!

Если учитель прислал ссылку на урок (например, такую: https://coreapp.ai/app/player/lesson/5e778344bd6ed9bbdb651a2e/2), скопируйте и вставьте ее в адресную строку браузера.

В случае, если учитель прислал код урока (например, такой: OEUV), введите в адресную строку браузера адрес «urok.io». Откроется страница с полем для ввода текста, в которое нужно ввести код урока, который вы получили и нажать на кнопку «Перейти в урок».

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

Если регистрация на платформе CORE уже есть, то выберете «Войти со своим аккаунтом», укажите свой e-mail и пароль. Дальше нажмите на кнопку «Войти».

Если до этого на платформе не регистрировались, но решили это сделать, выберете «Создать аккаунт и войти».

Здесь нужно будет указать свой e-mail, придумать пароль, ввести свою фамилию и имя. Ознакомьтесь с пользовательским соглашением и кликнете на кнопку «Зарегистрироваться и войти». Для того чтобы подтвердить почту, нужно будет зайти в свой почтовый ящик. Там будет ждать письмо с инструкциями.

Если аккаунта на платформе CORE нет, но он и не нужен — не беда, выберете «Войти без регистрации». Здесь понадобится ввести свое имя и фамилию (обязательно записываем правильно!). Дальше нажимаем на кнопку «Начать урок».

Однако мы рекомендуем проходить регистрацию. Ведь если есть аккаунт, то все уроки, которые будет посылать учитель, сохранятся в личном кабинете. А если нет аккаунта, то и личного кабинета тоже нет!

Источник

Авторизация в ASP.NET Core MVC

В статье описаны паттерны и приемы авторизации в ASP.NET Core MVC. Подчеркну, что рассматривается только авторизация (проверка прав пользователя) а не аутентификация, поэтому в статье не будет использования ASP.NET Identity, протоколов аутентификации и т.п. Будет много примеров серверного кода, небольшой экскурс вглубь исходников Core MVC, и тестовый проект (ссылка в конце статьи). Приглашаю интересующихся под кат.

Claims

Принципы авторизации и аутентификации в ASP.NET Core MVC не изменились по сравнению с предыдущей версией фреймворка, отличаясь лишь в деталях. Одним из относительно новых понятий является claim-based авторизация, с нее мы и начнем наше путешествие. Что же такое claim? Это пара строк «ключ-значение», в качестве ключа может выступать «FirstName», «EmailAddress» и т.п. Таким образом, claim можно трактовать как свойство пользователя, как строку с данными, или даже как некоторое утверждение вида «у пользователя есть что-то«. Знакомая многим разработчикам одномерная role-based модель органично содержится в многомерной claim-based модели: роль (утверждение вида «у пользователя есть роль X«) представляет собой один из claim и содержится в списке преопределенных System.Security.Claims.ClaimTypes. Не возбраняется создавать и свои claim.

Следующее важное понятие — identity. Это единое утверждение, содержащее набор claim. Так, identity можно трактовать как цельный документ (паспорт, водительские права и др.), в этом случае claim — строка в паспорте (дата рождения, фамилия. ). В Core MVC используется класс System.Security.Claims.ClaimsIdentity.

Еще на уровень выше находится понятие principal, обозначающее самого пользователя. Как в реальной жизни у человека может быть на руках несколько документов одновременно, так и в Core MVC — principal может содержать несколько ассоциированных с пользователем identity. Всем известное свойство HttpContext.User в Core MVC имеет тип System.Security.Claims.ClaimsPrincipal. Естественно, через principal можно получить все claim каждого identity. Набор из более чем одного identity может использоваться для разграничения доступа к различным разделам сайта/сервиса.

На диаграмме указаны лишь некоторые свойства и методы классов из пространства имен System.Security.Claims.

Зачем это все нужно? При claim-based авторизации, мы явно указываем, что пользователю необходимо иметь нужный claim (свойство пользователя) для доступа к ресурсу. В простейшем случае, проверяется сам факт наличия определенного claim, хотя возможны и куда более сложные комбинации (задаваемые при помощи policy, requirements, permissions — мы подробно рассмотрим эти понятия ниже). Пример из реальной жизни: для управления легковым авто, у человека должны быть водительские права (identity) с открытой категорией B (claim).

Подготовительные работы

Здесь и далее на протяжении статьи, мы будем настраивать доступ для различных страниц веб-сайта. Для запуска представленного кода, достаточно создать в Visual Studio 2015 новое приложение типа «ASP.NET Core Web Application», задать шаблон Web Application и тип аутентификации «No Authentication».

При использовании аутентификации «Individual User Accounts» был бы сгенерирован код для хранения и загрузки пользователей в БД посредством ASP.NET Identity, EF Core и localdb. Что является совершенно избыточным в рамках данной статьи, даже несмотря на наличие легковесного EntityFrameworkCore.InMemory решения для тестирования. Более того, нам в принципе не потребуется библиотека аутентификации ASP.NET Identity. Получение principal для авторизации можно самостоятельно эмулировать in-memory, а сериализация principal в cookie возможна стандартными средствами Core MVC. Это всё, что нужно для нашего тестирования.

Для эмуляции хранилища пользователей достаточно открыть Startup.cs и зарегистрировать сервисы-заглушки во встроенном DI-контейнере:

Кстати, мы всего лишь проделали ту же работу, что проделал бы вызов AddEntityFrameworkStores :

Начнем с авторизации пользователя на сайте: на GET /Home/Login нарисуем форму-заглушку, добавим кнопку для отправки пустой формы на сервер. На POST /Home/Login вручную создадим principal, identity и claim (в реальном приложении эти данные были бы получены из БД). Вызов HttpContext.Authentication.SignInAsync сериализует principal и поместит его в зашифрованный cookie, который в свою очередь будет прикреплен к ответу веб-сервера и сохранен на стороне клиента:

Включим cookie-аутентификацию в методе Startup.Configure(app):

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

Атрибут Authorize и политики доступа

Атрибут [Authorize] никуда не делся из MVC. По-прежнему, при маркировке controller/action этим атрибутом — доступ внутрь получит только авторизованный пользователь. Вещи становятся интереснее, если дополнительно указать название политики (policy) — некоторого требования к claim пользователя:

Политики создаются в уже известном нам методе Startup.ConfigureServices :

Такая политика устанавливает, что попасть на страницу About сможет только авторизованный пользователь с claim-ом «age», при этом значение claim не учитывается. В следующем разделе, мы перейдем к примерам посложнее (наконец-то!), а сейчас разберемся, как это работает внутри?

[Authorize] — атрибут маркерный, сам по себе логики не содержащий. Нужен он лишь для того, чтобы указать MVC, к каким controller/action следует подключить AuthorizeFilter — один из встроенных фильтров Core MVC. Концепция фильтров та же, что и в предыдущих версиях фреймворка: фильтры выполняются последовательно, и позволяют выполнить код до и после обращения к controller/action. Важное отличие от middleware: фильтры имеют доступ к специфичному для MVC контексту (и выполняются, естественно, после всех middleware). Впрочем, грань между filter и middleware весьма расплывчата, так как вызов middleware возможно встроить в цепочку фильтров при помощи атрибута [MiddlewareFilter].

Вернемся к авторизации и AuthorizeFilter. Самое интересное происходит в его методе OnAuthorizationAsync:

Надеюсь, приведенные ссылки на исходный код дали вам представление об внутреннем устройстве фильтров в Core MVC.

Настройки политик доступа

Requirement — не более чем DTO для передачи параметров в соответствующий handler, который в свою очередь имеет доступ к HttpContext.User и волен налагать любые проверки на principal и содержащиеся в нем identity/claim. Более того, handler может получать внешние зависимости через встроенный в Core MVC DI-контейнер:

Регистрируем сам handler в Startup.ConfigureServices(), и он готов к использованию:

Resource-based авторизация

Как уже говорилось ранее, policy-based авторизация выполняется Core MVC в filter pipeline, т.е. ДО вызова защищаемого action. Успех авторизации при этом зависит только от пользователя — либо он обладает нужными claim, либо нет. А что, если необходимо учесть также защищаемый ресурс и его свойства, получить какие данные из внешних источников? Пример из жизни: защищаем action вида GET /Orders/ , считывающий по id строку с заказом из БД. Пусть наличие у пользователя прав на конкретный заказ мы сможем определить только после получения этого заказа из БД. Это автоматически делает непригодными рассмотренные ранее аспектно-ориентированные сценарии на основе фильтров MVC, выполняемых перед тем, как пользовательский код получает управление. К счастью, в Core MVC есть способы провести авторизацию вручную.

Затем создадим новую политику и handler:

Наконец, проверяем пользователя + ресурс на соответствие нужной политике внутри action (заметьте, атрибут [Authorize] больше не нужен):

У метода IAuthorizationService.AuthorizeAsync есть перегрузка, принимающая список из requirement — вместо названия политики:

Что позволяет еще более гибко настраивать права доступа. Для демонстрации, используем преопределенный OperationAuthorizationRequirement (да, этот пример перекочевал в статью прямо с docs.microsoft.com):

что позволит вытворять следующие вещи:

В методе HandleRequirementAsync(context, requirement, resource) соответствующего handler — нужно лишь проверить права соответственно операции, указанной в requirement.Name и не забыть вызвать context.Fail() если пользователь провалил авторизацию:

Handler будет вызван столько раз, сколько requirement вы передали в AuthorizeAsync и проверит каждый requirement по-отдельности. Для единовременной проверки всех прав на операции за один вызов handler — передавайте список операций внутри requirement, например так:

На этом обзор возможностей resource-based авторизации закончен, и самое время покрыть наши handler-ы тестами:

Авторизация в Razor-разметке

Выполняемая непосредственно в разметке проверка прав пользователя может быть полезна для скрытия элементов UI, к которым пользователь не должен иметь доступ. Конечно же, во view можно передать все необходимые флаги через ViewModel (при прочих равных я за этот вариант), либо обратиться напрямую к principal через HttpContext.User:

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

Permission-based авторизация. Свой фильтр авторизации

Декларативное перечисление всех запрашиваемых операций (в первую очередь из числа CRUD) при авторизации пользователя, такое как:

… имеет смысл, если в вашем проекте построена система персональных разрешений (permissions): имеется некий набор из большого числа высокоуровневых операций бизнес-логики, есть пользователи (либо группы пользователей), которым были в ручном режиме выданы права на конкретные операции с конкретным ресурсом. К примеру, у Васи есть права «драить палубу», «спать в кубрике», а Петя может «крутить штурвал». Хорош или плох такой паттерн — тема для отдельной статьи (лично я от него не в восторге). Очевидная проблема данного подхода: список операций легко разрастается до нескольких сотен даже не в самой большой системе.

Ситуация упрощается, если для авторизации нет нужды учитывать конкретный экземпляр защищаемого ресурса, и наша система обладает достаточной гранулярностью, чтобы просто навесить на весь метод атрибут со списком проверяемых операций, вместо сотен вызовов AuthorizeAsync в защищаемом коде. Однако, использование авторизации на основе политик [Authorize(Policy = «foo-policy»)] приведет к комбинаторному взрыву числа политик в приложении. Почему бы не использовать старую добрую role-based авторизацию? В примере кода ниже, пользователю необходимо быть членом всех указанных ролей для получения доступа к FooController:

Начнем с создания enum для операций, requirement и handler для проверки пользователя:

К счастью, в Core MVC эти проблемы легко разрешимы при помощи атрибута [TypeFilter]:

Мы получили полностью работающее, но безобразно выглядящее решение. Для того, чтобы скрыть детали реализации нашего фильтра от вызывающего кода, нам и пригодится атрибут [AuthorizePermission] :

Дополнительные материалы для чтения по теме (также приветствуются ваши ссылки для включения в список):

Источник

Создавать игры просто. Core – проблемная мечта Epic Games

В сентябре 2020 года Интернет внезапно наполнился 150-ю бесплатными ролевыми играми в сеттинге Dungeons & Dragons. Все они разрабатывались сообществом в рамках конкурса с использованием инструмента Core. Спустя несколько дней после окончания состязания Epic Games объявила о 15-миллионных инвестициях, а с 15 апреля Core можно скачать бесплатно в Epic Games Store.

Авторы обещают, что любой человек может самостоятельно создать игру в любом жанре с помощью простых средств и мощностей Unreal Engine и даже зарабатывать на этом деньги. Ну или бесплатно проводить время в тысячах игр сообщества. Подобный масштабный проект пытались реализовать многие студии, но большинству из них это пока не удалось. Чем же Core лучше предшественников?

Какую мечту продаёт Core?

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

«Ежедневно в Core появляется что-то новое для каждого игрока — от шутеров, игр на выживание и приключений до MMORPG, платформеров и игр для вечеринок».

«Публикация одной кнопкой позволяет легко делиться своей игрой, находить игроков и потенциально зарабатывать деньги».

Что предлагается?

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

Сердце Core – редактор, где собираются игровые сцены с сотнями объектов – фэнтезийных, научно-фантастических, масса компонентов, персонажей и звуков. С точки зрения организации он напоминает техническую подструктуру Unreal Engine, только в сильно упрощенной версии.

Если вы никогда не работали с движками и 3D-программами, то спешим расстроить – инструментарий Core требует пояснений и без базовых знаний английского не обойтись. На портале Core Academy есть текстовая документация, на YouTube-канале – поясняющие ролики, но нет доступного, пошагового обучения.

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

Как здесь заработать?

Прежде чем сделать первый шаг в Core, предлагается сразу же подписаться на рассылку новостей и получить два легендарных облика персонажа. Поиск игр осуществляется на экране, напоминающем YouTube или Twitch, где можно увидеть информацию о популярнейших играх, посмотреть рейтинги, определиться с жанром и так далее. Во внутреннем магазине можно купить валюту Core Credits. Вложившись, Epic хотела бы заработать на бесплатной программе.

И первый вопрос, который возникает, когда видишь внутриигровой магазин: «а не слишком ли рано пытаются пропихнуть реальные деньги в неокрепший продукт?». Но потом вспоминаешь современную индустрию и тяжело вздыхаешь.

Источник вдохновения Core найти несложно. Мгновенно вспоминается платформа Roblox, принадлежащая Roblox Corporation, которая оценивается в 38 миллиардов долларов. Это больше, чем вся Epic Games.

Так же как и Roblox, предполагается, что Core понравится детям и молодежи. Стиль Fortnite, эмоции, приятная музыка, масса бесплатных игр. В холле можно курсировать на крутом ховерборде, полетать, ознакомиться с названиями наиболее популярных проектов, включая «silent hill DEMO. » и «Doom (Alpha)». Следует понимать, что большинство игр – первые попытки 12-летних геймдизайнеров.

Почему мечта о сотнях качественных бесплатных игр (пока) не реализуема

Спустя несколько недель после релиза вряд ли кто-то ждал чего-то подобного Roblox, ведь она с 2006 года прошла долгий путь и приобретала популярность постепенно. Но всё же качество игр, мягко говоря, не сшибает с ног. Несмелые шаги сообщества вряд ли можно воспринимать всерьёз, а игры самой Manticore шаблонны: многопользовательский режим с захватом флага, симулятор фермы, стандартный шутер, королевская битва, простая стратегия.

Причин, почему проект в ближайшем будущем не выстрелит, немало. На старте Core сталкивается с теми же проблемами, что и другие похожие инструменты разработки, например, Dreams на PS4 или RPG Maker.

При использовании стандартных ресурсов игры выглядят, звучат и играются почти одинаково. Все они, за редким исключением, похожи на Fortnite. Да, в них можно интегрировать собственные 3D-модели, звуковые файлы и коды. Но, если у вас настолько большой опыт в разработке, то вы предпочтёте «без костылей» работать в Unreal Engine. Зачем вам слаборазвитая Core, если все права на ваш контент будут принадлежать владельцам?

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

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

А главная и очевидная причина – существование Roblox с развитой инфраструктурой и колоссальной аудиторией, которая способна развлечь и принести реальную прибыль. Каким образом Core собирается выделиться на фоне конкурента и выжить – непонятно.

Analysis

Core – интересная попытка Epic Games выстрелить на рынке с одним доминирующим продуктом. У авторов есть возможности мощнейшего и популярнейшего движка Unreal и кое-какое сообщество. Но будет ли оно настолько вдохновлено, чтобы создавать популярные игры внутри платформы – большой вопрос. Пока интересных проектов немного, также, как и руководств по их реализации.

Если у вас есть уйма свободного времени, нет опыта в создании игр, знаний языков программирования и вы не хотите сразу связываться с серьёзным движком, но есть интересные идеи и желание творить – Core может стать потенциально неплохим выбором. Здесь действительно можно быстро собрать игру с приемлемой графикой по заданному сценарию. Остановить вас может лишь один фактор – необходимость хотя бы поверхностно знать английский язык, ведь для азов придётся знакомиться с документацией и роликами официальных разработчиков.

Источник

Дидактор

педагогическая практика

CORE — отечественный конструктор интерактивных уроков

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

Core — это онлайн-платформа конструирования образовательных материалов и проверки знаний с обратной связью и электронным журналом.

Данный конструктор был создан в рамках проекта «Национальная Открытая Школа». С его помощью учитель может создавать интерактивные уроки, интерактивные рабочие листы.

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

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

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

Инструменты вашего урока находятся в левой части панели.

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

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

Сам инструмент тестирования довольно прост:

Между тем, имеются и другие инструменты для контроля и формирующего оценивания учащихся.

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

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

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

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

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

Упражнение. Данный инструмент позволяет ввести созданные вами в Learningapps интерактивные задания, дидактические игры. Конструктор интегрирован с контентом данного популярного сайта. Вам даже нет необходимости копировать html-код. Достаточно скопировать ссылку и любое задание появится на создаваемой вами странице в полном объёме.

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

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

Для работы учащимся вовсе не обязательно создавать свой аккаунт. Достаточно выбрать вариант Без регистрации. В таком случае обязательно потребуйте от ребят вписать имя и фамилию.

Учитель получает оперативную статистику о работе учеников.

Имеется возможность посмотреть результаты как по всему классу, так и по каждому ученику в отдельности.

Внимание!

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

Посмотрите мой небольшой набросок по ссылке. Имя и фамилию можно ввести вымышленные. Буду рад, если вы оставите свои комментарии в интерактивном задании или в ходе обсуждения статьи.

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

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

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

Комментарии к “ CORE — отечественный конструктор интерактивных уроков ”

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

Я бы с удовольствием приступила к освоению платформы, например, на площадке Летнего лагеря «Вместе — к успеху» https://docs.google.com/spreadsheets/d/1VEkuGx9tLRQkj3Z_JcpTjLd3hnwIPCWAt3Md1JijbgE/edit#gid=0

Добрый день! Почему-то в Вашем уроке, где нужно ввести названия городов-столиц, пишет, что «неправильно». Может в определённом порядке надо вводить?

Доброе утро, Надежда! Правильные ответы надо вводить по очереди. По одному. Затем проверять. Для ввода следующего правильного ответа щёлкаете «Попробовать ещё раз».

Вчера просто «запала» на CORE. Поняла, что буду использовать. И активно! Спасибо.

Источник