728x90
        // Generate JWT token
        return Jwts.builder()
                .setSubject(user.getUserId())
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + 86400000)) // 24 hours expiration
                .signWith(SignatureAlgorithm.HS512, "YourSecretKey") // Replace 'YourSecretKey' with your actual secret key
                .compact();

 

 

io.jsonwebtoken library 안에서 signWith (SignatureAlgorithm, String) 라는 놈은 이제 Deprecated 된 놈 중 하나인데 보안적인 이유때문에 짜진 친구이다.

 

이제는 String 대신에 Key 하나를 던져서 보안성을 강화해보자

 

 

Key 를 사용하기 위해 Library 2개를 더 납치해준다

import javax.crypto.SecretKey;
import io.jsonwebtoken.security.Keys;
@Service
public class AuthService {

    @Autowired
    private UserRepository userRepository;

    private final SecretKey key = Keys.secretKeyFor(SignatureAlgorithm.HS512); // Securely generate a key

    public String authenticateAndGenerateToken(LoginDto loginDto) {
        User user = userRepository.findByUserId(loginDto.getUserId());

        if (user == null || !new BCryptPasswordEncoder().matches(loginDto.getPassword(), user.getPassword())) {
            throw new IllegalArgumentException("Invalid credentials");
        }

        return Jwts.builder()
                .setSubject(user.getUserId())
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + 86400000)) // 24 hours expiration
                .signWith(key, SignatureAlgorithm.HS512)
                .compact();
    }
}

 

 

728x90

기본적으로 조져지던 Swagger는 Springfox 에서 조져지는데 이 친구들은 3.x.x 대로 올라오면서 사실상 업데이트가 제대로 맞춰지지 않았기 때문에 엄청나게 거시기 한 점이 있다.

 

 따라서 OpenAPI의 SpringDoc 를 조져주는 게 좋은데,  이 경우에도 버전에 따라서 양상이 좀 다르게 바뀐다

 

3 버전대 이전 버전에서 Spring Doc 조지기

implementation("org.springdoc:springdoc-openapi-ui:1.6.11")

 

3.2.2 버전의 경우 아래와 같이 dedencies 를 조져준다

implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.0.2'

 

잘 보면 의존성에 따라서 Library 가 변한 것을 알 수 있는데, 결과적으로 버전에 따른 Library 를 안맞춰주면 

Whitelabel Error Page를 감상할 수 있다.

대충 이렇게 생긴 친구인데 의존성을 안맞춰주면 2024년도에도 이렇게 똑같이 발생한다는 말이다.

 

또한 괜히 Library 는 많으면 많을 수록 좋다는 생각으로 2가지 친구를 동시에 추가시켜 줬다가는 다음과 같은 빨간맛을 볼 수 있다.

 

after Using .apis(RequestHandlerSelectors.basePackage("com.szs.columbus.controller")) // Replace with your controller package, I'm in error like this
Unable to infer base url. This is common when using dynamic servlet registration or when the API is behind an API Gateway. The base url is the root of where all the swagger resources are served. For e.g. if the api is available at http://example.org/api/v2/api-docs then the base url is http://example.org/api/. Please enter the location manually:

 

그리고 추가적으로 종종 localhost 기반에서 들어가서 접속해보면 박스가 하나 뜨면서 

너새끼의 basePackage 가 잘못되었으니 수동으로 한번 꼬라박아줄래? 라고 계속 물어본다

 


번외. Springfox 너새끼는 어디까지 가능한가

추가적으로 Springfox 3.0.0에서는 Spring Boot 2.5와 2.6 에서 사용되는 것과 별개로 약간의 변화가 생기는데.

2. Remove Explicit @EnableSwagger2 Annotation

Springfox 3.0.0 and later versions with Spring Boot starters do not require the @EnableSwagger2 annotation. You can remove this annotation from your configuration class.

 

Annotation 하나를 제거해준다는 특징이 있다.

 

결론 = 그냥 어지간하면 이제는 OpenAPI 의 SpringDoc 이 답이다

 


추가적으로 application.properties 에서 path 기반하에 있는걸 다 박아주는 것도 설정할  수 있는데

 

In application.properties 

# Swagger Base
springdoc.packages-to-scan=com.szs.columbus.controller

 

이런식으로 Controller Package 하부를 죄다 박아버릴 수 있다. (이건 당연히 예전에 Springfox 에서도 지원되던 것이다.)

 

 

참조하면 좋은 글

https://sjh9708.tistory.com/169

 

[Spring Boot] Swagger API Docs 작성하기 (SpringDoc, SpringBoot 3 버전)

이전에 Spring Boot 프로젝트에 Swagger를 연동해 본 적이 있었다. 최근 Spring Boot의 지원 버전이 3점대로 올라감과 동시에, 2점대에서 Swagger 사용 목적으로 많이 사용되는 SpringFox가 안타깝게도 제대로

sjh9708.tistory.com

https://colabear754.tistory.com/99

 

[Spring Boot] Springdoc 라이브러리를 통한 Swagger 적용

목차 기본 환경 IntelliJ Ultimate 2022.3 Spring Boot 2.7.7 Kotlin 1.7.21(JDK 11) Springdoc Openapi UI 1.6.11 Springdoc은 무엇인가? 이전에 Spring Boot 프로젝트에 Swagger UI를 적용하는 포스트를 작성한 적이 있다. 해당 포

colabear754.tistory.com

 

728x90

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
}

 

728x90

SEOUL, Jan. 26 (Yonhap) -- Sam Altman, CEO of U.S. artificial intelligence company OpenAI, has visited South Korea to discuss ways to set up a global network for artificial intelligence (AI) chip manufacturing with key chipmakers here, industry sources said Friday.

Altman looked around the semiconductor production line of Samsung Electronics Co. in Pyeongtaek, some 65 kilometers south of Seoul, and met with Kyung Kye-hyun, who heads the chip business at the Korean company, according to the sources.

The American businessman arrived in Seoul the previous day.

Scheduled talks with SK hynix Inc. CEO Kwak Noh-jung and SK Group Chairman Chey Tae-won are also on the agenda during his two-day visit.

This AFP photo shows Open AI CEO Sam Altman. (Yonhap)

It is Altman's second visit to South Korea after his first in June last year, when he met with Korean President Yoon Suk Yeol and had a conference with local startups.

Altman's recent move has been drawing attention as the businessman is seeking a new partnership in a bid to shake up the AI chip market, which the U.S. tech company Nvidia Corp. has largely dominated.

South Korean chipmakers Samsung Electronics and SK hynix are two of the few companies in the world that produce the premium high bandwidth memory (HBM) chips, tailored for AI processors. Their combined market share in the global HBM market reaches more than 90 percent.

SK hynix is providing the fourth-generation HBM3 chips to Nvidia and gearing up to mass produce the fifth-generation HBM3E.

Samsung Electronics, the world's largest memory chipmaker, has both memory chip and foundry, or also called contract manufacturing, businesses.

brk@yna.co.kr
(END)

+ Recent posts