[Step2] 로그인 기능을 구현한다.

[devjun10]

📝 구현 내용

구현한 내용은 다음과 같습니다. 회원정보 상세보기는 아직 HTML 페이지가 완성되지 않아, 조금 더 다듬고 올리도록 하겠습니다.

• 로그인 기능 구현.
• Session 만료시간 관리.
• 회원정보 상세보기
• 사용자 탈퇴/삭제
• Jacoco / Sonarqube 적용

✨ 로그인

세션은 애플리케이션 내부에 저장했으며, 이는 SessionManager를 통해 관리됩니다.

public interface SessionManager {
    Session createSession(Long userId);
}

@Component
public class SessionStore implements SessionManager {

    private static final int FIFTEEN_MINUTES = 15;
    private static final Map<Long, Session> factory = new ConcurrentHashMap<>();

    @Override
    public Session createSession(Long userId) {
        String uuid = randomUUID().toString();
        LocalDateTime after15Minutes = now().plusMinutes(FIFTEEN_MINUTES);

        Session newSession = new Session(userId, uuid, after15Minutes);
        factory.put(userId, newSession);
        return newSession;
    }
}

세션 만료 시간을 관리하는 요구사항이 있었기 때문에, 이는 세션 클래스 내부에 만료 시간을 두어 세션을 처리할 수 있도록 했습니다.

public class Session {

    private final Long userId;
    private final String sessionId;
    private final LocalDateTime expired;

    ......

}

🔎 Nio2EndPoint

스프링에서 사용자 요청이 서블릿 컨테이너에 도달하기 전, 다음과 같은 과정을 거칩니다. 이는 비동기로 이루어지는데, 이전에 구현한 내용은 동기적으로 모든 것을 처리했습니다.

1. Acceptor
2. Poller
3. Executors
4. Http11Processor
5. CoyoteAdaptor
6. Servlet Container

따라서 이를 개선하기 위해 다음과 같이 Channel, Selector 등 NIO의 구성요소를 이용해, 사용자 요청이 비동기적으로 처리되도록 바꾸고 있습니다. 이 부분은 어느 선까지 구현해야 할지, 아직 결정하지 못한 상태로, 미션을 진행하면서 조금씩 리팩토링할 예정입니다.

@Slf4j
public class Acceptor implements Runnable {

    ......

    @Override
    public void run() {
        while (true) {
            try {
                selector.select();
                Set<SelectionKey> selectedKeys = selector.selectedKeys();
                Iterator<SelectionKey> keys = selectedKeys.iterator();
                while (keys.hasNext()) {
                    SelectionKey key = keys.next();
                    if (key.isAcceptable()) {
                        acceptSocket(key, selector);
                    } else if (key.isReadable()) {
                        read(key);
                    } else if (key.isWritable()) {
                        write(key);
                    }
                    keys.remove();
                }
            } catch (IOException exception) {
                throw new RuntimeException(exception);
            }
        }
    }

    ......

}

쓰레드 풀을 만들어 쓰레드를 재사용 했습니다. 다만, 이 부분에서 read/write 부분의 구현이 조금 아쉬운데, read와 write가 한 메서드에서 이루어지기 때문입니다. 이 부분은 추후 시간이 된다면 수정할 예정입니다.

@Slf4j
public class Acceptor implements Runnable {

    private static final int FIXED_THREAD_COUNT = 32;
    private static final int BUFFER_CAPACITY = 1024;

    private final Selector selector;
    private final AbstractEndpoint<SocketChannel> nio2EndPoint;
    private final ExecutorService service = newFixedThreadPool(FIXED_THREAD_COUNT);

    ....

    private void read(SelectionKey key) {
        log.debug("READ");
        NioSocketWrapper socketWrapper = null;
        try {
            SocketChannel socketChannel = (SocketChannel) key.channel();
            ByteBuffer buffer = allocate(BUFFER_CAPACITY);
            socketWrapper = new NioSocketWrapper(socketChannel, buffer);
            socketWrapper.flip();

            socketChannel.register(selector, OP_WRITE);
            key.attach(socketWrapper);
        } catch (IOException exception) {
            if (socketWrapper != null) {
                HttpServletResponse response = socketWrapper.getResponse();
                response.setStatus(INTERNAL_SERVER_ERROR);
            }
        }
    }

    private void write(SelectionKey key) {
        log.debug("WRITE");
        SocketChannel socketChannel = (SocketChannel) key.channel();
        service.submit((Runnable) key.attachment());
        try {
            socketChannel.register(selector, OP_READ);
        } catch (IOException exception) {
            Object object = key.attachment();
            if (object != null) {
                HttpServletResponse response = (HttpServletResponse) object;
                response.setStatus(INTERNAL_SERVER_ERROR);
            }
        }
    }
}

[J-MU]

validateSignUp에서 validateLoginInfo로 변경하신 이유가 뭔가요?

[devjun10]

이거 제 실수 같아요. 원래대로 돌리겠습니다. 👍

[devjun10]

다시보니 둘 다 있네요 ㅎㅎ 이대로 두겠습니다~!

@Component
public class UserValidator {

    public void validateSignUpInfo(
        String username,
        String password
    ) {
        if (username == null || password == null) {
            throw new InvalidParameterException(username, password);
        }
        if (username.isBlank() || password.isBlank()) {
            throw new InvalidParameterException(username, password);
        }
    }

    public void validateLoginInfo(
        String username,
        String password
    ) {
        if (username == null || password == null) {
            throw new InvalidParameterException(username, password);
        }
        if (username.isBlank() || password.isBlank()) {
            throw new InvalidParameterException(username, password);
        }
    }

    public void validateSessionId(Long userId) {
        if (userId == null) {
            throw new UnAuthorizedException();
        }
    }
}

[J-MU]

L43: this.cookiesMap

this키워드가 가독성에 도움을 준다고 생각하시나요?

[devjun10]

가독성은 잘 모르겠어요. 저도 이 부분이 일관성이 없을 때가 조금 있는데, 앞으로는 한 방식으로 통일하도록 해볼게요.

[J-MU]

필드로 List cookies를 선언해놓으신 이유가 무엇인가요?

[devjun10]

이거 필요없는 것 같아요. 삭제하겠습니다. 👍

[J-MU]

이건 디미터의 법칙에 위반되는 구현 아닌가요?

[devjun10]

일단 맞아요. 다만 디미터의 법칙을 깬다고 문제되진 않을 것 같아 사용했는데, cookies.getValue("name")을 하면 Cookie가 나오고, 해당 쿠키의 값을 반환하해요. 즉, 연관된 클래스의 연관된 값이 나오기 때문에 상관없다고 판단했습니다. 그래도 Cookie를 선언하고, 별도로 value를 하는 게 조금 더 좋아 보이긴 하네요. 반영하겠습니다. 👍

제가 이전에 MU님 코드에 디미터 법칙을 말했던 건, getDeclaringClass 메서드는 Clazz 타입을 반환하고, newInstance 메서드는 T 타입을 반환했기 때문이었어요. newInstance가 Exception을 선언해야 하기도 하고. 즉, 서로 연관된 문맥이 다르면 디미터의 법칙을 지키는 게 좋지만, 비슷한 문맥이라면 같이 쓰더라도 상관없다고 생각합니다. 이건 개인적 판단이라 MU가 판단해 주세요.

Class<?> clazz = User.class.getDeclaringClass( );
Object object  = clazz.newInstance( );

[devjun10]

답변 정정합니다. 디미터의 법칙을 어긴 것 같네요. 객체 내부의 구현이 노출된 것 같아, 다음과 같이 수정하겠습니다.

public class Cookies {

    ......

    private final Map<String, Cookie> cookiesMap;
    public static final Cookies emptyCookies = new Cookies();

    ......

    public String getValue(String name) {
        Cookie findCookie = this.cookiesMap.get(name);
        if(findCookie != null) {
            return findCookie.getValue( );  
        }
        return null;
    }

    ......

}

[J-MU]

메서드 명을 변경하신 이유가 뭔가요?
SignUpInfo가 기존 메서드보다 특별히 하는 일을 더 잘 나타낸다고 생각하시나요?이유가 뭔가요?

[devjun10]

이 부분은 제 실수 같아요. 반영하겠습니다. 👍

[J-MU]

url -> uri로 변경하신 이유가 뭔가요?
url과 uri의 차이를 설명해주세요.

[devjun10]

요청 라인에서 실제 위치를 반환할 수도, 식별자가 필요할 수도 있기 때문에 URI가 더 적절하다고 판단했습니다. URL은 실제 자원이 위치하는 경로를 말하고, URI는 자원의 위치 뿐 아니라 식별자도 나타냅니다. URI가 더 넓은 개념이고요!

[J-MU]

userId가 Wrapper타입이여야 했던 특별한 이유가 있나요?

[devjun10]

사용자 아이디가 long이면 값이 없다면 0으로 초기화 될거에요. Long이면 값이 없다면 null 값으로 들어오며, 값이 없다는 것을 명시적으로 나타낼 수 있기 때문에 사용했습니다.

[J-MU]

username자리에 password를 넣으시는 이유가 뭐죠? 의도하신게 맞나요?

[devjun10]

이거 수정했는데 커밋에는 이렇게 남아있네요. 제 실수고, 변경됐습니다.

[J-MU]

단순하게 userId를 리턴하는 거에 비해서 Objects.hash를 이용하는 것이 이점이 있을까요?
속도면에서도 hash collision을 줄인다는 면에서도 아무런 이점이 없다고 느껴져요.
어차피 userId는 유니크한 값이니까요. 어떻게 생각하시나요?

[devjun10]

Objects.hash 메서드는 사실 IntelliJ가 정의해주는대로 사용하고 있었는데, 학습해보니 이는 아래 두 가지 장점이 있네요. 이를 사용한다고 해서 성능이 좋아지거나, 혹은 이미 유니크한 값을 더 좋은 방법으로 식별/판별할 것 같지는 않구요, Null-Safe, 다중 인자 지원 정도 때문에 사용하는 것 같습니다.

1. Null-Safe
2. 다중 인자 지원

[kochungcheon]

이번 미션 고생 많으셨습니다!

[kochungcheon]

randomUUID에 대해서 설명해주세요!

[kochungcheon]

또한 UUID 충돌에 대해 어떻게 생각하시나요

[kochungcheon]

오 좋네요!

[kochungcheon]

현재 해당 인터페이스에 대한 구현체는 한개이네요! 구현체가 한개일 것으로 예상될 때도 인터페이스 사용하는 게 좋을 지 의견을 듣고 싶습니다!

[kochungcheon]

private static final 선언 기준이 궁금합니다! 2의 경우 왜 사용안하셨나요!

[devjun10]

요청라인을 파싱할 때, >=2 조건을 상수로 뽑아낼 때, 2를 어떻게 상수로 표현할지 안떠올랐습니다. 적절한 표현이 있을까요?

[kochungcheon]

LinkedHashMap을 사용하신 이유가 궁금합니다!

[kochungcheon]

고생하셨습니다!

[kmularise]

세션 키가 만료되면 Map에 남아있게 되나요?

[devjun10]

현재 구현에서는 세션이 만료되더라도 키가 Map에 남아있습니다. 간단하게 스케줄러를 사용해서 불필요한 세션을 주기적으로 제거해 주는 작업이 추가되면 좋을 것 같네요. 다음 PR 때 반영하겠습니다.

[kmularise]

세션으로 로그인을 구현한 이유가 있나요?

[devjun10]

요구사항에 세션으로 로그인을 구현한다 는 조건이 있었습니다. 👀

[kmularise]

세션과 쿠키의 차이점에 대해 설명해주세요!