스프링부트는 사랑입니다

Spring Security and AngularJS Part I 본문

Tutorials

Spring Security and AngularJS Part I

얼바인 2015. 12. 2. 03:41
728x90

스프링 시큐리티와 앵귤러JS - Spring Security and AngularJS


Part I : 단일 페이지 보안 어플리케이션 (A Secure Single Page Application)

Part II: 로그인페이지 (The Login Page)

Part III: 리소스 서버 (The Resource Server)

Part IV: API 게이트웨이 (The API Gateway)

Part V: OAuth2와 싱글사인온 (Single Sign On with OAuth2)

Part VI: 다중 UI 어플리케이션과 게이트웨이 (Multiple UI Applications and a Gateway)

Part VII: 모듈화한 AngularJS 어플리케이션  (Modular AngularJS Application)

Part VIII: Angular 어플리케이션 테스트 (Testing an Angular Application)


--------------------------------------------------------------------------------

단일페이지 보안어플리케이션 A Secure Single Page Application

이 섹션에서 스프링 시큐리티, 스프링 부트와 앵귤러JS의 멋진 기능을 같이 조합하여 쾌적하고 시큐어한 사용자 경험을 제공하려고 한다. 스프링과 앵귤러JS를 막 시작하려는 사람도 충분히 따라할수 있는 수준이지만, 많은 디테일한 정보를 제공하여 경력자들 또한 이롭게 할 것이다. 이 글은 스프링 시큐리티와 앵귤러JS의 새 기능을 순차적으로 연재하는 시리즈의 첫번째 섹션이다. 연재가 되면서 어플리케이션을 차츰 더 낫게 손보겠지만 이후의 주요 변화는 기능적인 것보다는 아키텍쳐 관점이 될 것이다.


스프링과 단일페이지 어플리케이션 Spring and the Single Page Application

HTML5과 "단일페이지어플리케이션"은 요즘 개발자들에게 극도의 가치가 있는 툴이지만 정적인 컨텐츠(HTML,CSS와 자바스크립트)뿐만 아니라 의미가 되는 상호작용은 백엔드서버에 들어있으므로 우리는 백엔드 서버가 필요하다. 백엔드서버는 모든 역할의 갯수 - 정적인 컨텐츠를 제공하고, 가끔 (요즘엔 많지않지만) 동적인 HTML를 랜더링하며, 보호하는 자원의 안전한 접근을 보장하며, 자바스크립트와 브라우저내에서 HTTP와 JSON을 통해 상호작동 (REST API라 언급되기도함)을 하는 - 만큼의 역할을 할 수 있다.

스프링은 백엔드 기능(특히 엔터프라이즈 환경에서)을 만드는데 있어 언제나 인기있는 기술이었고,  스프링 부트의 출현과 함께 이러한 기능을 제공하기에 이보다 더 쉬울 순 없게 되었다. 오직 스프링부트와 앵귤러JS 그리고 트위터 부트스트랩만 사용해서 어떻게 새 단일페이지 어플리케이션을 살펴보도록 하자. 이 기술세트를 선택하게 된 특별한 이유가 있는건 아니고 그냥 엔터프라이즈 자바 바닥에서 아주 인기가 많기 때문에, 이렇게 시작할 충분한 가치가 있기 때문이다. 


새 프로젝트 만들기 Create a New Project

이 어플리케이션을 만들기위한 단계마다 스프링과 앵귤러에 익숙하지않은 사람들이 어떻게 되어가는지 따라올 수 있게 약간의 부연설명을 덧붙일 것이다. 부연설명이 필요없는 사람들은 이 단락을 넘기고 어플리케이션을 동작하는 마지막 섹션으로 바로 가도 된다. 새 프로젝트를 생성할 수 있는 몇가지 옵션들이 있다:


우리가 빌드할 완성된 프로젝트의 소스코드는 여기 Github에서 볼 수 있다. 필요하다면 프로젝트를 클론하여 돌려보고 바로 다음 단계로 건너뛰어도 된다.


Spring Tool Suite 이용하기

Spring Tool Suite (이클립스 플러그인의 한종류)의 메뉴 File->New->Spring Starter Project에서 프로젝트를 만들거나 불러올 수 있다.


홈페이지 추가하기 Add a Home Page

단일페이지 어플리케이션의 핵심은 하나의 정적인 "index.html"이다. 바로 프로젝트의 "src/main/resources/static" 또는 "src/main/resources/public"의 경로에 다음과 같이 하나 만들어보자:

index.html
<!doctype html>
<html>
<head>
<title>Hello AngularJS</title>
<link href="css/angular-bootstrap.css" rel="stylesheet">
<style type="text/css">
[ng\:cloak], [ng-cloak], .ng-cloak {
  display: none !important;
}
</style>
</head>

<body ng-app="hello">
  <div class="container">
    <h1>Greeting</h1>
    <div ng-controller="home" ng-cloak class="ng-cloak">
      <p>The ID is {{greeting.id}}</p>
      <p>The content is {{greeting.content}}</p>
    </div>
  </div>
  <script src="js/angular-bootstrap.js" type="text/javascript"></script>
  <script src="js/hello.js"></script>
</body>
</html>

단지 "Hello World"를 출력하는 코드이므로 매우 간결하고 쉽다.


홈페이지의 특징 Features of the Home Page

이 홈페이지의 가장 주요한 기능은 다음과 같다:

  • <head>에서 CSS를 불러온다. 하나의 엘리먼트에는 실제로 아직 존재하지는 않지만 ("angular-bootstrap.css")와 같이 임시적으로 파일 이름을 채우며, 인라인 스타일시트가 "ng-cloak" 클래스를 정의 하고 있다.

  • "ng-cloak" 클래스는 <div> 컨탠트에 적용되어 해당 동적 컨텐트를 앵귤러JS가 처리할때까지 보지않게(hidden) 한다 - 초기 페이지 로딩중에 페이지가 깜빡거리는 현상을 막기 위해서다.

  • <body>에 마크된 ng-app="hello"는 앵귤러가 "hello"라 불리는 어플리케이션을 인식할 수 있게 만들어주는 하는 자바스크립트 모듈을 정의해야 한다는 의미다.

  • "ng-cloak"을 제외한 모든 CSS 클래스는 트위터 부트스트랩에서 불러온다. 스타일시트를 올바르게 설정해두면 페이지를 이쁘게 만들어줄것이다.

  • greeting안의 컨탠트는 {{greeting.content}}와 같이 핸들바를 이용하여 마크업되었다. 이것은 후에 앵귤러에 의해 실제 값으로 채워질 것이다. (<div>)로 둘러쌓인 ng-controller directive에 의해 "home" 이라 불리는 controller에 의해). 

  • 앵귤러JS (와 트위터 부트스트랩)은 <body>의 하단에 포함되어 브라우저가 모든 HTML을 처리한 이후 읽혀질것이다.

  • 또한 어플리케이션의 행동을 정의해둘 별도의 "hello.js"이 있다. 

곧 스크립트와 스타일시트 파일들을 만들테니 지금은 그들이 없는 파일이라는걸 무시하기로 하자.


어플리케이션 동작하기 Running the Application

일단 홈페이지 파일이 추가되면 (아직 많은 것 하지않았음에도 불구하고) 어플리케이션을 브라우저에서 실행할 수 있다. 커맨드라인상에 다음과 같이 타입해보자:

$ mvn spring-boot:run

그리고 브라우저를 열고 주소창에 http://localhost:8080를 타입한다. 홈페이지가 실행되면 브라우저 팝업창이 뜨며 아이디와 패스워드를 물어볼것이다. (아이디는 "user"이고 패스워드는 어플리케이션 시작시 콘솔로그에 출력된다). 아직 컨탠트가 없지만 인증에 성공하면 "greeting"헤더를 가지는 빈페이지를 볼 수 있을 것이다.

 패스워드 확인을 위해 콘솔창을 찾는게 싫다면 프로젝트의 "src/main/resources"의 위치에 application.properties 파일을 만들어 다음과 같이 추가하면된다: security.user.password=password (패스워드는 원하는대로 변경가능하다). "application.yml"파일을 만들어 넣어도 똑같이 동작한다.

IDE에선 그냥 어클리케이션 클래스의 main() 메소드를 실행하면 된다. 지금은 UiApplication이라는 하나의 클래스만 있다.

패키지 빌드하여 standalone JAR을 만들어 다음과 같이 실행해도 된다:

$ mvn package
$ java -jar target/*.jar

프론트엔드 에셋 Front End Assets

앵귤러JS나 다른 프론트엔드 기술의 초급 튜토리얼들은 주로 라이브러리 에셋을 직접 라이브러리와 연관된 여러개의 파일들을 다운받아 리소스 경로에 직접 넣는 것 대신 인터텟을 통해 바로 가져오라고 가르친다. (이를테면 앵귤러 JS 웹사이트에서는 Google CDN를 통해 다운받는것을 추천한다). 이것은 어플리케이션을 동작하는데 반드시 따라야하는 것은 아니지만 실제 제품화 단계에서 브라우저와 서버같의 불필요한 통신을 피할수 있는 최고의 실전 팁이다. 우리가 CSS 스타일시트를 변경하거나 커스터마이즈하지 않는다면 "angular-bootstrap.css"파일을 프로젝트에 만들어두는 것도 불필요하므로 Google CDN를 통해 정적인 에셋을 사용하면 된다. 하지만 실제 어플리케이션은 거의 대부분 스타일시트를 수정하면서도 CSS소스 자체에는 손대고 싶지않기 때문에 Less 나 Sass와 같은 상위레벨의 툴을 사용한다. 따라서 우리 또한 그렇게 해볼 것이다.

이것을 위한 많은 방법들이 있지만 이 섹션의 목적을 위해 우리는 자바기반의 프론트엔드 에센의 선처리 및 패키징 툴체인인 wro4j을 사용할 것이다. 그냥  서블릿 어플리케이션에서 JIT (Just in Time) Filter로서 사용할 수 있지만 메이븐이나 이클립스와 같은 빌드툴을 또한 매우 잘 지원한다. 그리고 우리가 이것을 쓰려는 이유다. 따라서 우리는 정적 리소스 파일들을 빌드하여 번들화시켜 우리의 어플리케이션 JAR에 넣을 것이다.

여담: Wro4j 는 아마도 하드코어 프론트엔드 개발자가 선택할 만한 툴은 아닐것이다. 그들은 통상 bower 와/또는 grunt와 같은 노드기반의 툴체인을 쓴다. 그러한 툴은 명백하게 아주 훌륭하고 인터넷상에 수많은 튜토리얼을 구할수 있다. 당신이 그것을 선호한다면 이 프로젝트내에서 자유롭게 쓰길 바란다. 그냥 프로젝트의 "src/main/resources/static" 경로에 그 툴체인으로 만들어진 결과파일/폴더를 넣으면 바로 잘 동작할것이다. 당신이 하드코어 프론트엔드 개발자가 아니라면 이 자바기반의 툴인 wro4j를 나름 편하게 활용할 수 있을 것이다.

빌드타임에 정적 리소스를 만드려면 메이븐 pom.xml에 약간의 마법을 뿌려야한다. (좀 장황하지만 boilerplate로서 메이븐의 parent pom안에서 또는 그래들의 shared task나 plugin으로 추출된다):

pom.xml

<build>
  <resources>
    <resource>
      <directory>${project.basedir}/src/main/resources</directory>
    </resource>
    <resource>
      <directory>${project.build.directory}/generated-resources</directory>
    </resource>
  </resources>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
    </plugin>
    <plugin>
      <artifactId>maven-resources-plugin</artifactId>
      <executions>
        <execution>
          <!-- Serves *only* to filter the wro.xml so it can get an absolute
            path for the project -->
          <id>copy-resources</id>
          <phase>validate</phase>
          <goals>
            <goal>copy-resources</goal>
          </goals>
          <configuration>
            <outputDirectory>${basedir}/target/wro</outputDirectory>
            <resources>
              <resource>
                <directory>src/main/wro</directory>
                <filtering>true</filtering>
              </resource>
            </resources>
          </configuration>
        </execution>
      </executions>
    </plugin>
    <plugin>
      <groupId>ro.isdc.wro4j</groupId>
      <artifactId>wro4j-maven-plugin</artifactId>
      <version>1.7.6</version>
      <executions>
        <execution>
          <phase>generate-resources</phase>
          <goals>
            <goal>run</goal>
          </goals>
        </execution>
      </executions>
      <configuration>
        <wroManagerFactory>ro.isdc.wro.maven.plugin.manager.factory.ConfigurableWroManagerFactory</wroManagerFactory>
        <cssDestinationFolder>${project.build.directory}/generated-resources/static/css</cssDestinationFolder>
        <jsDestinationFolder>${project.build.directory}/generated-resources/static/js</jsDestinationFolder>
        <wroFile>${project.build.directory}/wro/wro.xml</wroFile>
        <extraConfigFile>${basedir}/src/main/wro/wro.properties</extraConfigFile>
        <contextFolder>${basedir}/src/main/wro</contextFolder>
      </configuration>
      <dependencies>
        <dependency>
          <groupId>org.webjars</groupId>
          <artifactId>jquery</artifactId>
          <version>2.1.1</version>
        </dependency>
        <dependency>
          <groupId>org.webjars</groupId>
          <artifactId>angularjs</artifactId>
          <version>1.3.8</version>
        </dependency>
        <dependency>
          <groupId>org.webjars</groupId>
          <artifactId>bootstrap</artifactId>
          <version>3.2.0</version>
        </dependency>
      </dependencies>
    </plugin>
  </plugins>
</build>

위의 소스 그대로 당신의 POM에 붙여넣거나 Github에 있는 소스를 가져다 쓰면된다.

주요 사항은:

  • 우리는 (CSS와 스타일링을 위한 jquery와 부트스트랩, 그리고 비지니스 로직을 위한 앵귤러JS의) 의존성으로서 몇몇 webjars 라이브러리를 추가했다. 이러한 jar 파일안의 정적 리소스들의 일부는 우리가 만든 angular-bootstarp.* 같은 파일들을 포함할 것이다. 그러나 jar 자체는 어플리케이션에 같이 패키지 될 필요없다.

  • 트위터 부트스트랩은 JQuery에 의존성을 가지므로 같이 넣을 것이다. 부트스트랩을 쓸 필요없는 앵귤러JS 어플리케이션은 이것이 필요없다. 왜냐하면 앵귤러는 자체적으로 JQuery로 쓰려는 기능을 가지고 있기때문이다.

  • <resources/> 섹션에서 선언되었기 때문에 생성된 리소스들은 "target/generated-resources"폴더에 위치되며, 프로젝트를 빌드한 JAR안에 패키지될 것이다. (이클립스 m2e같은 메이븐 툴링을 쓴다는 가정하에) IDE에서는 클래스패스를 통해 쓸 수 있다.

  • wro4j-maven-plugin은 약간 이플립스 통합기능을 가지고 있어 이클립스 마켓플레이스에서 인스톨할 수 있다. (어플리케이션이 완성되면 필요없으므로 처음이면 나중에 인스톨하라). 인스톨하면 이클립스는 이후 리소스 파일들을 주시하고 변경사항이 있으면 결과물을 자동으로 재생성한다. 디버그 모드로 동작중이라면 브라우저에 변경사항을 즉시 반영한다.

  • Wro4j는 당신의 빌드 클래스패스를 알지 못하는 XML설정을 통해 제어하며 오직 파일의 절대경로만 인식한다. 그러므로 우리는 파일의 절대 경로를 만들어 wro.xml에 추가해야한다. 이것을 위해 메이븐 리소스 필터링을 사용할 것이며 이것이 왜 명시적으로 "maven-resources-plugin" 선언을 해줘야 하는가에 대한 이유다.

필요한 POM 수정은 이게 전부이며 "src/main/wro"에 위치할 wro4j 빌드파일을 추가할일만 남았다.


Wroj4j 소스파일들 Wro4j Source Files

Github의 소스파일엔 오직 3개 파일만 볼 수 있다. (그중 차후 커스터마이징을 위해 하나는 빈파일이다)

  • wro.properties는 wro4j 엔진의 선처리preprocessing와 랜더링을 위한 설정configuration 파일이다. 이 설정파일로 이 툴체인의 다양한 기능을 켜거나 끌수있다. Less로 부터 CSS를 컴파일하고 자바스크립트를 minify하려는 우리의 경우, 결과적으로 필요한 모든 라이브러리들의 소스를 섞어 2개의 파일로 합칠것이다.

    wro.properties
    preProcessors=lessCssImport
    postProcessors=less4j,jsMin
  • wro.xml는 "angular-bootstarp"이라는 단일 "그룹"을 선언하며 생성되는 정적 리소스의 기본명으로 종료한다. 우리가 추가한 webjars의 <css> 와 <js> 엘리먼트의 참조형 및 로컬 리소스파일인 main.less를 또한 포함하고있다.

    wro.xml
    <groups xmlns="http://www.isdc.ro/wro">
      <group name="angular-bootstrap">
      <css>webjar:bootstrap/3.2.0/less/bootstrap.less</css>
        <css>file:${project.basedir}/src/main/wro/main.less</css>
        <js>webjar:jquery/2.1.1/jquery.min.js</js>
        <js>webjar:angularjs/1.3.8/angular.min.js</js>
      </group>
    </groups>
  • main.less는 예제코드로서 빈 파일이지만 UI의 Look & Feel이나 트위터 부트스트랩의 (밑의 한줄로) 기본 파란색을 옅은 핑크색으로 바꾸는 등의 기본설정을 바꾸거나, 커스터마이즈하는데 사용된다.

    main.less
    @brand-primary: #de8579;
  • 위의 파일들을 프로젝트로 복사해넣고 "mvn package"를 타입하면 JAR파일안에 "bootstarp-angular.*" 리소스 파일들을 볼 수 있을 것이다. 이제 앱을 실행하면, CSS가 작동하는것을 확인할수 있다. 하지만 아직 비지니스 로직과 페이지 이동기능이 여전히 빠져있다.


    앵귤러 어플리케이션 만들기 Create the Angular Application

    이제 "hello" 어플리케이션을 만들어보자 ("src/main/resources/static/js/hello.js" 경로에 만들어야 "index.html"의 하단의 <script/> 엘리먼트가 올바른 경로를 찾을수 있다)

    최소사양의 앵귤러JS 어플리케이션은 다음과 같다.

    hello.js
    angular.module('hello', [])
      .controller('home', function($scope) {
        $scope.greeting = {id: 'xxx', content: 'Hello World!'}
    })

    어플리케이션의 이름은 "hello"이고 빈 "config" 와 "home"이라는 이름의 "controller"를 가지고 있다. "home" controller는 "index.html"에 ng-controller="home"을 선언한 <div> 컨텐트때문에 "index.html"가 로드될때  같이 호출된다

    controller 함수안에 마법과도 같은 $scope을 주입했고 (앵귤러는 명명규칙naming convention에 따른 의존성주입 dependency injection by naming convention을 한다), 당신의 함수변수의 이름을 인식하고 있다는걸 명심하자. $scope은 컨트롤러가 책임지는 함수내에서 UI엘리먼트를 위한 컨텐트와 행동규약등을 설정해준다.

    당신이 이 파일을 "src/main/resources/static/js" 경로밑에 추가했다면 어플리케이션은 이제 안전하고 기능적이되었으며 "Hello World!"를 보여줄것이다. greeting은 HTML내에{{greeting.id}} 와 {{greeting.content}} 와 같은 placeholder들은 핸들바를 사용하는 앵귤러에 의해 랜더되었다. 


    동적 컨텐트 추가하기 Adding Dynamic Content

    지금까지 우리는 하드코드된 greeting을 가진 어플리케이션을 만들었다. 어떻게 서로가 맞추어가는지 배우면 유용할것이다. 그러나 실제로 우리가 기대한 컨텐트는 서버로부터 오는것이므로 이제 HTML endpoint를 만들어 greeting을 받아올 것이다. "src/main/java/demo"에 있는 어플리케이션의 메인클래스에  @RestController 어노테이션과 새 @RequestMapping을 정의하자:

    UiApplication.java
    @SpringBootApplication
    @RestController
    public class UiApplication {
    
      @RequestMapping("/resource")
      public Map<String,Object> home() {
        Map<String,Object> model = new HashMap<String,Object>();
        model.put("id", UUID.randomUUID().toString());
        model.put("content", "Hello World");
        return model;
      }
    
      public static void main(String[] args) {
        SpringApplication.run(UiApplication.class, args);
      }
    
    }

    새프로젝트를 어떻게 만들었냐에 따라 UiApplication이 아닐 수도 있 다. @SpringBootApplication 대신 @EnableAutoConfiguration @ComponentScan @Configuration이 있을 수도 있다.

    어플리케이션을 실행하고 curl에서 "/resource" endpoint를 타입해보면 기본적으로 보안이 작동하여 다음과 같은 메세지를 볼 수 있다:

    $ curl localhost:8080/resource
    {"timestamp":1420442772928,"status":401,"error":"Unauthorized","message":"Full authentication is required to access this resource","path":"/resource"}

    앵귤러에서 동적리소스 불러오기 Loading a Dynamic Resource from Angular

    이제 브라우저에서 메세지를 받아봐보자. "home" controller를 XHR을 사용하여 보호된 리소스를 불러올수있게 수정하자:

    hello.js
    angular.module('hello', [])
      .controller('home', function($scope, $http) {
      $http.get('/resource/').success(function(data) {
        $scope.greeting = data;
      })
    });

    core기능으로 앵귤러가 제공해주는 $http서비스를 주입하고 GET메소드로 resource에 접근한다. 성공적으로 요청되면 앵귤러는 콜백으로 Response body로부터 JSON 타입을 돌려받는다.

    다시 어플리케이션을 실행하면 (또는 그냥 브라우저의 홈페이지를 다시 로드하면) Unique ID를 가진 동적 메세지를 볼수 있을것이다. 리소스가 보호된 상태라 직접적으로 curl을 사용할 순 없지만 브라우저는 컨텐트에 접근할 수 있다. 우리 이제 백줄도 안되는 코드로 단일페이지 보안 어플리케이션을 가지게 되었다!

    당신은 아마 파일 수정후 브라우저에 정적 리소스의 재실행을 강제하고 싶을 수 있다. 크롬(파이어폭스에선 플러그인을 통해)에서 "developer tools" 메뉴 (단축키 F12)를 통해 가능하며 또는 CTRL+F5를 사용하면 된다.


    어떻게 작동하는가? How Does it Work?

    브라우저와 백엔드간의 연동은 사용자의 브라우저에서 확인할 수 있다. 만일 사용자가 개발자 툴을 사용한다면 (보통 크롬에서는 기본값으로 F12를 누르면 열리고 파이어폭스에서는 플러그인을 설치해야할 것이다) 정리하자면:

    VerbPathStatusResponse

    GET

    /

    401

    인증을 위한 브라우저 팝업 프롬프트

    GET

    /

    200

    index.html

    GET

    /css/angular-bootstrap.css

    200

    트위터 부트스트랩 CSS

    GET

    /js/angular-bootstrap.js

    200

    부트스트랩과 앵귤러JS

    GET

    /js/hello.js

    200

    어플리케이션 로직

    GET

    /resource

    200

    JSON greeting

    브라우저가 단일 연동으로서 홈페이지를 로드한다고 간주하기때문에 사용자는 아마 401 응답을 볼 수 없을것이다. 그리고 /resource를 위한 두번의 요청을 볼수 있는데, 이는 CORS negotiation때문이다.

    요청들을 더 자세히 들여다 보면, 모든 요청에 다음과 같은 "인증Authorization"헤더가 있는 것을 볼 수 있다:

    Authorization: Basic dXNlcjpwYXNzd29yZA==

    브라우저는 모든 요청에 사용자명과 패스워드를 보내고 있는데 ( 그러므로 제품화단계에선 HTTPS으로만 써야하는걸 기억하자). 이런한 단계는 "앵귤러"와 무관하므로 사용자가 자바스크립트 프레임워크를 쓰던 안쓰던 잘 동작한다.


    무엇이 문제인가? What’s Wrong with That?

    표면적으로는 매우 잘 작동하는 것처럼 보인다. 간결하고 구현이 간단하며, 모든 데이터는 패스워드에 의해 안전하다. 그리고 사용자가 프로트엔드 또는 백엔드 기술세트를 바꾸더라도 여전히 잘 작동할 것이다. 하지만 약간의 이슈가 있는데:

    • 기본 인증은 사용자명과 패스워드 인증으로 제한되어있다.

    • 인증 UI는 흔하지만 매우 추하다 ( 브라우저 다이얼로그).

    • Cross Site Request Forgery (CSRF)로부터 보호되지않는다.

    CSRF는 실제로 백엔드 리소스에 GET만 사용하는 지금의 어플리케이션에는 문제가 안될 수도 있다 (예를 들면 서버의 상태변화가 없을때). 일단 사용자가 어플리케이션에 POST, PUT 또는 DELETE 를 사용한다면, 요즘의 기술로는 더 이상 안전하지 않다.

    이 시리즈의 다음 섹션에서, 우리는 HTTP Basic보다 훨씬 유연한 폼 기반의 인증을 사용하도록 어플리케이션을 확장할 것이다. 일단 우리가 폼을 사용하면 CSRF 보호를 할 필요가 있다. 스프링 시큐리티와 앵귤러 둘다 이것을 만드는데 도움을 주는 즉시 활용가능한 멋진 기능들을 가지고 있다. 약간 스포일로해보면, 우리는 HttpSession을 사용할 것이다.

    감사의 말: 이 시리즈를 만드는데 도움을 준 모든분께 감사드리고 싶다. 특히 각각의 섹션과 소스코드를 주의깊게 리뷰를 해주고, 내가 잘 알고 있다고 생각한 부분에서 조차 알지못했던 몇가지 트릭을 알게 해준 Rob Winch 와 Thorsten Spaeth.에게 감사하다.



    728x90