Market project - 1 // 프로젝트 생성과 회원 가입 - 권한 설정에 관해

단순 회원가입, 로그인보다 기능이 더 많은 프로젝트를 시작한다.

 

+ 주문, 주문 확인, 장바구니, 장바구니 확인 같은 세부 기능들이 추가되었다.

 

바로 이전에 진행했던 프로젝트를 토대로 작성해본다.

 

버전이 약간 다르므로 (JAVA 11, Spring boot 2.7.16) 차이가 있을 수 있으나 현재까지 다른 것은 느끼지 못했다.

 

하나의 궁금증이 생겼는데, 

---

 

회원가입을 진행할 때 권한을 설정하는 부분이 있다. 서비스 코드를 살펴보자.

 

 public CustomerDto register(CustomerDto customerDto) {
        checkUserInfo(customerDto.getCustomerName(), customerDto.getEmail(), customerDto.getPhoneNumber());

        Authority authority = Authority.builder()
                .authorityName("ROLE_USER").build();

        Customer customer = Customer.builder()
                .customerName(customerDto.getCustomerName())
                .password(passwordEncoder.encode(customerDto.getPassword()))
                .email(customerDto.getEmail())
                .phoneNumber(customerDto.getPhoneNumber())
                .authorities(Collections.singleton(authority)) // 특정한 요소를 가진 불변한 컬렉션
                .build();

        return CustomerDto.from(customerRepository.save(customer));
    }

 

CustomerDto를 통해 유저가 입력한 정보를 받아온다.

 

checkUserInfo를 통해 DB에 중복된 정보가 있는지 Repository에서 확인한다.

이름이 ROLE_USER인 권한 객체 Athority를 생성하고 - 보통 유저의 권한이 되겠다-

저장될 Customer 객체를 만들어준다.

 

여기서

.authorities(Collections.singleton(authority)) 가 사용되는데, 이전에 사용했던 권한 설정과는 좀 다른 모습이었다.

컬렉션이니 싱글톤이니 이상한 기능도 들어있고 해서 찾아보았는데, 단순히 그냥 컬렉션이라는 여러 요소들이 들어간 자료구조 하나를 만드는 것이었다.

 

Collections.singleton() 을 사용하면 주어진 요소로 이루어진 불변한 컬렉션 하나가 생성되는 것이다. 여기서는 ROLE_USER로 추가하였으므로 Authority 객체에 해당하는 부분, 엔티티 테이블도 함께 생성이 될 것이다. 

불변한- 을 사용하면 읽기 전용으로 안전하게 사용할 수 있겠다.

 

---

물론 builder() 부분의 권한 설정 .authority()는 다른 형태로도 지정할 수 있다.

 

1. String 형태

.authorities("ROLE_USER")

 

2. List 형태

.authorities(Arrays.asList("ROLE_USER", "ROLE_ADMIN"))

 

3. Set 형태

.authorities(new HashSet<>(Arrays.asList("ROLE_USER", "ROLE_ADMIN")))

 

4. GrantedAuthority 객체 사용

.authorities(new SimpleGrantedAuthority("ROLE_USER"))

 

5. 여러 권한 한번에 추가

.authorities("ROLE_USER", "ROLE_ADMIN")

 

등등 다양한 내용이 있을듯 하다. 자료구조에 대한 지식이 조금 부족한 것 같으니,

Set이나 List를 사용하는 이유에 대해서도 좀 알아보자.

 

Set

-> 중복을 허용하지 않고, 순서가 보장되지 않는 컬렉션

-> 각 요소는 유일해야 함, 중복을 방지할 때 필요

-> HashSet, TreeSet

 

List

-> 중복을 허용하고, 순서가 유지되는 컬렉션

-> 순서가 중요할 때

-> ArrayList, LinkedList

 

이 모든 것들을 포함한 Collection 인터페이스

->Set과 List는 모두 Collection 인터페이스를 확장한다.

 

다시 위의 Collections.singleton()으로 돌아가면, 이 메서드는 Set을 반환한다. 

Customer.java

 <...>
 
 @ManyToMany
    @JoinTable(name = "user_authority", joinColumns = {@JoinColumn(name = "customer_id", referencedColumnName = "cumstomer_id")},
    inverseJoinColumns = {@JoinColumn(name = "authority_name", referencedColumnName = "authority_name")})
    private Set<Authority> authorities;

 

권한은 중복이 되면 안되고 유일하게 존재해야 한다. Set을 사용하는것이 나쁘지 않다고 할 수 있겠다.

 

만약 중복을 허용하거나 순서가 중요하지 않다면 다른 컬렉션을 사용해도 무방하다.

 

---

 

이전 프로젝트들에서는 유저의 권한을 Enum클래스로 만들어 가져왔던 것 같은데, 그것도 연구해보면 응용이 가능 할 것 같다. 이번 프로젝트에서는 우선 Set을 이용한 권한설정을 사용해보자.

 

회원가입 로직은 간단하므로 생략하고 마무리한다.