Spring Boot 및 Angular 인증-앱을 보호하는 방법은 무엇입니까?

Spring Boot 및 Angular 인증-앱을 보호하는 방법은 무엇입니까?

1. 질문(문제점):

그래서 나는이 레거시 앱을 spring MVC 및 JSP로 실행하고, mongo DB에서 읽기
, Spring boot 및 angular JS를 사용하는 최신 앱으로 대체하려고 생각하고 있습니다.

나는 프레임 워크를 찾고 있지 않습니다. 제 질문은 인증과 관련하여 더 개념적이며 앵귤러와 스프링 부트 사이에서 작동하는 방식입니다.

인증을 위해 제 3자를 사용하고 싶지 않습니다. 내부 DB 사용자와 비밀번호를 계속 사용하고 싶습니다.
또한 클라이언트가 먼저 등록한 다음 각도 및 인증을 우회하는 모든 요청에 ​​토큰을 전송해야하는 나머지 API가 있습니다.

그래서 과거에 (고대 j2ee) 나는 Servlet 필터를 가지고 있었는데,이 필터 전쟁은 어떤 요청에서든 실행되었고, 세션이 인증되었는지 확인했습니다. 그렇지 않은 경우 인증 페이지로 전달한 다음 결과를 세션에 저장합니다.

이것의 라인을 따라 뭔가 :

@WebFilter("/*")
public class LoginFilter implements Filter {

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws ServletException, IOException {    
        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;
        HttpSession session = request.getSession(false);
        String loginURI = request.getContextPath() + "/login";

        boolean loggedIn = session != null && session.getAttribute("user") != null;
        boolean loginRequest = request.getRequestURI().equals(loginURI);

        if (loggedIn || loginRequest) {
            chain.doFilter(request, response);
        } else {
            response.sendRedirect(loginURI);
        }
    }

    // ...
}

Angular JS로 동일한 인증 메커니즘을 수행하는 방법은 무엇입니까?
서블릿의 필터에 해당하는 것은 무엇입니까?
Angular는 클라이언트 측 렌더링이기 때문에 어떻게 보호합니까?

입력 해 주셔서 감사합니다!

2. 해결방안:

나는 프레임 워크를 찾고 있지 않습니다. 제 질문은 인증과 관련하여 더 개념적이며 앵귤러와 스프링 부트 사이에서 작동하는 방식입니다.

특정 프레임 워크를 넘어서 개념적 답변을 요구하고 있기 때문에이 특정 답장을하기가 까다 롭다는 것을 알았습니다. 그러나 두 프레임 워크 인 Angular와 Spring을 언급하고 있으므로 한 걸음 뒤로 물러서겠습니다.

클라이언트에 대한 인증은 우회하기가 쉽기 때문에 적절한 인증은 항상 서버 측에서 수행해야합니다. 클라이언트 측 특정 경로를 허용하지 않지만 UX를 개선하기 위해 감시 장치를 사용할 수 있습니다.

기본적으로 선택할 수있는 두 가지 유형이 있습니다 : 상태 또는 상태 비 저장

상태 인증은 성공적인 인증 후 서버가 일부 세션을 생성하고 일부 식별자를 저장하고 연속 요청에 대해 유효성을 검사하는 경우입니다. 이것은 봄에 JSESSION이라는 쿠키 접근 방식을 사용하는 전통적인 세션입니다. 이 접근 방식의 단점은 상태가 어딘가에 유지되어야한다는 것입니다. 그리고 고정 세션 (이 정보를 메모리에 보관하여 벗어날 수 있음)이없는 한이를 저장 / 검색하기 위해 분산 시스템 (SQL db, 카산드라, 애완 동물 프로젝트 등). 그러나 우리가 배운 것처럼 트래픽이 많은 분산 상태는 병목 현상을 일으키므로 가능하면 피하는 것이 좋습니다.

상태 비 저장 인증 : JWT의 경우와 마찬가지로 모든 서버에서 세션을 다시 생성하는 데 필요한 모든 정보가 포함되어 있으므로 분산 상태가 없거나 더 좋은 방법은 상태가 클라이언트 (브라우저)에 있고 암호화 방식으로 서명되어 있으므로 사용자가 액세스 / 변조 할 수 있습니다. 단점은 토큰의 암호화 / 복호화가 약간의 CPU를 요구할 수 있지만 사용자에게는 눈에 띄는 것이 없다는 것입니다.

따라서 위 중 하나를 결정하면 나머지는 크게 다르지 않습니다. 두 경우 모두 앵귤러에 인터셉터 를 구현 하고 경우에 따라 각 요청에 대해 쿠키 또는 Auth 헤더를 전송해야하며 서버 측에서는 해당 필터를 통해 요청을 처리해야합니다. 첫 번째 예제의 쿠키 대신 세션 값을 더 RESTful 방식으로 헤더로 보낼 수 있습니다.

또한 클라이언트가 먼저 등록한 다음 각도 및 인증을 우회하는 모든 요청에 ​​토큰을 전송해야하는 나머지 API가 있습니다.

이는 API에 대한 새로운 사용 사례처럼 보이지만 위에 언급 된 내용은 그대로 유지됩니다. 로그인이 완료되고 토큰 / 세션이 인증 사용자에게 반환 된 후에도 인증 헤더를 계속 사용할 수 있습니다. 이 유형의 클라이언트에 대해 다른 인증 토큰을 가질 수도 있습니다.이 경우 API를 변경하지 않고이 헤더를 확인하기 위해 새 필터를 연결하면됩니다.

원하는 인증 / 승인 솔루션을 구현하는 데 적합한 리소스를 온라인에서 찾을 수있을 것입니다.

65690415