안녕하세요~ 강의 내용 중 궁금한게 있는데요 layout에선 usepathname, usesearchparams 와 같은 값에 접근할 수 없기 때문에 'use client' 지시어를 활용해 클라이언트 컴포넌트를 통해 해당 값에 접근해야한다 라고 말씀해주셨는데 이 개념은 단순 서버 컴포넌트와 클라이언트 컴포넌트에 따른 차이점과 동일한 의미 아닌가요?? next.js 자체가 서버컴포넌트 일 경우 usepathname, usesearchparams 와 같은 훅을 사용할 수 없는데 Page.tsx 컴포넌트도 마찬가지 아닌가요?? 'layout에선' usepathname, usesearchparams 와 같은 값에 접근할 수 없기 때문에 'use client' 지시어를 활용해 클라이언트 컴포넌트를 통해 해당 값에 접근해야한다. 라는 말씀이 Page.tsx 에서의 사용법과 어떤 차이점이 있는지 잘 이해가 가질 않습니다... 아 참고로 next 클라이언트 페이지 라우팅 시 layout영역은 리렌더링 되지 않고 page.tsx 영역만 렌더링된다라는 partial rendering 개념은 이해했습니다. 강의랑 유튜브 항상 잘 보고있습니다. 양질의 영상 제공해주셔서 감사합니다!
출력값 3번째줄에 있는 Tesla Model 3 start는 eCar.start();에서 start가 부모 클래스안에 있으니까 거기에 입력하여 출력하고 eCar.stop();와 eCar.checkBattery();는 자식값에 재정의하였기에 재정의한 데에 넣어 출력하는 건가요?
안녕하세요 선생님 항상 강의 잘 듣고 있습니다. 문제를 푸는 중에 궁금했던 건데요. 이런 코드에서 어떨 때는 배열 내 위치를 하나 더 움직이고 어떨 때는 ASCII 코드의 그 다음 알파벳을 뱉는데 이게 너무 헷갈립니다..ㅠ 주소에서 연산을 하는 거면 배열에서 위치를 옮기고 값에서 연산을 하는거면 ASCII코드에서 다음 알파벳을 뱉으면 되는건가요..? 주석에 제가 이해하는 법을 적어놨는데 이렇게 이해하면 되는걸까요? 특히, printf("%s", a+2); 이런 부분 같은 경우에는 a+2에서 a는 시작주소를 뜻하니 a[0], 따라서 a[0]+2 --> a[0]은 값이니 h, h라는 값에서+2하니까 j 이런 사고 과정으로도 흘러가는 거 같아 헷갈립니다..ㅠㅠ 답변 주시면 감사하겠습니다! # include <stdio.h> int main() { char a[6] = "hello"; printf("%s", a+2); // a는 시작주소(=a[0])를 뜻하니 a[0]의 주소에서 2번 옮김? -> llo printf("%c", a[1]+2); //a[1]은 값으로 e를 뱉으니 ASCII? -> g printf("%c", *a+1); // *a는 a[0]의 값 h를 뱉으니 ASCII? -> i printf("%c", *(a+1)); //(a+1)은 a[0]에서 하나를 더 움직인 주소 ->의 값 = e printf("%c", a[1]); // a[1] = e return 0; } 출력값 : llogiee
안녕하세요 강의 잘보고 있습니다. 13:15초에서 자식 호출 이전에 부모 호출을 통해 Constructor of A가 출력되는데 제가 궁금한 점은 B상속 이후 그러니까 class B extends A public B() { super.paint() //해당부분에서 왜 명시적 호출이 이루어지지 않는지가 궁금합니다 제가 생각했을 때는 super.paint()에 대한 매개변수가 지정되지 않았기 때문이다 public B() { 에 void가 추가되지 않았기 때문이다 라고 생각되는데 답변 주시면 감사하겠습니다.
강의를 수강한 후 수강생이 제작한 프로그램을 유튜브 채널 및 카페에 무료로 소개 해드립니다. 직접 프로그램을 만들어 공유해보는 재미를 얻어가시기 바랍니다. 에 대해 궁금해서 질문드립니다 블똑사 카페에서 수강생만 올릴수있는 혜택이 주어지나요? 어떻게 유튜브채널이나 카페에 홍보도와주시는거죠?
a = True if not a: print ( "a는 거짓입니다" ) else : print ( "a는 참입니다" ) 위 부분에서 a는 true인데, if not a 구문이 a 가 False 일때 실행되고, else 가 True일때 실행돼서 "a는 참입니다" 값이 나오는건가요?
# Licensed to the Apache Software Foundation (ASF) under one # or more contributor license agreements. See the NOTICE file # distributed with this work for additional information # regarding copyright ownership. The ASF licenses this file # to you under the Apache License, Version 2.0 (the # "License"); you may not use this file except in compliance # with the License. You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, # software distributed under the License is distributed on an # "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY # KIND, either express or implied. See the License for the # specific language governing permissions and limitations # under the License. # # Basic Airflow cluster configuration for CeleryExecutor with Redis and PostgreSQL. # # WARNING: This configuration is for local development. Do not use it in a production deployment. # # This configuration supports basic configuration using environment variables or an .env file # The following variables are supported: # # AIRFLOW_IMAGE_NAME - Docker image name used to run Airflow. # Default: apache/airflow:3.0.2 # AIRFLOW_UID - User ID in Airflow containers # Default: 50000 # AIRFLOW_PROJ_DIR - Base path to which all the files will be volumed. # Default: . # Those configurations are useful mostly in case of standalone testing/running Airflow in test/try-out mode # # _AIRFLOW_WWW_USER_USERNAME - Username for the administrator account (if requested). # Default: airflow # _AIRFLOW_WWW_USER_PASSWORD - Password for the administrator account (if requested). # Default: airflow # _PIP_ADDITIONAL_REQUIREMENTS - Additional PIP requirements to add when starting all containers. # Use this option ONLY for quick checks. Installing requirements at container # startup is done EVERY TIME the service is started. # A better way is to build a custom image or extend the official image # as described in https://airflow.apache.org/docs/docker-stack/build.html. # Default: '' # # Feel free to modify this file to suit your needs. --- x-airflow-common: &airflow-common # In order to add custom dependencies or upgrade provider distributions you can use your extended image. # Comment the image line, place your Dockerfile in the directory where you placed the docker-compose.yaml # and uncomment the "build" line below, Then run `docker-compose build` to build the images. image: ${AIRFLOW_IMAGE_NAME:-apache/airflow:3.0.2} # build: . environment: &airflow-common-env AIRFLOW__CORE__EXECUTOR: CeleryExecutor AIRFLOW__CORE__AUTH_MANAGER: airflow.providers.fab.auth_manager.fab_auth_manager.FabAuthManager AIRFLOW__DATABASE__SQL_ALCHEMY_CONN: postgresql+psycopg2://airflow:airflow@postgres/airflow AIRFLOW__CELERY__RESULT_BACKEND: db+postgresql://airflow:airflow@postgres/airflow AIRFLOW__CELERY__BROKER_URL: redis://:@redis:6379/0 AIRFLOW__CORE__FERNET_KEY: '' AIRFLOW__CORE__DAGS_ARE_PAUSED_AT_CREATION: 'true' AIRFLOW__CORE__LOAD_EXAMPLES: 'true' AIRFLOW__CORE__EXECUTION_API_SERVER_URL: 'http://airflow-apiserver:8080/execution/' # yamllint disable rule:line-length # Use simple http server on scheduler for health checks # See https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/logging-monitoring/check-health.html#scheduler-health-check-server # yamllint enable rule:line-length AIRFLOW__SCHEDULER__ENABLE_HEALTH_CHECK: 'true' # WARNING: Use _PIP_ADDITIONAL_REQUIREMENTS option ONLY for a quick checks # for other purpose (development, test and especially production usage) build/extend Airflow image. _PIP_ADDITIONAL_REQUIREMENTS: ${_PIP_ADDITIONAL_REQUIREMENTS:-} # The following line can be used to set a custom config file, stored in the local config folder AIRFLOW_CONFIG: '/opt/airflow/config/airflow.cfg' volumes: - ${AIRFLOW_PROJ_DIR:-.}/airflow/dags:/opt/airflow/dags - ${AIRFLOW_PROJ_DIR:-.}/logs:/opt/airflow/logs - ${AIRFLOW_PROJ_DIR:-.}/config:/opt/airflow/config - ${AIRFLOW_PROJ_DIR:-.}/airflow/plugins:/opt/airflow/plugins - ${AIRFLOW_PROJ_DIR:-.}/airflow/files:/opt/airflow/files user: "${AIRFLOW_UID:-50000}:0" depends_on: &airflow-common-depends-on redis: condition: service_healthy postgres: condition: service_healthy services: postgres_custom: image: postgres:13 environment: POSTGRES_USER: leeyujin POSTGRES_PASSWORD: leeyujin POSTGRES_DB: leeyujin volumes: - postgres-custom-db-volume:/var/lib/postgresql/data ports: - 5432:5432 networks: network_custom: ipv4_address: 172.28.0.3 postgres: image: postgres:13 environment: POSTGRES_USER: airflow POSTGRES_PASSWORD: airflow POSTGRES_DB: airflow volumes: - postgres-db-volume:/var/lib/postgresql/data healthcheck: test: ["CMD", "pg_isready", "-U", "airflow"] interval: 10s retries: 5 start_period: 5s restart: always ports: - 5431:5432 networks: network_custom: ipv4_address: 172.28.0.4 redis: # Redis is limited to 7.2-bookworm due to licencing change # https://redis.io/blog/redis-adopts-dual-source-available-licensing/ image: redis:7.2-bookworm expose: - 6379 healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 10s timeout: 30s retries: 50 start_period: 30s restart: always networks: network_custom: ipv4_address: 172.28.0.5 airflow-apiserver: <<: *airflow-common command: api-server ports: - "8080:8080" healthcheck: test: ["CMD", "curl", "--fail", "http://localhost:8080/api/v2/version"] interval: 30s timeout: 10s retries: 5 start_period: 30s restart: always depends_on: <<: *airflow-common-depends-on airflow-init: condition: service_completed_successfully networks: network_custom: ipv4_address: 172.28.0.6 airflow-scheduler: <<: *airflow-common command: scheduler healthcheck: test: ["CMD", "curl", "--fail", "http://localhost:8974/health"] interval: 30s timeout: 10s retries: 5 start_period: 30s restart: always depends_on: <<: *airflow-common-depends-on airflow-init: condition: service_completed_successfully networks: network_custom: ipv4_address: 172.28.0.7 postgres 실습 때문에 yaml 파일 수정 후부터 만든 모든 파일이 web ui에 안 올라가져요.. git을 통해 로컬이나 컨테이너 각 디렉토리에는 파일들이 잘 들어가있습니다. dag 파일 코드 오류일까봐 이미 올라가져있던 파일 코드 복붙해서 test_dag.py를 만들었는데 그것도 안 올라갑니다ㅜㅜ..
강의 25. [BE] 백엔드 Auth Guard 구현 시작. Auth Guard로 유저 아이디 가져오는 부분 작업 타임라인 19:55 여기까지는 정상적으로 진행됩니다. 쿠키에서 "authjs.session-token" 확인이 가능합니다. import NextAuth from "next-auth"; import { PrismaAdapter } from "@auth/prisma-adapter"; import { prisma } from "@/prisma"; import CredentialsProvider from "next-auth/providers/credentials"; import { comparePassword } from "@/lib/password-utils"; import * as jwt from "jsonwebtoken"; import { JWT } from "next-auth/jwt"; export const { handlers, auth, signIn, signOut } = NextAuth({ useSecureCookies: process.env.NODE_ENV === "production", trustHost: true, adapter: PrismaAdapter(prisma), secret: process.env.AUTH_SECRET, providers: [ CredentialsProvider({ name: "credentials", credentials: { email: { label: "이메일", type: "email", placeholder: "이메일 입력", }, password: { label: "비밀번호", type: "password", }, }, async authorize(credentials) { // 1. 모든 값들이 정상적으로 들어왔는가? if (!credentials || !credentials.email || !credentials.password) { throw new Error("이메일과 비밀번호를 입력해주세요."); } // 2. DB에서 유저를 찾기 const user = await prisma.user.findUnique({ where: { email: credentials.email as string, }, }); if (!user) { throw new Error("존재하지 않는 이메일입니다."); } // 3. 비밀번호 일치 여부 확인 const passwordMatch = comparePassword( credentials.password as string, user.hashedPassword as string ); if (!passwordMatch) { throw new Error("비밀번호가 일치하지 않습니다."); } return user; }, }), ], session: { strategy: "jwt", }, jwt: { encode: async ({ token, secret }) => { return jwt.sign(token as jwt.JwtPayload, secret as string); }, decode: async ({ token, secret }) => { return jwt.verify(token as string, secret as string) as JWT; }, }, pages: {}, callbacks: {}, }); FE 추가분 /frontend/auth.ts // ... 중략 import * as jwt from "jsonwebtoken"; import { JWT } from "next-auth/jwt"; export const { handlers, auth, signIn, signOut } = NextAuth({ // ...중략 jwt: { encode: async ({ token, secret }) => { return jwt.sign(token as jwt.JwtPayload, secret as string); }, decode: async ({ token, secret }) => { return jwt.verify(token as string, secret as string) as JWT; }, }, // ... 중략 }) pnpm add jsonwebtoken pnpm add -D @types/jsonwebtoken GET /api/auth/csrf 200 in 47ms POST /api/auth/callback/credentials? 200 in 114ms [auth][error] JWTSessionError: Read more at https://errors.authjs.dev#jwtsessionerror [auth][cause]: Error: The edge runtime does not support Node.js 'crypto' module. Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime at Object.get (C:\Users\svx32\OneDrive\바탕 화면\v5\frontend\.next\server\edge\chunks\_6e5868ec._.js:62:41) at C:\Users\svx32\OneDrive\바탕 화면\v5\frontend\.next\server\edge\chunks\node_modules__pnpm_d2b00409._.js:8647:62 at getSecret (C:\Users\svx32\OneDrive\바탕 화면\v5\frontend\.next\server\edge\chunks\node_modules__pnpm_d2b00409._.js:8630:20) at push.[project]/node_modules/.pnpm/jsonwebtoken@9.0.2/node_modules/jsonwebtoken/verify.js [middleware-edge] (ecmascript).module.exports (C:\Users\svx32\OneDrive\바 탕 화면\v5\frontend\.next\server\edge\chunks\node_modules__pnpm_d2b00409._.js:8633:12) at Object.decode (C:\Users\svx32\OneDrive\바탕 화면\v5\frontend\.next\server\edge\chunks\[root-of-the-server]__273b5c62._.js:137:233) at session (C:\Users\svx32\OneDrive\바탕 화면\v5\frontend\.next\server\edge\chunks\fdcd2_@auth_core_ec592ae5._.js:4516:39) at AuthInternal (C:\Users\svx32\OneDrive\바탕 화면\v5\frontend\.next\server\edge\chunks\fdcd2_@auth_core_ec592ae5._.js:5123:269) at async Auth (C:\Users\svx32\OneDrive\바탕 화면\v5\frontend\.next\server\edge\chunks\fdcd2_@auth_core_ec592ae5._.js:5379:34) at async handleAuth (C:\Users\svx32\OneDrive\바탕 화면\v5\frontend\.next\server\edge\chunks\node_modules__pnpm_d2b00409._.js:3913:29) at async C:\Users\svx32\OneDrive\바탕 화면\v5\frontend\.next\server\edge\chunks\_6e5868ec._.js:12505:20 [auth][details]: {} GET / 200 in 62ms --- 이 오류 메시지는 애플리케이션이 Edge Runtime 환경 에서 Node.js의 crypto 모듈을 사용하려고 시도 할 때 발생하는 JWTSessionError 입니다. 오류 상세 설명 JWTSessionError : 이는 JWT(JSON Web Token) 세션 관리 중에 문제가 발생했음을 나타냅니다. JWT는 웹 애플리케이션에서 사용자 세션을 처리하는 일반적인 방법입니다. The edge runtime does not support Node.js 'crypto' module. : 이 부분이 핵심 문제입니다. Edge Runtime (예: Next.js Edge Functions 또는 Middleware)은 빠르고 가볍게 설계된 환경입니다. 따라서 모든 Node.js API를 지원하지 않으며, 특히 암호화, 해싱, 디지털 서명 등에 사용되는 crypto 모듈을 포함하지 않습니다. JWT 작업은 이 crypto 모듈에 크게 의존합니다. 스택 트레이스 분석 : 오류 스택 트레이스를 보면 jsonwebtoken 패키지(특히 verify 작업 중)에서 crypto 모듈에 접근하려고 시도하며, 이 과정이 @auth/core (일반적으로 Auth.js 라이브러리)에서 호출됩니다. 이는 JWT 유효성 검사 프로세스가 crypto 모듈의 부재로 인해 실패하고 있음을 명확히 보여줍니다. 간단히 말해, 애플리케이션이 Edge Runtime이라는 제한된 서버리스 환경에서 JWT 유효성 검사(보안 관련 작업)를 수행하려고 하지만, 이 환경에는 해당 작업을 위한 필수 도구( crypto 모듈)가 없기 때문에 오류가 발생하는 것입니다. 해결 방법 (일반적인 접근) 이 문제를 해결하기 위해서는 주로 다음 방법들을 고려할 수 있습니다: JWT 관련 작업을 Edge Runtime 외부로 이동 : JWT 유효성 검사와 같이 crypto 모듈이 필요한 작업은 Edge Runtime이 아닌 일반적인 Node.js 서버 환경 (예: Next.js의 표준 API 라우트)에서 수행하도록 변경해야 합니다. 인증 라이브러리 설정 변경 : 사용하고 있는 인증 라이브러리(Auth.js)의 세션 전략을 변경하여 Edge Runtime 컨텍스트에서 crypto 모듈에 의존하지 않도록 구성해야 합니다. 예를 들어, JWT 기반 세션 대신 데이터베이스 세션과 같은 다른 세션 관리 방식을 고려할 수 있습니다. AUTH_SECRET 확인 : 직접적인 원인은 아니지만, AUTH_SECRET 환경 변수가 올바르게 설정되어 있고, 사용 중인 환경에 맞게 JWT를 안전하게 처리하는지 확인하는 것도 중요합니다. 어떻게 해결해야하나요??
