에서 역할 기반 인증NET Core 3.1
This tutorial series is now also available as an online video course. You can watch the first hour on YouTube or get the complete course on Udemy. Or you just keep on reading. Enjoy! :)
에서 역할 기반 인증NET Core 3.1
소개
당신은 이미 그것을 요구했기 때문에, 그것은 역할에 기초한 신분 검증입니다.
이 장에서 귀하는 User
에 캐릭터를 추가하고 이 캐릭터를 읽으며 서비스의 행동을 변경하고 [Authorize]
속성을 확장하는 방법을 배울 것입니다.
더 구체적으로 말하자면, 우리는 GetAllCharacters()
방법의 행위를 변경할 것이다.
현재 사용자는 자신이 만든 문자만 볼 수 있지만, 사용자가 Admin
역할을 가지고 있다면 사용자마다 모든 문자를 볼 수 있습니다.
이를 실현하기 위해서 우리는 먼저 User
클래스에 새로운 속성을 추가하고 다른 이동을 실행하며 JSON 웹 영패에 새로운 Claim
을 추가한 다음에 새로운 Claim
을 읽어서 사용자가 무엇을 볼 수 있는지 결정합니다.
시작합시다.
새 사용자 속성: 캐릭터 & 새로운 이동
우선, User
은 Role
이라는 새로운 속성, 즉 string
을 획득했습니다.
그 밖에 우리는 이 속성에 [Required]
이라는 속성을 추가했다.
이를 실현하기 위해서는 System.ComponentModel.DataAnnotations
using 지령이 필요합니다.
public class User
{
public int Id { get; set; }
public string Username { get; set; }
public byte[] PasswordHash { get; set; }
public byte[] PasswordSalt { get; set; }
public List<Character> Characters { get; set; }
[Required]
public string Role { get; set; }
}
[Required]
속성을 사용하여 실체 프레임워크에 이 속성이null일 수 없음을 알려 줍니다.따라서 우리는 캐릭터에 대한 값을 설정해야 한다.이 속성은 string
이기 때문에 기본값은 빈 문자열일 뿐입니다.
이를 변경하고 기본값을 Player로 설정합니다.우리는 DataContext
방법의 OnModelCreating()
종류에서 이렇게 한다.User
실체에 대해 우리는 방법 Role
을 사용하여 속성 HasDefaultValue()
의 기본값을 설정합니다.
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<CharacterSkill>()
.HasKey(cs => new { cs.CharacterId, cs.SkillId });
modelBuilder.Entity<User>()
.Property(user => user.Role).HasDefaultValue("Player");
}
이제 다른 마이그레이션을 실행할 때 이미 존재하는 모든 사용자는 "Player"역할을 받게 되고, 모든 새 사용자도 이 역할을 받게 됩니다.dotnet ef migrations add Role
으로 다른 마이그레이션을 추가합니다.
이 새 마이그레이션의 Up()
방법에서 보듯이 새 열이 추가되었습니다. 이 열은 null이 될 수 없고 기본값인 "Player"가 있습니다.너무 좋아요.
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Role",
table: "Users",
nullable: false,
defaultValue: "Player");
}
dotnet ef database update
으로 데이터베이스를 업데이트하겠습니다.
완료되면 데이터베이스에 있는 각 사용자의 새 열과 "Player"역할을 볼 수 있습니다.
Postman에 새 사용자를 등록하면 새 사용자라도 이 역할을 받게 됩니다.
완벽했어지금까지 이것은 실행 가능한 것이다.현재 우리는 이 역할을 사용자의 영패에 추가해야 한다.
다른 선언으로 JSON 웹 토큰을 확장합니다.
이 캐릭터를 사용자의 영패에 추가하는 것은 사실상 상당히 간단하다.우리가 추가해야 할 것은 단지 새로운 Claim
일 뿐이다.
따라서 AuthRepository
방법 중의 CreateToken()
에서 우리는 새로운 Claim
을 claims
목록에 추가합니다.
유형은 ClaimTypes.Role
이고 값은 사용자 대상의 새로운 Role
속성입니다.
private string CreateToken(User user)
{
List<Claim> claims = new List<Claim>
{
new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
new Claim(ClaimTypes.Name, user.Username),
new Claim(ClaimTypes.Role, user.Role)
};
// ...
그렇습니다.
하지만 이게 정말 효과가 있는지 봅시다.
우리는 사용자에게 로그인해서 생성된 영패를 복사하고 브라우저에서 jwt.io의 디버거를 사용합니다.
우리는 영패를 붙일 수 있는데, 실제로 우리는 새로운 성명을 보았다.사용자의 역할은'유저'입니다.
아름답다이제 서비스의 행동을 변경하고 특정 역할에 대한 접근을 제한함으로써 이 새로운 기능을 완성합시다.
컨트롤러 액세스 제한 및 서비스 동작 변경
목표는 GetAllCharacters()
중 CharacterService
방법을 변경하는 행위입니다.
그 전에, 나는 당신에게 방법이나 전체 종류에 대한 접근을 어떻게 제어하는지 보여 주고 싶습니다.CharacterController
에서 [Authorize]
속성을 사용하고 있습니다.따라서 인증된 사용자만 이 컨트롤러에 접근할 수 있습니다.
접근을 더욱 제한하기 위해서, 우리는 간단하게 이 속성에'캐릭터', 예를 들어'유저'캐릭터를 추가할 수 있다.
[Authorize(Roles = "Player")]
[ApiController]
[Route("[controller]")]
public class CharacterController : ControllerBase
{
// ...
현재, 이것은 우리가 신분 검증을 거친testuser의 어떤 내용도 바꾸지 않기 때문에, 데이터베이스에서 이 사용자에게 수동으로 "Admin"역할을 지정하도록 합니다.
우리는 새 영패를 얻기 위해 Postman을 사용하여 다시 사용자에게 로그인해야 합니다. 그리고 이 영패를 사용하여 사용자의 모든 문자를 받아야 합니다.
그러나 보시다시피 이것은 불가능하다.우리는 403 금지를 받았다.
이제 [Authorize]
속성에 캐릭터 "Admin"을 추가합니다.우리는 간단하게 쉼표와 두 번째 캐릭터를 추가함으로써 이 점을 실현할 수 있다.
[Authorize(Roles = "Player,Admin")]
우리가 지금 사용자의 역할을 보고 싶을 때, 그것은 확실히 작용한다.
그러나 우리는 진정으로 관리자 역할을 이용해야 한다.
간단한'유저'는 그들이 창조한 캐릭터만 볼 수 있다.관리자는 모든 문자를 보아야 한다.CharacterService
으로 넘어가서 GetUserRole()
이라는 작은 방법을 추가합니다. 방법GetUserId()
과 유사합니다.
이번 반환 유형만 string
입니다. 클레임 유형 Role
의 값이 필요합니다.
private string GetUserRole() => _httpContextAccessor.HttpContext.User.FindFirstValue(ClaimTypes.Role);
그래현재 GetAllCharacters()
방법에서, 사용자 역할이 "Admin"과 같은지 확인하고, 만약 그렇다면, 우리는 모든 문자를 되돌려주고, 그렇지 않다면, 우리는 낡은 줄을 사용하고, 거기에서 User.Id
을 통해 문자를 필터합니다.
List<Character> dbCharacters =
GetUserRole().Equals("Admin") ?
await _context.Characters.ToListAsync() :
await _context.Characters.Where(c => c.User.Id == GetUserId()).ToListAsync();
우리가 포스트맨으로 다시 테스트할 때, 우리는 심지어 다른 사용자의 역할을 얻을 수 있다.이것이 바로 우리가 원하는 것이다.
그래서 좋다. 이것이 바로 캐릭터 기반의 신분 검증을 추가하는 방식이다.
예전과 같이 당신은 상응하는 GitHub repository에서 원본 코드를 얻을 수 있습니다. 만약에 더 많은 기능 요구나 문제가 있으면 언제든지 저에게 연락하십시오.
다음에 봐요!
그림은 코네코바에서 freepik.com에 만들어졌습니다.
하지만 잠깐만, 더 있어!
public class User
{
public int Id { get; set; }
public string Username { get; set; }
public byte[] PasswordHash { get; set; }
public byte[] PasswordSalt { get; set; }
public List<Character> Characters { get; set; }
[Required]
public string Role { get; set; }
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<CharacterSkill>()
.HasKey(cs => new { cs.CharacterId, cs.SkillId });
modelBuilder.Entity<User>()
.Property(user => user.Role).HasDefaultValue("Player");
}
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Role",
table: "Users",
nullable: false,
defaultValue: "Player");
}
private string CreateToken(User user)
{
List<Claim> claims = new List<Claim>
{
new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
new Claim(ClaimTypes.Name, user.Username),
new Claim(ClaimTypes.Role, user.Role)
};
// ...
[Authorize(Roles = "Player")]
[ApiController]
[Route("[controller]")]
public class CharacterController : ControllerBase
{
// ...
[Authorize(Roles = "Player,Admin")]
private string GetUserRole() => _httpContextAccessor.HttpContext.User.FindFirstValue(ClaimTypes.Role);
List<Character> dbCharacters =
GetUserRole().Equals("Admin") ?
await _context.Characters.ToListAsync() :
await _context.Characters.Where(c => c.User.Id == GetUserId()).ToListAsync();
Reference
이 문제에 관하여(에서 역할 기반 인증NET Core 3.1), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/_patrickgod/role-based-authentication-in-net-core-3-1-190g텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)