Невозвратный my account html. WooCommerce

Из этого туториала вы узнаете, как управлять ссылками Моя учетная запись, Оформление заказа, Вход, Выход, Регистрация в Woocommerce.

WooCommerce. Как управлять ссылками Моя учетная запись, Оформление заказа, Вход, Выход, Регистрация

    Войдите в панель управления, перейдите в раздел Внешний вид (Appearance) -> Редактор (Editor ) , и откройте файл custom-function .php .

    Найдите соответствующую часть кода с помощью ключевого слова: $link_string_login (вы можете использовать поисковые функции браузера для того, чтобы найти код):


  1. $link_string_login = "Ваша ссылка";

    Пожалуйста, сверьтесь со скриншотом ниже. Вы увидите исходный и измененный код:


  2. $link_string_register определяет ссылку регистрации. Вы можете указать пользовательский вариант ссылки вместо оригинального. Это будет выглядеть следующим образом:

    $link_string_register = "Cust regisr";

    $link_string_logout = "Cust logout";

  3. Сохраните измененный файл custom-function .php . Отредактированный код должен выглядеть следующим образом:



  4. Для изменения ссылок перейдите в раздел Внешний вид (Appearance) -> Меню (Menus) . Выберите меню Магазин (Shop) и нажмите кнопку Выбрать (Select) :


  5. Эти пункты меню являются ссылками на страницы. Вы можете изменить содержание этих страниц или установить пользовательские ссылки. Мы удалили существующие пункты меню и создали вместо них новые пункты меню с пользовательскими ссылками:


  6. Сохраните изменения и обновите сайт. Мы отредактировали ссылки Доставка (Delivery), Оформление заказа (Checkout ) и Учетная запись (My Account) :


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

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

Что это?

Авторизация - это процесс предоставления доступа к контроллерам и методам действий для определенных пользователей, как правило, находящихся в определенных ролях (например, допуск к админке должны иметь только администраторы).

Зачем нужно использовать?

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

Как использовать в рамках MVC?

Добавление поддержки ролей

ASP.NET Identity содержит строго типизированный базовый класс для доступа и управления ролями, который называется RoleManager , где T является реализацией интерфейса IRole , описывающего механизм хранения данных, используемых для представления ролей. Entity Framework использует класс IdentityRole , являющийся реализацией интерфейса IRole и содержит следующие свойства:

Мы не будем использовать напрямую объекты IdentityRole в нашем приложении, вместо этого добавьте файл класса AppRole.cs в папку Models со следующим содержимым:

Using Microsoft.AspNet.Identity.EntityFramework; namespace Users.Models { public class AppRole: IdentityRole { public AppRole() : base() { } public AppRole(string name) : base(name) { } } }

Класс RoleManager работает с экземплярами IRole с помощью методов и свойств, перечисленных в таблице ниже:

Эти базовые методы реализуют тот же базовый шаблон, который использует класс UserManager для управления пользователями. Добавьте файл AppRoleManager.cs в папку Infrastructure со следующим содержимым:

Using Microsoft.AspNet.Identity; using Microsoft.AspNet.Identity.EntityFramework; using Microsoft.AspNet.Identity.Owin; using Microsoft.Owin; using System; using Users.Models; namespace Users.Infrastructure { public class AppRoleManager: RoleManager, IDisposable { public AppRoleManager(RoleStore store) : base(store) { } public static AppRoleManager Create(IdentityFactoryOptions options, IOwinContext context) { return new AppRoleManager(new RoleStore(context.Get())); } } }

Этот класс определяет статический метод Create(), который позволит OWIN создавать экземпляры класса AppRoleManager для всех запросов, где требуются данные Identity, не раскрывая информации о том, как данные о ролях хранятся в приложении. Чтобы зарегистрировать класс управления ролями в OWIN, необходимо отредактировать файл IdentityConfig.cs, как показано в примере ниже:

// ... namespace Users { public class IdentityConfig { public void Configuration(IAppBuilder app) { // ... app.CreatePerOwinContext(AppRoleManager.Create); // ... } } }

Это гарантирует, что экземпляры класса AppRoleManager используют тот же контекст базы данных Entity Framework, что и экземпляры AppUserManager.

Создание и удаление ролей

Мы подготовили базовую инфраструктуру для работы с ролями, давайте теперь создадим средство администрирования для работы с ролями. Сначала давайте определим методы действия и представления для управления ролями. Добавьте контроллер RoleAdmin в проект приложения с кодом, показанным в примере ниже:

Using System.Web; using System.Web.Mvc; using System.Threading.Tasks; using Microsoft.AspNet.Identity; using Microsoft.AspNet.Identity.Owin; using System.ComponentModel.DataAnnotations; using Users.Infrastructure; using Users.Models; namespace Users.Controllers { public class RoleAdminController: Controller { private AppUserManager UserManager { get { return HttpContext.GetOwinContext().GetUserManager(); } } private AppRoleManager RoleManager { get { return HttpContext.GetOwinContext().GetUserManager(); } } public ActionResult Index() { return View(RoleManager.Roles); } public ActionResult Create() { return View(); } public async Task Create(string name) { if (ModelState.IsValid) { IdentityResult result = await RoleManager.CreateAsync(new AppRole(name)); if (result.Succeeded) { return RedirectToAction("Index"); } else { AddErrorsFromResult(result); } } return View(name); } public async Task Delete(string id) { AppRole role = await RoleManager.FindByIdAsync(id); if (role != null) { IdentityResult result = await RoleManager.DeleteAsync(role); if (result.Succeeded) { return RedirectToAction("Index"); } else { return View("Error", result.Errors); } } else { return View("Error", new string { "Роль не найдена" }); } } private void AddErrorsFromResult(IdentityResult result) { foreach (string error in result.Errors) { ModelState.AddModelError("", error); } } } }

Здесь мы применили многие из тех приемов, что использовали в контроллере Admin, в том числе добавили свойства UserManager и RoleManager для более быстрого запроса объектов AppRoleManager и AppUserManager. Также мы добавили аналогичный метод AddErrorsFromResult(), который обрабатывает ошибки в объекте IdentityResult и добавляет их в метаданные модели.

Представления для контроллера RoleAdmin содержат простую HTML-разметку и операторы Razor. Нам необходимо отобразить не только список ролей, но и имена всех пользователей, входящих в каждую роль. Класс IdentityRole определяет свойство Users, которое возвращает коллекцию объектов IdentityUserRole , описывающих пользователей роли. Каждый объект IdentityUserRole имеет свойство UserId, которое возвращает уникальный идентификатор пользователя, с помощью которого мы будем получать имя пользователя.

Добавьте файл класса IdentityHelpers.cs в папку Infrastructure со следующим содержимым:

Using System.Web; using System.Web.Mvc; using Microsoft.AspNet.Identity.Owin; namespace Users.Infrastructure { public static class IdentityHelpers { public static MvcHtmlString GetUserName(this HtmlHelper html, string id) { AppUserManager mgr = HttpContext.Current .GetOwinContext().GetUserManager(); return new MvcHtmlString(mgr.FindByIdAsync(id).Result.UserName); } } }

Этот код содержит определение вспомогательного метода HTML , определенного как расширение класса HtmlHelper. Метод GetUserName() принимает строковый аргумент, содержащий идентификатор пользователя, получает экземпляр класса AppUserManager с помощью метода GetOwinContext().GetUserManager() (где метод GetOwinContext является расширяющим HttpContext), использует метод FindByIdAsync(), чтобы найти экземпляр AppUser, связанный с идентификатором и возвращает значение свойства UserName.

Следующий пример показывает содержимое файла Index.cshtml, находящегося в папке /Views/RoleAdmin:

@using Users.Models @using Users.Infrastructure @model IEnumerable @{ ViewBag.Title = "Роли"; }

Roles
@if (Model.Count() == 0) { } else { foreach (AppRole role in Model) { } }
ID Название Пользователи
Нет ролей
@role.Id @role.Name @if (role.Users == null || role.Users.Count == 0) { @: Нет пользователей в этой роли } else {

@string.Join(", ", role.Users.Select(x => Html.GetUserName(x.UserId)))

}
@using (Html.BeginForm("Delete", "RoleAdmin", new { id = role.Id })) { @Html.ActionLink("Изменить", "Edit", new { id = role.Id }, new { @class = "btn btn-primary btn-xs", style= "float:left; margin-right:5px" }) }
@Html.ActionLink("Создать", "Create", null, new { @class = "btn btn-primary" })

В этом представлении отображается список ролей, определенных в приложении, вместе со списком пользователей в каждой роли. На данный момент мы еще не создали ни одной роли:

Следующий пример содержит представление Create.cshtml в той же папке, которое используется для создания новых ролей:

@model string @{ ViewBag.Title = "Создание роли"; }

Создать роль

@Html.ValidationSummary(false) @using (Html.BeginForm()) {

Единственная информация, которая требуется для создания новой роли - ее название. Поэтому мы добавили один стандартный элемент и кнопку отправки формы POST-методу действия Create.

Чтобы протестировать функционал создания ролей, запустите приложение и перейдите по адресу /RoleAdmin/Index в окне браузера. Чтобы создать новую роль нажмите кнопку «Создать», введите имя в поле ввода в появившейся форме и нажмите вторую кнопку «Создать». Новое представление будет отображать список ролей, сохраненных в базе данных:

Вы можете также удалить роль из приложения нажав кнопку «Удалить».

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

Для авторизации пользователей недостаточно просто создавать и удалять роли. Мы также должны уметь управлять ролями, назначать и удалять пользователей из роли. Это не сложный процесс, но для его реализации нам необходимо загружать данные о ролях с помощью класса AppRoleManager, а затем вызывать методы, определенные в классе AppUserManager на объектах, связанных с определенной ролью.

Давайте начнем с добавления новых классов модели-представления (view-model) в файл UserViewModels.cs:

Using System.Collections.Generic; using System.ComponentModel.DataAnnotations; namespace Users.Models { public class CreateModel { // ... } public class LoginViewModel { // ... } public class RoleEditModel { public AppRole Role { get; set; } public IEnumerable Members { get; set; } public IEnumerable NonMembers { get; set; } } public class RoleModificationModel { public string RoleName { get; set; } public string IdsToAdd { get; set; } public string IdsToDelete { get; set; } } }

Класс RoleEditModel содержит информацию о роли и определяет список пользователей в роли в виде коллекции объектов AppUser. Благодаря этому, мы сможем извлечь ID и имя каждого пользователя в роли. Класс RoleModificationModel будет получать данные от системы привязки модели во время редактирования данных пользователя. Он содержит массив идентификаторов пользователей, а не объектов AppUser, для замены ролей.

Определившись с классами моделей, давайте добавим методы редактирования ролей Edit в контроллер RoleAdmin:

Using System.Web; using System.Web.Mvc; using System.Threading.Tasks; using Microsoft.AspNet.Identity; using Microsoft.AspNet.Identity.Owin; using System.ComponentModel.DataAnnotations; using Users.Infrastructure; using Users.Models; using System.Linq; using System.Collections.Generic; namespace Users.Controllers { public class RoleAdminController: Controller { // ... public async Task Edit(string id) { AppRole role = await RoleManager.FindByIdAsync(id); string memberIDs = role.Users.Select(x => x.UserId).ToArray(); IEnumerable members = UserManager.Users.Where(x => memberIDs.Any(y => y == x.Id)); IEnumerable nonMembers = UserManager.Users.Except(members); return View(new RoleEditModel { Role = role, Members = members, NonMembers = nonMembers }); } public async Task Edit(RoleModificationModel model) { IdentityResult result; if (ModelState.IsValid) { foreach (string userId in model.IdsToAdd ?? new string { }) { result = await UserManager.AddToRoleAsync(userId, model.RoleName); if (!result.Succeeded) { return View("Error", result.Errors); } } foreach (string userId in model.IdsToDelete ?? new string { }) { result = await UserManager.RemoveFromRoleAsync(userId, model.RoleName); if (!result.Succeeded) { return View("Error", result.Errors); } } return RedirectToAction("Index"); } return View("Error", new string { "Роль не найдена" }); } } }

Большая часть кода в GET-версии метода Edit отвечает за формирование списков пользователей входящих и не входящих в роль и реализуется с помощью методов LINQ. После группировки пользователей возвращается представление, которому передается объект RoleEditModel.

POST-версия метода Edit отвечает за добавление и удаление пользователей из ролей. Класс AppUserManager наследует ряд вспомогательных методов для работы с ролями из класса UserManager. Эти методы перечислены в таблице ниже:

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

В примере ниже показан код представления Edit.cshtml, находящегося в папке /Views/RoleAdmin.cshtml:

@using Users.Models @model RoleEditModel @{ ViewBag.Title = "Изменить роль"; }

Изменить роль

@Html.ValidationSummary() @using (Html.BeginForm()) {
Добавить в роль @Model.Role.Name
@if (Model.NonMembers.Count() == 0) { } else { foreach (AppUser user in Model.NonMembers) { } }
Все пользователи в роли
User ID Добавить в роль
@user.UserName
Удалить из роли @Model.Role.Name
@if (Model.Members.Count() == 0) { } else { foreach (AppUser user in Model.Members) { } }
Нет пользователей в роли
User ID Удалить из роли
@user.UserName
@Html.ActionLink("Отмена", "Index", null, new { @class = "btn btn-default" }) }

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

Давайте протестируем функциональность редактирования ролей. Добавление класса AppRoleManager в архитектуру OWIN заставит Entity Framework удалить базу данных и воссоздать новую схему. Это означает, что пользователи, которых мы создали ранее исчезнут. Поэтому после запуска приложения перейдите по адресу /Admin/Index и создайте нескольких пользователей.

Чтобы проверить редактирование ролей, перейдите по адресу /RoleAdmin/Index и создайте несколько ролей, затем отредактируйте эти роли, добавив в них нескольких пользователей. На рисунке ниже показан пример приложения (я создал роль Users):

Использование ролей для авторизации

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

Public class AccountController: Controller { // ... public ActionResult Logout() { AuthManager.SignOut(); return RedirectToAction("Index", "Home"); } // ... }

Давайте обновим контроллер Home и добавим новый метод действия, который будет передавать информацию об аутентифицированном пользователе в представление:

Using System.Collections.Generic; using System.Web.Mvc; namespace Users.Controllers { public class HomeController: Controller { public ActionResult Index() { return View(GetData("Index")); } public ActionResult OtherAction() { return View("Index", GetData("OtherAction")); } private Dictionary GetData(string actionName) { Dictionary dict = new Dictionary(); dict.Add("Action", actionName); dict.Add("Пользователь", HttpContext.User.Identity.Name); dict.Add("Аутентифицирован?", HttpContext.User.Identity.IsAuthenticated); dict.Add("Тип аутентификации", HttpContext.User.Identity.AuthenticationType); dict.Add("В роли Users?", HttpContext.User.IsInRole("Users")); return dict; } } }

В этом примере мы оставили атрибут Authorize для метода действия Index без изменений, но добавили этот атрибут к методу OtherAction, задав при этом свойство Roles, ограничивающее доступ к этому методу только для пользователей, являющихся членами роли Users. Мы также добавили метод GetData(), который добавляет некоторую базовую информацию о пользователе, используя свойства, доступные через объект HttpContext.

В заключение, нам необходимо добавить кнопку выхода из приложения в представление Index.cshtml из папки /Views/Home:

... @Html.ActionLink("Выйти", "Logout", "Account", null, new {@class = "btn btn-primary"})

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

Для тестирования системы авторизации, запустите приложение и перейдите по адресу /Home/Index. Браузер будет перенаправлен на страницу входа в приложение, где вы должны будете ввести данные существующей учетной записи. Метод действия Index является доступным для любого авторизованного пользователя. Однако если вы перейдете по адресу /Index/OtherAction, доступ будет открыт только тем пользователям, которые являются членами роли Users.

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

Public class AccountController: Controller { public ActionResult Login(string returnUrl) { if (HttpContext.User.Identity.IsAuthenticated) { return View("Error", new string { "В доступе отказано" }); } ViewBag.returnUrl = returnUrl; return View(); } // ... }

На рисунке ниже наглядно показано поведение нашего приложения, когда пользователю отказано в доступе:

My Account enables you to view and update your personal settings, modify your Site24x7 account settings and also control your organizational information. All your account information are categorized under three different sections, viz., Personal Settings, Account Settings, and Organization Settings. Based on your user privileges , you can view and modify your account settings.

  1. Login to Site24x7 client .
  2. Navigate to Admin > My Account .
  3. You"re redirected to your My Accounts screen now.

How Can I Update...

Personal Settings

Site24x7 uses Zoho Accounts, a service for single-sign-on to handle your personal account settings. You can gain insight and modify your critical personal information like: Site24X7 account name and email address, Site24x7 user role , and allowed groups . You can make the following changes as part of your Personal Settings:


Account Settings


Organization Information

To perform any actions like modifying the name of your organization, inviting new users to join your account, deleting email addresses from your account, or even deleting your organization account requires you to contact .

  1. Click Admin > My Account.
  2. You can view and update your organization settings. Your organization name and organization super admin email address are listed here.

Enable Two Factor Authentication

Restrict IP Address

Set up Single Sign-On (SSO) for Site24x7 with SAML based Authentication

What is SSO?

Before understanding what Single Sign-On is we must go through how traditional authentication works.

  1. A service will present the user with a login page where the user must submit a set of login credentials i.e., username and passwords. Some services might ask for more authentication information such as a one-time password.
  2. The credentials submitted by the user are validated against the ones present in the database at the service.

Traditional authentication is quite intuitive; everything is managed within the service, providing a simple way for users to authenticate. However, if a user needs to access multiple applications with a different set of login credentials for each application, it quickly turns cumbersome for the user. The user must remember multiple credentials and comply with different password policies.

Single Sign-On is a feature which lets you access Site24x7 as well as third-party applications with a single submission of user credentials. Users aren"t required to remember an array of usernames and passwords for each application they need access to. Site24x7 is a service by Zoho, and use Zoho Accounts for SSO using SAML.

What is SAML?

SAML - Security Assertion Markup Language , developed by the Security Services Technical Committee of "Organization for the Advancement of Structured Information Standards" (OASIS), is an XML-based framework for exchanging user authentication, entitlement, and attribute information. SAML is a derivative of XML. The purpose of SAML is to enable Single Sign-On for web applications across various domains and services.