안녕하세요 security 사용시 궁금한점이 있어 문의드립니다. oauth2 client 의존성을 주가해서 securityConfig 설정까지 완료하였습니다. 그래서 oauth 사용하여 sns 로그인 까지 구현하였는데 webClient 사용해서 다른 api 와 통신시 /login 페이지로 빠져버리더라구요 아래는 해당 service 단이며 콘솔창에 service token 까지는 잘찍히는데 밑에부터는 /login 페이지로 빠지는것같습니다. 혹시 webClient 사용시 security 설정을 별도로 해줘야할까요? @Service class BusinessCardService( private val webClientConfig: WebClientConfig ) { suspend fun create() : String? { println("service create()") val requestAttributes = RequestContextHolder.getRequestAttributes() as ServletRequestAttributes val cookies = requestAttributes.request.cookies val tokenCookie = cookies?.find{ it.name == "Authorization" } val token = tokenCookie?.value println("service token : ${token}") val businessCard = webClientConfig.webClient().post() .uri("/v1/ocr") .headers { header -> header.setBearerAuth(token ?: "") header.set("Content-Type", "application/json") } .contentType(org.springframework.http.MediaType.APPLICATION_JSON) .retrieve() .awaitBodyOrNull<String>() println("businessCard : "+ businessCard) return businessCard } }
강의 수강 후 개인 프로젝트를 진행중입니다. 코드 리팩토링에 관한 문제인데요. validation강의할 때 강사님께서 web과 domain 계층을 분리해서 domain은 web을 모르지만 web은 domain을 알아야 하는? 알아야 되는? 것이라고 설명하셔서 그것에 맞게 코드를 작성중입니다. domain계층엔 직접 데이터베이스와 연동하는 엔티티와 레포지토리, 서비스를 저장했습니다. 그리고 web계층엔 컨트롤러와 컨트롤러에서 주고받는 폼들(엔티티에 저장하기 위한)을 저장했구요 컨트롤러는 최대한 기능만 보이게 깔끔하게 유지하려고 하는데 폼 객체->엔티티, 엔티티->폼 객체를 작성하는 코드가 지저분해지더라구요. 무심코 리포지토리에 이 메서드를 넣었다가 domian은 web을 몰라야 한다는 말씀이 생각나서 이 코드들을 컨트롤러에 옮기려고 하는데 실무에서도 보통 폼->엔티티로 바꾸는 작업 혹은 엔티티->폼으로 바꾸는 작업은 컨트롤러 단에서 하는지 궁금합니다.
Router53의 도메인 EC2에 연결하는 부분 질문합니다. 저는 가비아에서 도메인을 구입하고 4가지 네임서버를 설정을 하고 선생님 강의처럼 모든 것을 똑같이 했는데도 이틀이 지난 지금도 제가 구입한 도메인으로 들어가면 사이트에 연결할 수 없다고 뜨는지 정말 모르겠네요.. 레코드 설정도 다 완벽하게 됐는데 이유를 정말 모르겠어요. 이 부분에서 항상 적용이 안돼서 이 강의 결제까지 오게 되었는데 왜 그런 걸까요? 다들 시간이 좀 걸린다고 했는데도 이틀은 좀 .. 뭐가 잘못된 걸까요?
머테리얼 컬러 가이드처럼, 프라이머리 컬러를 블루 계열로 두고 세컨더리 컬러를 틸 계열로 두고 싶은데, 예제는 하나의 색상 계열로 프라이머리, 세컨더리를 나누고 있어서 베리어블 구조를 어떻게 짜야할지 잘 모르겠습니다. 테마-브랜드 컬러에 틸 계열을 추가한 뒤 시멘틱-bg-인터랙티브세컨더리에 해당 브랜드 컬러를 참조하면 되는걸까요? 아니면 프리미티브 컬러에만 틸 계열을 넣어둔 뒤 시멘틱-bg-인터랙티브세컨더리 컬러에 프리미티브-틸500 을 바로 참조하면 되는걸까요?..
버전 관리를 통하여 동시성을 피할수 있다고 하셨는데, 서로 다른 서버에서 동시에 version = 1 인 데이터룰 얻고, 동시에 stock = stock + 1, version = 2 로 업데이트 치면 optimistic lock 또한 동시성이 발생할 수 있는 것 아닌가요? 강의에서는 version = 1 인 데이터를 동시에 얻지만 업데이트는 순차적으로 하는 표만 보여주셔서 헷갈려요. 순차적으로 할 수 밖에 없는 메커니즘이라면 그 부분을 설명해주셨으면 좋겠습니다.
cra환경이고 setupProxy.js에 오른쪽과 같이 프록시 미들웨어를 작성해 주었습니다. src 경로에 있고 리액트를 재실행 시켰을 때 미들웨어가 실행되는 것은 확인 했습니다. 문제는 이걸 왼쪽과 같이 사용하려고 하니 /api 경로가 수정이 안된다는 겁니다.. 도와주시면 정말 감사하겠습니다 ㅠㅠ 6시간 째 들여다 보고 있는데 도무지 뭐가 문제인지 모르겠습니다.. http-proxy-middleware 버전은 3.0.0 입니다.
강의 너무 잘 듣고 있습니다. 제가 이해한 문맥이 맞는지 확인하고자 글 남깁니다! 선생님께서는 SpellChecker 생성자의 매개변수에 곧바로 람다 또는 메서드 참조를 사용하셨기에 강의에서는 드러나지 않았으나(혹은 매개변수에 람다식을 작성한 후 변수로 추출. 이 경우에는 Supplier<Dictionary> 타입으로 추출됨), 책에서는 Supplier 인터페이스의 반환 타입이 Dictionary의 하위 타입인 경우를 염두에 둔 것으로 여겨집니다. 예를 들어, Supplier<DefaultDictionary> 타입의 변수가 있어 해당 변수를 SpellChecker 생성자의 매개변수로 넘기거나 혹은 일반적인 상황은 아닐 수 있겠지만 Supplier<DefaultDictionary> 등의 하위 타입 Supplier를 구현(혹은 Dictinary 인터페이스를 상속 받는 하위 타입 인터페이스의 Supplier를 구현. Supplier<SubDictionary> 같은)하는 클래스를 매개변수로 넘기는 상황 등에서는 한정적 와일드카드를 사용해야 하기 때문에 책에서 한정적 와일드카드를 사용하라고 얘기한 것 같습니다. 즉, Supplier<Dictionary> 타입이 아니라 Supplier<DefaultDictionary>, Supplier<SubDictonary> 타입과 같이 지네릭 타입에 Dictionary 하위 타입이 오더라도 사용 가능하게끔 하기 위함인 것 같습니다. 그렇게 생각한 근거는 책에 "클라이언트는 자신이 명시한 타입(이 경우 Dictionary)의 하위 타입이라면 무엇이든 생성할 수 있는 팩터리를 남길 수 있다." - 30p 라고 쓰여 있었기 때문입니다.
자바와 스프링 부트로 생애 최초 서버 만들기, 누구나 쉽게 개발부터 배포까지! [서버 개발 올인원 패키지]
Description: Parameter 0 of constructor in com.group.libraryapp.service.user.UserService required a bean of type 'com.group.libraryapp.repository.user.UserRepository' that could not be found. Action: Consider defining a bean of type 'com.group.libraryapp.repository.user.UserRepository' in your configuration. Disconnected from the target VM, address: '127.0.0.1:53718', transport: 'socket' Process finished with exit code 1 이게 계속 뜨면서 실행이 안됩니다 제발 도와주세요 ㅜㅜㅜㅠㅠ gpt에다가 물어봤는데도 안되어서 말씀드립니다
안녕하세요. 이번에 신입 백엔드 개발자로 취업하게 되어 프로젝트를 진행 중에 해당 HTTP 강의를 듣고 궁금한 점이 생기어 올리게 되었습니다. 다름이 아니라 사용자 API와 관리자 API를 제공하는 서버가 분리되어 있지 않고 한 서버에서 모두 제공하는 형태에서 URI를 어떻게 설계해야 하는지 잘 모르겠습니다. 예를 들어, 로그인 API를 예시로 들어보자면 "/v1/api/login" 으로 만들면 깔끔한데 관리자 로그인도 들어가야해서 결국 "/v1/api/user/login", "/v1/api/admin/login" 으로 설계하게 되었는데 이게 잘 설계한 것인지 모르겠습니다... [예시] 인증이 필요없는 API --> 기본 Path "/api/v1/..." --> ex. /api/v1/products (상품 목록 API) 사용자 인증이 필요한 API --> 기본 Path "/api/v1/user/..." --> ex. /api/v1/products (내 상품 목록 API) 관리자 인증이 필요한 API --> 기본 Path "/api/v1/admin/..." --> ex. /api/v1/admin/products (모든 유저 상품 목록 API) [궁금한 점] 사용자 API와 관리자 API를 한 서버에서 제공하는 경우에 URI를 어떤 규칙을 갖고 설계하는 게 좋은지 궁금합니다. 하나의 컨트롤러에다 인증이 필요없는 Public API, 사용자 API, 관리자 API를 모두 관리하는 게 좋은지 아니면 권한별로 컨트롤러를 쪼개서 관리하는 게 좋은 것인지 궁금합니다. --> (하나의 컨트롤러로 관리) ex. ProductController --> (권한 별로 쪼개서 관리) ex. PublicProductController, UserProductController, AdminProductController
