시간과 공간 그리고 진실의 방

Swagger 를 사용하여 API가 실행되도록 하고 구현한 상태에서 모듈에 관련된 문제가 발생했다.

bootRun으로 Gradle 을 돌리다가 아래와 같이 뻗어버린 사태였는데, 해답은 간단하게 이미 적혀있듯

classgraph 를 조져주면된다

***************************
APPLICATION FAILED TO START
***************************

Description:

An attempt was made to call a method that does not exist. The attempt was made from the following location:

    org.webjars.WebJarAssetLocator.scanForWebJars(WebJarAssetLocator.java:188)

The following method did not exist:

    'io.github.classgraph.ClassGraph io.github.classgraph.ClassGraph.acceptPaths(java.lang.String[])'

The calling method's class, org.webjars.WebJarAssetLocator, was loaded from the following location:

    jar:file:/C:/Users/35mwl/.gradle/caches/modules-2/files-2.1/org.webjars/webjars-locator-core/0.55/d9c819930f44c89af1a6a8af2db6364926f6be69/webjars-locator-core-0.55.jar!/org/webjars/WebJarAssetLocator.class

The called method's class, io.github.classgraph.ClassGraph, is available from the following locations:

    jar:file:/C:/Users/35mwl/.gradle/caches/modules-2/files-2.1/io.github.classgraph/classgraph/4.8.69/6bd8c9033563e162b5c12de12b139724dbf71f48/classgraph-4.8.69.jar!/io/github/classgraph/ClassGraph.class

The called method's class hierarchy was loaded from the following locations:

    io.github.classgraph.ClassGraph: file:/C:/Users/35mwl/.gradle/caches/modules-2/files-2.1/io.github.classgraph/classgraph/4.8.69/6bd8c9033563e162b5c12de12b139724dbf71f48/classgraph-4.8.69.jar


Action:

Correct the classpath of your application so that it contains compatible versions of the classes org.webjars.WebJarAssetLocator and io.github.classgraph.ClassGraph


> Task :bootRun FAILED

Execution failed for task ':bootRun'.
> Process 'command 'C:\Users\35mwl\.jdks\corretto-18.0.2\bin\java.exe'' finished with non-zero exit value 1

build.gradle 에 다음과 같이 모듈 삽입을 해주고 Gradle sync 까지 마쳐준다

dependencies {
    // ... other dependencies ...
    implementation 'org.webjars:webjars-locator-core:0.46' // Update to a compatible version
    implementation 'io.github.classgraph:classgraph:4.8.69' // Update to a compatible version
}

The HTTP 401 response code indicates an "Unauthorized" error. This typically means that the request requires user authentication which has not been provided or which has failed. Here are some common reasons and solutions for this issue in a Spring Boot application:

1. Spring Security Configuration

If your Spring Boot application is using Spring Security, it might be configured to require authentication for accessing the API endpoints. This is a common scenario when Spring Security is included in the project dependencies.

Solutions:

• Provide Authentication Credentials: If your API requires authentication, you need to provide the correct credentials in your request header. In Postman, you can do this in the Authorization tab, selecting the type of authentication your API uses (like Basic Auth, Bearer Token, etc.) and entering the required credentials.
• Adjust Security Configuration: If the /users endpoint should be publicly accessible without authentication, you'll need to adjust your Spring Security configuration to permit requests to this endpoint. Here’s an example of how you might configure this in your WebSecurityConfigurerAdapter:

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        // ... other configurations ...
        .authorizeRequests()
        .antMatchers("/users").permitAll() // Permit requests to /users endpoint
        .anyRequest().authenticated()
        // ... other configurations ...
}

2. CSRF Protection

Spring Security's CSRF (Cross-Site Request Forgery) protection is enabled by default. If you are making a POST request to your Spring Boot application from Postman or another REST client, CSRF protection might block it.

Solutions:

• Include CSRF Token: If CSRF protection is necessary (usually for browser-based applications), include the CSRF token in your request.
• Disable CSRF Protection for API Endpoints: If you're building a stateless REST API (especially one used by non-browser clients), you might consider disabling CSRF protection for those endpoints:

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        // ... other configurations ...
        .csrf().disable() // Disable CSRF protection
        // ... other configurations ...
}

1. Reserved Keyword 

 GenerationTarget encountered exception accepting command : Error executing DDL "create table evaluation (id bigint generated by default as identity, comment varchar(255), content_id bigint, like boolean, unlike boolean, user_id bigint, primary key (id))" via JDBC [Syntax error in SQL statement "create table evaluation (id bigint generated by default as identity, comment varchar(255), content_id bigint, [*]like boolean, unlike boolean, user_id bigint, primary key (id))"; expected "identifier";]

위에서 나온 부분은 Reserved Keyword (예약어) 에 대한 사용이다.

 JPA  를 사용할 때에 JPA는 형상변환을 거쳐 SQL 문법 (Diarect)로 변환되게 되는데, 코드상에서 보면 당연히 '좋아요' 를 like로 지정할 수 있겠지만 이러한 부분은 SQL 문법에서의 like 와 문제를 일으키게 된다.

문제가 되는 코드를 살펴보자

package com.webtoon.webtoonservice.model;

import jakarta.persistence.*;

@Entity
public class Evaluation {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private Long userId;
    private Long contentId;
    private Boolean like;
    private Boolean unlike;
    private String comment; // Ensure validation to disallow special characters
}

이 부분에서 해당하는 부분을 고치려면 like를 likes 로 고치거나 이스케이핑을 하면 된다.

@Entity
@Table(name = "evaluation")
public class Evaluation {
    // other fields...

    @Column(name = "`like`")
    private Boolean like;
    private Boolean unlike;

    // getters and setters...
}

2. Reserved Keyword

GenerationTarget encountered exception accepting command : Error executing DDL "create table user (id bigint generated by default as identity, gender varchar(255), register_date timestamp(6), type varchar(255), user_email varchar(255), user_name varchar(255), primary key (id))" via JDBC [Syntax error in SQL statement "create table [*]user (id bigint generated by default as identity, gender varchar(255), register_date timestamp(6), type varchar(255), user_email varchar(255), user_name varchar(255), primary key (id))"; expected "identifier";]

가장 눈치채기 어려운 것 중 하나인 user 에 대한 부분이다. 변환하는 과정 도중 Directs 중에서 user 라는 부분은 이미 잡혀있는 user table 을 지칭하여 문제를 일으킬 수 있기 마련인데 이러한 부분 때문에 문제가 발생한다.

package com.webtoon.webtoonservice.model;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;


import jakarta.persistence.*;
import java.util.Date;



@Entity
@Table(name = "`user`") // use backticks to escape
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String userName;
    private String userEmail;
    private String gender; // Consider using an enum here
    private String type;   // Consider using an enum here
    private Date registerDate;
}

마찬가지로 이스케이핑을 하여 처리할 수 있다.

전 포스팅에서 한번 언급한 바가 있지만, 고도몰에 접속하거나 토큰에 의해서 데이터를 가져오게 되는 경우 Session 연결을 성립하게 되는 경우다.

Android 단에서 ApiService.kt 단에서 GET method 방식으로 Shop의 User Profile 을 확인하는 부분을 추가시켜 주었고, 원래라면 앱이 켜졌을 때마다 accessToken 을 가지고 고도몰에 대해서 End-Point 단위로 request 를 날려주려 했으나 비효율적이라는 판단이 들은 것 같다.

1.

앱을 사용하는 사용자들이 전부다 샵을 이용할 계획이 있는 것은 아니기 때문이다.

이러한 부분에서 앱을 키자마자 무조건적으로 샵에 대해서 request 를 전송하게 되면, 불필요한 트래픽과 동시에 request 가 발생하게 된다.

2.

WebView 에 의해서 Shop 이 로드됫을 때 (init) 시점마다 request 를 던져주게 되면, 자연스럽게 WebView 안에 있는 Web 에 대해서도 Session Handling 을 할 수 있게 되기 때문에 이 부분이 구조적으로 볼 때에 정상적이라고 볼 수 있을 것 같았다.

여하튼 패치 후, 정상적으로 세션 끊김 문제는 해결되었고

 Signed Key를 이용하여 Deploy 를 하기위해 Android Market 에 검토요청을 올렸다.