diff --git a/_data/es/general.yml b/_data/es/general.yml index e6327e6214..d6868853d1 100644 --- a/_data/es/general.yml +++ b/_data/es/general.yml @@ -1,8 +1,8 @@ -title_announcement: "Express@5.1.0: Now the Default on npm with LTS Timeline" -body_announcement: "Express 5.1.0 is now the default on npm, and we're introducing an official LTS schedule for the v4 and v5 release lines. Check out our latest blog for more information." -community-caveat-alert: "This information refers to third-party sites, products, or modules that are not maintained by the Expressjs team. Listing here does not constitute an endorsement or recommendation from the Expressjs project team." -warning: 'Warning' -note: 'Note' -caution: 'Caution' -i18n_notice: "This document might be outdated relative to the documentation in English. For the latest updates, please refer to the" -i18n_notice_link_text: "documentation in english" +title_announcement: "Express@5.1.0: Ahora el valor por defecto de npm con LTS Timeline" +body_announcement: "Express 5.1.0 es ahora el predeterminado en npm, y estamos introduciendo un horario oficial de LTS para las líneas de lanzamiento v4 y v5. Mira nuestro último blog para más información." +community-caveat-alert: "Esta información se refiere a sitios, productos o módulos de terceros que no son mantenidos por el equipo de Expressjs. La lista aquí no constituye un respaldo o una recomendación del equipo del proyecto Expressjs." +warning: 'Advertencia' +note: 'Nota' +caution: 'Advertencia' +i18n_notice: "Este documento puede estar desactualizado en relación con la documentación en inglés. Para las últimas actualizaciones, por favor consulte el" +i18n_notice_link_text: "documentación en inglés" diff --git a/_data/ko/menu.yml b/_data/ko/menu.yml index 7bef82a1e8..a32177d39c 100644 --- a/_data/ko/menu.yml +++ b/_data/ko/menu.yml @@ -7,14 +7,14 @@ hello_world: Hello world generator: Express 생성기 basic_routing: 기본 라우팅 static_files: 정적 파일 -examples: More examples +examples: 더 많은 예시 faq: 자주 묻는 질문(FAQ) # Guide guide: Gu안내서ide routing: 라우팅 writing_middleware: 미들웨어 작성 using_middleware: 미들웨어 사용 -overriding_express_api: Overriding the Express API +overriding_express_api: Express API 오버라이딩 using_template_engines: 템플리트 엔진 사용 error_handling: 오류 처리 debugging: 디버깅 @@ -40,13 +40,13 @@ resources: 자원 glossary: 용어집 middleware: 미들웨어 community: 커뮤니티 -utils: Utility modules -contributing: Contributing to Express -changelog: Release Change Log +utils: 유틸리티 모듈 +contributing: Express에 기여하기 +changelog: 릴리즈 변경 로그 # Support -support: Support +support: 지원 # Blog blog: Blog -latest_post: Latest post -all_posts: All posts -write_post: Write a Post +latest_post: 최신 게시물 +all_posts: 모든 게시물 +write_post: 게시물 작성 diff --git a/de/guide/writing-middleware.md b/de/guide/writing-middleware.md index 5b77689ef0..c4d5653244 100644 --- a/de/guide/writing-middleware.md +++ b/de/guide/writing-middleware.md @@ -23,6 +23,7 @@ Wenn über die aktuelle Middlewarefunktion der Anforderung/Antwort-Zyklus nicht Das folgende Beispiel zeigt die Elemente eines Middlewarefunktionsaufrufs: +
Elements of a middleware function call @@ -41,6 +42,7 @@ Das folgende Beispiel zeigt die Elemente eines Middlewarefunktionsaufrufs:
HTTP-Anforderungsargument zur Middlewarefunktion, die nach der geltenden Konvention als "req" bezeichnet wird.
+
Starting with Express 5, middleware functions that return a Promise will call `next(value)` when they reject or throw an error. `next` will be called with either the rejected value or the thrown Error. diff --git a/es/api.md b/es/api.md index c022b8941e..2d382a84d6 100644 --- a/es/api.md +++ b/es/api.md @@ -2,7 +2,7 @@ layout: api version: 5x title: Express 5.x - Referencia de API -description: Access the API reference for Express.js detailing all modules, methods, and properties for building web applications with this version. +description: Acceda a la referencia de la API para Express.js detallando todos los módulos, métodos y propiedades para construir aplicaciones web con esta versión. redirect_from: " " --- diff --git a/es/guide/writing-middleware.md b/es/guide/writing-middleware.md index 0896bc8f1a..2c5a6aa1af 100644 --- a/es/guide/writing-middleware.md +++ b/es/guide/writing-middleware.md @@ -23,6 +23,7 @@ Si la función de middleware actual no finaliza el ciclo de solicitud/respuestas El siguiente ejemplo muestra los elementos de una llamada a función de middleware: +
Elements of a middleware function call @@ -41,6 +42,7 @@ El siguiente ejemplo muestra los elementos de una llamada a función de middlewa
Argumento de solicitud HTTP a la función de middleware, denominado "req" por convención.
+
Starting with Express 5, middleware functions that return a Promise will call `next(value)` when they reject or throw an error. `next` will be called with either the rejected value or the thrown Error. diff --git a/es/index.md b/es/index.md index 8f57ad5f5d..f4e28023d0 100644 --- a/es/index.md +++ b/es/index.md @@ -1,7 +1,7 @@ --- layout: home -title: Express - Node.js web application framework -description: "Express is a fast, unopinionated, minimalist web framework for Node.js, providing a robust set of features for web and mobile applications." +title: Express - Node.js Marco de aplicación web +description: "Express es un marco web rápido, sin opinión y minimalista para Node.js, que proporciona un robusto conjunto de características para aplicaciones web y móviles." menu: home redirect_from: " " --- @@ -9,8 +9,8 @@ redirect_from: " "
-
Express{{ site.data.express.current_version }}
-

Fast, unopinionated, minimalist web framework for Node.js

+
Express{{ site.data.express.current_version }}
+

Marco web rápido, sin opinión y minimalista para Node.js

$ npm install express --save
@@ -38,24 +38,22 @@ app.listen(port, () => {
{% include announcement.html %} -
-{% endif %} +
{% endif %}
-

Web Applications

Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications. -
+

Aplicaciones web

Express es un minimalista y flexible framework de aplicaciones web de Node.js que provee un conjunto robusto de características para aplicaciones web y móviles
-

APIs

With a myriad of HTTP utility methods and middleware at your disposal, creating a robust API is quick and easy. +

APIs

Con una gran cantidad de métodos de utilidad HTTP y middleware a tu disposición, crear una API robusta es rápido y fácil.
-

Performance

Express provides a thin layer of fundamental web application features, without obscuring Node.js features that you know and love. +

Rendimiento

Express proporciona una capa delgada de características fundamentales de la aplicación web, sin ocultar las características de Node.js que usted conoce y ama.

Middleware

- Express is a lightweight and flexible routing framework with minimal core features - meant to be augmented through the use of Express middleware modules. + Express es un marco de enrutamiento ligero y flexible con las características básicas mínimas + destinado a aumentarse mediante el uso de módulos middleware.
diff --git a/fr/guide/writing-middleware.md b/fr/guide/writing-middleware.md index c7a6441829..9c64f8f560 100644 --- a/fr/guide/writing-middleware.md +++ b/fr/guide/writing-middleware.md @@ -23,6 +23,7 @@ Si la fonction middleware en cours ne termine pas le cycle de demande-réponse, L'exemple suivant montre les éléments d'un appel de fonction middleware: +
Elements of a middleware function call @@ -41,6 +42,7 @@ L'exemple suivant montre les éléments d'un appel de fonction middleware:
Argument de demande HTTP à la fonction middleware, appelé "req" par convention.
+
Starting with Express 5, middleware functions that return a Promise will call `next(value)` when they reject or throw an error. `next` will be called with either the rejected value or the thrown Error. diff --git a/it/guide/writing-middleware.md b/it/guide/writing-middleware.md index 84a7c12e78..d2d105f878 100644 --- a/it/guide/writing-middleware.md +++ b/it/guide/writing-middleware.md @@ -23,6 +23,7 @@ Se la funzione middleware corrente non termina il ciclo richiesta-risposta, deve I seguenti esempi mostrano gli elementi di una chiamata alla funzione middleware: +
Elements of a middleware function call @@ -41,6 +42,7 @@ I seguenti esempi mostrano gli elementi di una chiamata alla funzione middleware
Argomento richiesta HTTP nella funzione middleware, denominato "req" per convenzione.
+
Starting with Express 5, middleware functions that return a Promise will call `next(value)` when they reject or throw an error. `next` will be called with either the rejected value or the thrown Error. diff --git a/ja/guide/writing-middleware.md b/ja/guide/writing-middleware.md index 0700e401c3..265b6b9c52 100644 --- a/ja/guide/writing-middleware.md +++ b/ja/guide/writing-middleware.md @@ -23,6 +23,7 @@ _ミドルウェア_ 関数は、[リクエストオブジェクト](/{{ page.la 次の例は、ミドルウェア関数呼び出しの要素を示しています。 +
Elements of a middleware function call @@ -41,6 +42,7 @@ _ミドルウェア_ 関数は、[リクエストオブジェクト](/{{ page.la
ミドルウェア関数への HTTP リクエスト引数 (慣習的に「req」と呼ばれます)。
+
Starting with Express 5, middleware functions that return a Promise will call `next(value)` when they reject or throw an error. `next` will be called with either the rejected value or the thrown Error. diff --git a/ko/3x/api.md b/ko/3x/api.md index 92e474124e..8274d7f3dd 100644 --- a/ko/3x/api.md +++ b/ko/3x/api.md @@ -13,7 +13,7 @@ redirect_from: " " 3.x의 알려진 또는 알려지지 않은 보안 및 성능 문제는 마지막 업데이트(2015년 8월 1일) 이후로 처리되지 않고 있습니다. 최신 버전의 Express를 사용할 것을 강력히 권장합니다. -If you are unable to upgrade past 3.x, please consider [Commercial Support Options](/{{ page.lang }}/support#commercial-support-options). +버전 3.x 이상으로 업그레이드할 수 없는 경우, [상업적 지원 옵션](/{{ page.lang }}/support#commercial-support-options)을 고려해주시기 바랍니다. diff --git a/ko/4x/api.md b/ko/4x/api.md index ef0ab0a78b..8ebbd30613 100644 --- a/ko/4x/api.md +++ b/ko/4x/api.md @@ -2,7 +2,7 @@ layout: api version: 4x title: Express 4.x - API 참조 -description: Access the API reference for Express.js 4.x, detailing all modules, methods, and properties for building web applications with this version. +description: Express.js 4.x의 API 레퍼런스를 확인하여, 이 버전으로 웹 애플리케이션을 구축할 때 사용할 수 있는 모든 모듈, 메서드, 속성에 대해 자세히 알아봅니다. redirect_from: " " --- @@ -12,7 +12,7 @@ redirect_from: " " {% capture node-version %} -Express 4.0 requires Node.js 0.10 or higher. +Express 4.0에는 Node.js 0.10 이상이 필요합니다. {% endcapture %} diff --git a/ko/5x/api.md b/ko/5x/api.md index 9214124848..f2d5cb96af 100644 --- a/ko/5x/api.md +++ b/ko/5x/api.md @@ -2,7 +2,7 @@ layout: api version: 5x title: Express 5.x - API 참조 -description: Access the API reference for Express.js 5.x, detailing all modules, methods, and properties for building web applications with this latest version. +description: Express.js 5.x의 API 레퍼런스를 확인하여, 이 버전으로 웹 애플리케이션을 구축할 때 사용할 수 있는 모든 모듈, 메서드, 속성에 대해 자세히 알아봅니다. redirect_from: " " --- @@ -12,7 +12,7 @@ redirect_from: " " {% capture node-version %} -Express 5.0 requires Node.js 18 or higher. +Express 5.0에는 Node.js 18 이상이 필요합니다. {% endcapture %} diff --git a/ko/advanced/best-practice-performance.md b/ko/advanced/best-practice-performance.md index fd79e9ac5c..373816c548 100644 --- a/ko/advanced/best-practice-performance.md +++ b/ko/advanced/best-practice-performance.md @@ -25,7 +25,7 @@ redirect_from: " " - [로드 밸런서 사용](#use-a-load-balancer) - [역방향 프록시 사용](#proxy) -## Things to do in your code {#in-code} +## 코드에서 해야 할 일 {#in-code} 애플리케이션의 성능을 향상시키기 위해서 코드를 통해 할 수 있는 몇 가지는 다음과 같습니다. @@ -56,17 +56,17 @@ Node 및 다수의 모듈은 동기식 및 비동기식 버전의 함수를 제 애플리케이션이 동기 API를 사용할 때마다 경고 메시지와 스택 트레이스를 출력하려면 --trace-sync-io 명령줄 플래그를 사용할 수 있습니다. 물론, 프로덕션 환경에서 이러한 플래그를 실제로 사용해서는 안 되며, 이는 코드가 프로덕션 환경에서 사용될 준비가 되었다는 것을 보장하기 위한 것입니다. 자세한 정보는 [node 커맨드라인 옵션 문서](https://nodejs.org/api/cli.html#cli_trace_sync_io)를 참조하십시오. -### Do logging correctly +### 올바른 로깅 방법을 사용해야 합니다 일반적으로 앱은 디버깅 그리고 앱 활동 로깅(사실상 디버깅 이외의 모든 것)이라는 두 가지 이유로 인해 로깅을 실행합니다. `console.log()` 또는 `console.err()`을 사용하여 터미널에 로그 메시지를 출력하는 것이 일반적인 개발 작업 방식입니다. 단, [이 함수들은](https://nodejs.org/api/console.html#console) 출력 대상이 터미널이나 파일일 경우 동기적으로 동작하므로, 출력 결과를 다른 프로그램으로 파이프하지 않는 이상 프로덕션 환경에서는 적합하지 않습니다. -#### For debugging +#### 디버깅의 경우 디버깅을 위해 로깅하는 경우에는 `console.log()`를 사용하는 대신 [debug](https://www.npmjs.com/package/debug)와 같은 특별한 디버깅 모듈을 사용하십시오. 이러한 모듈을 이용하면 DEBUG 환경 변수를 사용하여 디버그 메시지 발생 시 어떠한 디버그 메시지가 `console.err()`로 전송되는지 제어할 수 있습니다. 앱을 순수한 비동기식으로 유지하려면 `console.err()`을 다른 프로그램으로 전송해야 합니다. 그러나 아마도 프로덕션 단계에서 디버그를 수행할 필요는 없을 것입니다. -#### For app activity +#### 앱 활동의 경우 -If you're logging app activity (for example, tracking traffic or API calls), instead of using `console.log()`, use a logging library like [Pino](https://www.npmjs.com/package/pino), which is the fastest and most efficient option available. +애플리케이션 활동(예: 트래픽 추적 또는 API 호출 기록)을 로깅할 때는 console.log() 대신 [Pino](https://www.npmjs.com/package/pino)와 같은 로깅 라이브러리를 사용하는 것이 좋습니다. Pino는 가장 빠르고 효율적인 옵션입니다. ### 올바른 예외 처리 @@ -81,7 +81,7 @@ Node 앱은 처리되지 않은 예외가 발생할 때 충돌이 발생합니 오류 처리의 기본사항 대한 자세한 내용은 다음을 참조하십시오. -- [Error Handling in Node.js](https://www.tritondatacenter.com/node-js/production/design/errors) +- [Node.js의 오류 처리](https://www.tritondatacenter.com/node-js/production/design/errors) #### try-catch 사용 @@ -109,7 +109,8 @@ app.get('/search', (req, res) => { #### 프로미스 사용 -When an error is thrown in an `async` function or a rejected promise is awaited inside an `async` function, those errors will be passed to the error handler as if calling `next(err)` +async 함수 내에서 에러가 발생하거나, async 함수 안에서 거부된(rejected) 프로미스를 await 할 경우, 해당 에러는`next(err)`를 호출한 것과 동일하게 에러 핸들러로 전달됩니다. +자세한 내용은 Node.js 에러 처리 문서를 참고하시기 바랍니다. ```js app.get('/', async (req, res, next) => { @@ -123,7 +124,7 @@ app.use((err, req, res, next) => { }) ``` -Also, you can use asynchronous functions for your middleware, and the router will handle errors if the promise fails, for example: +또한 미들웨어에 비동기 함수를 사용할 수 있으며, 만약 프로미스가 실패할 경우 라우터가 자동으로 에러를 처리합니다 예를 들면 다음과 같습니다. ```js app.use(async (req, res, next) => { @@ -133,9 +134,9 @@ app.use(async (req, res, next) => { }) ``` -Best practice is to handle errors as close to the site as possible. So while this is now handled in the router, it’s best to catch the error in the middleware and handle it without relying on separate error-handling middleware. +성능과 유지 보수 측면에서 가장 좋은 방법은 에러를 가능한 발생 지점 가까이에서 처리하는 것입니다. 따라서 라우터가 에러를 처리할 수 있더라도 별도의 에러 처리 미들웨어에 의존하기보다 미들웨어 내에서 에러를 직접 잡아 처리하는 것이 권장됩니다. -#### What not to do +#### 하지 말아야 할 일 수행하지 _않아야_ 할 한 가지 항목은 예외가 이벤트 루프에까지 발생할 때 생성되는 `uncaughtException` 이벤트를 청취하는 것입니다. `uncaughtException`에 대한 이벤트 리스너를 추가하면 예외가 발생하는 프로세스의 기본 작동을 변경할 수 있으며, 해당 프로세스는 예외가 발생하더라도 계속하여 실행될 것입니다. 이러한 방법은 앱에서 충돌이 발생하는 것을 방지하는 좋은 방법인 것처럼 보일 수 있지만, 처리되지 않은 예외가 발생한 후에도 앱이 계속하여 실행되면 프로세스가 불안정하고 예측할 수 없는 상태가 되므로 이러한 방법은 위험한 작업 방식이며 권장되지 않습니다. @@ -156,7 +157,7 @@ Best practice is to handle errors as close to the site as possible. So while thi ### NODE_ENV를 "production"으로 설정 -NODE_ENV 환경 변수는 애플리케이션이 실행되는 환경(일반적으로 개발 환경 또는 프로덕션 환경)을 지정합니다. One of the simplest things you can do to improve performance is to set NODE_ENV to `production`. +NODE_ENV 환경 변수는 애플리케이션이 실행되는 환경(일반적으로 개발 환경 또는 프로덕션 환경)을 지정합니다. 성능을 향상하는 가장 간단한 방법 중 하나는 환경 변수 NODE_ENV를 `production`으로 설정하는 것입니다. NODE_ENV를 "production"으로 설정하면 Express는 다음과 같이 동작합니다. @@ -164,11 +165,11 @@ NODE_ENV를 "production"으로 설정하면 Express는 다음과 같이 동작 - CSS 확장기능을 통해 생성된 CSS 파일을 캐싱. - 더 간결한 오류 메시지를 생성. -[Tests indicate](https://www.dynatrace.com/news/blog/the-drastic-effects-of-omitting-node-env-in-your-express-js-applications/) that just doing this can improve app performance by a factor of three! +[테스트 결과에 따르면]((https://www.dynatrace.com/news/blog/the-drastic-effects-of-omitting-node-env-in-your-express-js-applications/) NODE_ENV를 production으로 설정하는 것만으로도 애플리케이션 성능이 3배 향상될 수 있음이 확인되었습니다. 특정한 환경을 위한 코드를 작성하는 경우, `process.env.NODE_ENV`를 통해 NODE_ENV의 값을 확인할 수 있습니다. 환경 변수의 값을 확인하는 작업은 성능 저하를 유발하므로 이러한 작업은 낮은 빈도로 실행해야 한다는 점에 주의하십시오. -일반적으로 개발 시에는, 예를 들면 `export` 또는 `.bash_profile` 파일을 이용하여 대화식 쉘에서 환경 변수를 설정할 수 있습니다. But in general, you shouldn't do that on a production server; instead, use your OS's init system (systemd). 다음 섹션에서 일반적인 init 시스템의 사용에 대한 자세한 내용을 확인할 수 있지만, NODE_ENV를 설정하는 것은 성능에 매우 중요하므로(또한 쉽게 실행할 수 있으므로) NODE_ENV의 설정을 여기서 강조합니다. +일반적으로 개발 시에는, 예를 들면 `export` 또는 `.bash_profile` 파일을 이용하여 대화식 쉘에서 환경 변수를 설정할 수 있습니다. 하지만 일반적으로 프로덕션 서버에서는 직접 설정하지 않고, 대신 운영체제의 초기화 시스템(systemd 등) 사용하는 것이 권장됩니다. 다음 섹션에서 일반적인 init 시스템의 사용에 대한 자세한 내용을 확인할 수 있지만, NODE_ENV를 설정하는 것은 성능에 매우 중요하므로(또한 쉽게 실행할 수 있으므로) NODE_ENV의 설정을 여기서 강조합니다. systemd를 이용하는 경우, 유닛 파일에 `Environment` 지시문을 사용하십시오. 예를 들면 다음과 같습니다. @@ -177,7 +178,7 @@ systemd를 이용하는 경우, 유닛 파일에 `Environment` 지시문을 사 Environment=NODE_ENV=production ``` -For more information, see [Using Environment Variables In systemd Units](https://www.flatcar.org/docs/latest/setup/systemd/environment-variables/). +자세한 내용은 [systemd 유닛에서 환경 변수 사용하기를](https://www.flatcar.org/docs/latest/setup/systemd/environment-variables/) 참고하시기 바랍니다. ### 앱이 자동으로 다시 시작되도록 보장 @@ -196,13 +197,13 @@ For more information, see [Using Environment Variables In systemd Units](https:/ - 런타임 성능 및 자원 소비에 대한 통찰력을 획득. - 성능 향상을 위해 설정을 동적으로 수정. -- Control clustering (pm2). +- 제어 클라스터링 (pm2) -Historically, it was popular to use a Node.js process manager like [PM2](https://github.com/Unitech/pm2). See their documentation if you wish to do this. However, we recommend using your init system for process management. +과거에는 [PM2](https://github.com/Unitech/pm2)와 같은 Node.js 프로세스 매니저를 사용하는 것이 널리 퍼져 있었습니다. 원하신다면 해당 문서를 참고하시기 바랍니다. 하지만 프로세스 관리를 위해서는 init 시스템을 사용하는 것을 권장합니다. #### init 시스템 사용 -신뢰성의 다음 단계는 서버가 다시 시작될 때 애플리케이션이 다시 시작되도록 하는 것입니다. 시스템은 여전히 여러 이유로 작동이 중단될 수 있습니다. 서버에서 충돌이 발생할 때 앱이 다시 시작되도록 하려면 OS에 내장된 init 시스템을 사용하십시오. The main init system in use today is [systemd](https://wiki.debian.org/systemd). +신뢰성의 다음 단계는 서버가 다시 시작될 때 애플리케이션이 다시 시작되도록 하는 것입니다. 시스템은 여전히 여러 이유로 작동이 중단될 수 있습니다. 서버에서 충돌이 발생할 때 앱이 다시 시작되도록 하려면 OS에 내장된 init 시스템을 사용하십시오. 현재 가장 널리 사용되는 init 시스템은 [systemd](https://wiki.debian.org/systemd)입니다. Express 앱에 init 시스템을 사용하는 데에는 다음과 같은 두 가지 방법이 있습니다. @@ -213,7 +214,7 @@ Express 앱에 init 시스템을 사용하는 데에는 다음과 같은 두 가 Systemd는 Linux용 시스템 및 서비스 관리자입니다. 대부분의 주요 Linux 배포판은 systemd를 기본 init 시스템으로 도입했습니다. -systemd 서비스 구성 파일은 \*유닛 파일(unit file)\*로 불리며, 파일 이름이 .service로 끝납니다. Here's an example unit file to manage a Node app directly. Replace the values enclosed in `` for your system and app: +systemd 서비스 구성 파일은 \*유닛 파일(unit file)\*로 불리며, 파일 이름이 .service로 끝납니다. 아래는 Node 애플리케이션을 직접 관리하기 위한 파일 예시입니다. 시스템과 애플리케이션에 맞게 `` 로 표시된 값을 교체하시기 바랍니다. ```sh [Unit] @@ -251,7 +252,7 @@ systemd에 대한 자세한 정보는 [systemd 참조 자료(man page)](http://w 멀티코어 시스템에서는 프로세스 클러스터를 실행하여 Node 앱의 성능을 여러 배 높일 수 있습니다. 클러스터는 해당 앱의 인스턴스를 여러 개 실행하여(이상적인 경우 각 CPU 코어에서 하나의 인스턴스를 실행) 인스턴스들 사이에서 로드 및 태스크를 분배합니다. -![Balancing between application instances using the cluster API](/images/clustering.png) +![클러스터 API를 사용한 애플리케이션 인스턴스간 부하 분산](/images/clustering.png) 중요: 앱 인스턴스들은 별도의 프로세스로서 실행되므로 이러한 인스턴스들은 동일한 메모리 공간을 공유하지 않습니다. 즉, 오브젝트는 해당 앱의 각 인스턴스에 대한 로컬 오브젝트입니다. 따라서 애플리케이션 코드 내의 상태를 유지보수할 수 없습니다. 그러나 [Redis](http://redis.io/)와 같은 인메모리 데이터 저장소를 사용하면 세션과 관련된 데이터 및 상태를 저장할 수 있습니다. 이러한 주의사항은 기본적으로 여러 프로세스를 이용한 클러스터링 또는 여러 대의 실제 서버를 이용한 클러스터링 등 모든 형태의 수평적 확장에 적용됩니다. @@ -259,11 +260,11 @@ systemd에 대한 자세한 정보는 [systemd 참조 자료(man page)](http://w #### Node의 cluster 모듈 사용 -Clustering is made possible with Node's [cluster module](https://nodejs.org/api/cluster.html). 이러한 클러스터링을 통해 마스터 프로세스는 여러 작업자 프로세스를 복제생성하고, 수신되는 연결을 여러 작업자 사이에서 분배할 수 있습니다. +클러스터링은 Node의 [cluster 모듈](https://nodejs.org/api/cluster.html)을 통해 가능합니다. 이러한 클러스터링을 통해 마스터 프로세스는 여러 작업자 프로세스를 복제생성하고, 수신되는 연결을 여러 작업자 사이에서 분배할 수 있습니다. #### PM2 사용 -애플리케이션을 PM2에 배치하면, 애플리케이션 코드를 수정하지 _않고도_ 클러스터링을 활용할 수 있습니다. You should ensure your [application is stateless](https://pm2.keymetrics.io/docs/usage/specifics/#stateless-apps) first, meaning no local data is stored in the process (such as sessions, websocket connections and the like). +애플리케이션을 PM2에 배치하면, 애플리케이션 코드를 수정하지 _않고도_ 클러스터링을 활용할 수 있습니다. 먼저 [애플리케이션이 상태 비저장(stateless)](https://pm2.keymetrics.io/docs/usage/specifics/#stateless-apps)인지 확인해야 합니다 즉, 프로세스 내에 세션, 웹소켓 연결 등 로컬 데이터가 저장되어 있지 않아야 합니다. PM2로 애플리케이션을 실행하고 있을 때, 특정한 수의 인스턴스에 실행하는 **클러스터 모드**를 켤 수 있습니다. 머신의 가용 CPU 수같은 것들이 특정한 수입니다. 애플리케이션을 끌 필요 없이 `pm2` 커맨드라인 명령을 이용해 클러스터에 있는 프로세스의 수를 직접 바꿀 수도 있습니다. @@ -293,13 +294,14 @@ PM2의 클러스터링에 관한 추가 정보는 PM2 문서의 [Cluster Mode](h 프로덕션 환경 내에서의 성능을 향상시키기 위한 또 다른 전략은 요청의 결과를 캐싱하여 앱이 동일한 요청을 반복적으로 제공하는 작업을 반복하지 않도록 하는 것입니다. -Use a caching server like [Varnish](https://www.varnish-cache.org/) or [Nginx](https://blog.nginx.org/blog/nginx-caching-guide) (see also [Nginx Caching](https://serversforhackers.com/nginx-caching/)) to greatly improve the speed and performance of your app. +애플리케이션의 속도와 성능을 크게 향상시키려면 [Varnish](https://www.varnish-cache.org/) 또는 [Nginx](https://blog.nginx.org/blog/nginx-caching-guide)와 같은 캐싱 서버를 사용하는 것이 좋습니다. +(참고: [Nginx 캐싱 가이드](https://serversforhackers.com/nginx-caching/)) ### 로드 밸런서 사용 앱의 최적화 수준에 상관없이, 하나의 인스턴스는 제한된 양의 로드 및 트래픽만을 처리할 수 있습니다. 앱을 확장하는 방법 중 하나는 해당 앱의 인스턴스를 여러 개 실행하고 로드 밸런서를 통해 트래픽을 분배하는 것입니다. 로드 밸런서를 설정하면 앱의 성능 및 속도를 향상시킬 수 있으며, 하나의 인스턴스를 이용할 때보다 훨씬 더 높은 수준으로 확장할 수 있습니다. -로드 밸런서는 일반적으로 여러 애플리케이션 인스턴스 및 서버에 대한 트래픽을 오케스트레이션하는 역방향 프록시입니다. You can easily set up a load balancer for your app by using [Nginx](https://nginx.org/en/docs/http/load_balancing.html) or [HAProxy](https://www.digitalocean.com/community/tutorials/an-introduction-to-haproxy-and-load-balancing-concepts). +로드 밸런서는 일반적으로 여러 애플리케이션 인스턴스 및 서버에 대한 트래픽을 오케스트레이션하는 역방향 프록시입니다. 애플리케이션의 로드 밸런서를 손쉽게 구축하려면 [Nginx](https://nginx.org/en/docs/http/load_balancing.html)또는 [HAProxy](https://www.digitalocean.com/community/tutorials/an-introduction-to-haproxy-and-load-balancing-concepts)를 활용할 수 있습니다. 로드 밸런싱을 이용하는 경우, 특정한 세션 ID와 연관된 요청이 해당 요청을 발생시킨 프로세스에 연결되도록 해야 할 수도 있습니다. 이러한 경우는 _세션 선호도(session affinity)_ 또는 \*스티키 세션(sticky session)\*으로 알려져 있으며, 세션 데이터를 위해 Redis와 같은 데이터 저장소를 사용하는 위의 제안을 통해 처리할 수도 있습니다(애플리케이션에 따라 다름). 토론을 위해서는 [Using multiple nodes](https://socket.io/docs/v4/using-multiple-nodes/)를 참조하십시오. @@ -307,4 +309,4 @@ Use a caching server like [Varnish](https://www.varnish-cache.org/) or [Nginx](h 역방향 프록시는 웹 앱의 프론트에 위치하며, 요청이 앱으로 전달되도록 할 뿐만 아니라 요청에 대한 지원 연산을 수행합니다. 이는 오류 페이지, 압축, 캐싱, 파일 제공, 로드 밸런싱 및 기타 여러 작업을 처리할 수 있습니다. -애플리케이션 상태를 알아야 할 필요가 없는 태스크를 역방향 프록시로 이양하면 Express는 더 적은 자원을 차지하게 되어 특성화된 애플리케이션 태스크를 수행할 수 있습니다. For this reason, it is recommended to run Express behind a reverse proxy like [Nginx](https://www.nginx.org/) or [HAProxy](https://www.haproxy.org/) in production. +애플리케이션 상태를 알아야 할 필요가 없는 태스크를 역방향 프록시로 이양하면 Express는 더 적은 자원을 차지하게 되어 특성화된 애플리케이션 태스크를 수행할 수 있습니다. 이러한 이유로 프로덕션환경에서는 Express를 [Nginx](https://www.nginx.org/) 또는 [HAProxy](https://www.haproxy.org/)와 같은 리버스 프록시 뒤에서 실행하는 것을 권장합니다. diff --git a/ko/advanced/best-practice-security.md b/ko/advanced/best-practice-security.md index 24b98c85cc..43155eb952 100644 --- a/ko/advanced/best-practice-security.md +++ b/ko/advanced/best-practice-security.md @@ -1,7 +1,7 @@ --- layout: page title: 프로덕션 환경의 Express를 위한 보안 우수 사례 -description: Discover crucial security best practices for Express apps in production, including using TLS, input validation, secure cookies, and preventing vulnerabilities. +description: Express 애플리케이션을 프로덕션 환경에서 운영할 때 반드시 지켜야 할 중요한 보안 모범 사례를 알아봅니다. 여기에는 TLS 사용, 입력값 검증, 보안 쿠키 설정, 그리고 다양한 취약점 예방 방법이 포함됩니다. menu: advanced redirect_from: " " --- @@ -16,8 +16,7 @@ redirect_from: " " {% capture security-note %} -If you believe you have discovered a security vulnerability in Express, please see -[Security Policies and Procedures](/en/resources/contributing.html#security-policies-and-procedures). +만약 Express에서 보안 취약점을 발견하셨다면, [보안 정책 및 절차](/en/resources/contributing.html#security-policies-and-procedures)를 참고하시기 바랍니다. {% endcapture %} @@ -25,14 +24,14 @@ If you believe you have discovered a security vulnerability in Express, please s 이 문서에서는 프로덕션 환경에 배치된 Express 애플리케이션을 위한 몇 가지 보안 우수 사례에 대해 논의합니다. -- [Production Best Practices: Security](#production-best-practices-security) - - [Overview](#overview) - - [Don't use deprecated or vulnerable versions of Express](#dont-use-deprecated-or-vulnerable-versions-of-express) +- [프로덕션 모범 사례: 보안](#production-best-practices-security) + - [개요](#overview) + - [Express의 사용 중단되었거나 취약한 버전을 사용하지 않습니다](#dont-use-deprecated-or-vulnerable-versions-of-express) - [TLS 사용](#use-tls) - - [Do not trust user input](#do-not-trust-user-input) - - [Prevent open redirects](#prevent-open-redirects) + - [사용자 입력을 신뢰하지 않습니다](#do-not-trust-user-input) + - [오픈 리다이렉트를 방지합니다](#prevent-open-redirects) - [Helmet 사용](#use-helmet) - - [Reduce fingerprinting](#reduce-fingerprinting) + - [지문 인식 감소](#reduce-fingerprinting) - [쿠키를 안전하게 사용](#use-cookies-securely) - - [ieNoOpen](https://github.com/helmetjs/ienoopen)은 IE8 이상에 대해 `X-Download-Options`를 설정합니다. @@ -55,19 +54,19 @@ Express 2.x 및 3.x에 대한 유지보수는 더 이상 이루어지지 않습 또한 무료 TLS 인증서를 얻기 위한 편리한 도구 중 하나는 [Internet Security Research Group(ISRG)](https://letsencrypt.org/isrg/)이 제공하는 무료의 자동 개방형 인증 기관(CA)인 [Let's Encrypt](https://letsencrypt.org/about/)입니다. -## Do not trust user input +## 사용자 입력을 신뢰하지 않습니다 -For web applications, one of the most critical security requirements is proper user input validation and handling. This comes in many forms and we will not cover all of them here. -Ultimately, the responsibility for validating and correctly handling the types of user input your application accepts is yours. +웹 애플리케이션에서 가장 중요한 보안 요구 사항 중 하나는 적절한 사용자 입력 검증 및 처리를 수행하는 것입니다. 이는 여러 형태로 나타나며, 이 문서에서는 모든 경우를 다루지 않습니다. +궁극적으로 애플리케이션이 수용하는 사용자 입력 유형을 검증하고 올바르게 처리하는 책임은 개발자에게 있습니다. -### Prevent open redirects +### 오픈 리다이렉트 방지 -An example of potentially dangerous user input is an _open redirect_, where an application accepts a URL as user input (often in the URL query, for example `?url=https://example.com`) and uses `res.redirect` to set the `location` header and -return a 3xx status. +잠재적으로 위험한 사용자 입력의 예로 오픈 리다이렉트가 있습니다. 이는 애플리케이션이 URL을 사용자 입력으로 받아들여 (예: `?url=https://example.com` 쿼리 문자열)\ +`res.redirect`를 사용해 `location` 헤더를 설정하고 3xx 상태 코드를 반환하는 경우입니다. -An application must validate that it supports redirecting to the incoming URL to avoid sending users to malicious links such as phishing websites, among other risks. +애플리케이션은 악성 링크(예: 피싱 사이트) 로 사용자를 유도하는 위험을 방지하기 위해, 들어오는 URL에 대해 리다이렉트를 허용하는지 반드시 검증해야 합니다. -Here is an example of checking URLs before using `res.redirect` or `res.location`: +아래는 `res.redirect` 또는 `res.location`을 사용하기 전에 URL을 검증하는 예시입니다. ```js app.use((req, res) => { @@ -86,23 +85,23 @@ app.use((req, res) => { [Helmet](https://www.npmjs.com/package/helmet)을 이용하면 HTTP 헤더를 적절히 설정하여 몇 가지 잘 알려진 웹 취약성으로부터 앱을 보호할 수 있습니다. -Helmet is a middleware function that sets security-related HTTP response headers. Helmet sets the following headers by default: +Helmet은 보안 관련 HTTP 응답 헤더를 설정하는 미들웨어 함수입니다. Helmet은 기본적으로 다음 헤더들을 설정합니다. -- `Content-Security-Policy`: A powerful allow-list of what can happen on your page which mitigates many attacks -- `Cross-Origin-Opener-Policy`: Helps process-isolate your page -- `Cross-Origin-Resource-Policy`: Blocks others from loading your resources cross-origin -- `Origin-Agent-Cluster`: Changes process isolation to be origin-based -- `Referrer-Policy`: Controls the [`Referer`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer) header -- `Strict-Transport-Security`: Tells browsers to prefer HTTPS -- `X-Content-Type-Options`: Avoids [MIME sniffing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing) -- `X-DNS-Prefetch-Control`: Controls DNS prefetching -- `X-Download-Options`: Forces downloads to be saved (Internet Explorer only) -- `X-Frame-Options`: Legacy header that mitigates [Clickjacking](https://en.wikipedia.org/wiki/Clickjacking) attacks -- `X-Permitted-Cross-Domain-Policies`: Controls cross-domain behavior for Adobe products, like Acrobat -- `X-Powered-By`: Info about the web server. Removed because it could be used in simple attacks -- `X-XSS-Protection`: Legacy header that tries to mitigate [XSS attacks](https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting), but makes things worse, so Helmet disables it +- `Content-Security-Policy`: 페이지에서 허용되는 콘텐츠를 강력하게 지정하여 여러 공격을 완화합니다. +- `Cross-Origin-Opener-Policy`: 페이지의 프로세스 격리를 돕습니다. +- `Cross-Origin-Resource-Policy`: 다른 출처가 리소스를 크로스 오리진으로 로드하는 것을 차단합니다. +- `Origin-Agent-Cluster`: 프로세스 격리를 출처(origin) 단위로 변경합니다. +- `Referrer-Policy`: [`Referer`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer) 헤더를 제어합니다. +- `Strict-Transport-Security`: 브라우저에 HTTPS를 우선 사용하도록 지시합니다. +- `X-Content-Type-Options`: [MIME 스니핑](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing)을 방지합니다. +- `X-DNS-Prefetch-Control`: DNS 프리페칭 제어를 담당합니다. +- `X-Download-Options`: 다운로드를 저장하도록 강제합니다 (인터넷 익스플로러 전용) +- `X-Frame-Options`: [클릭재킹](https://en.wikipedia.org/wiki/Clickjacking) 공격을 완화하기 위한 레거시 헤더입니다. +- `X-Permitted-Cross-Domain-Policies`: Acrobat과 같은 Adobe 제품의 크로스 도메인 동작을 제어합니다. +- `X-Powered-By`: 웹 서버 정보에 관한 헤더입니다. 해당 헤더는 단순 공격에 악용될 수 있어 제거되었습니다 +- `X-XSS-Protection`: [XSS 공격](https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting)을 완화하려 했던 레거시 헤더이나, 오히려 문제를 악화시키기 때문에 Helmet에서는 비활성화합니다 -Each header can be configured or disabled. To read more about it please go to [its documentation website][helmet]. +각 헤더는 필요에 따라 설정하거나 비활성화할 수 있습니다. 자세한 내용은 [Helmet 공식 문서를][helmet] 참고하시기 바랍니다. 다른 모든 모듈처럼 Helmet은 다음과 같이 설치할 수 있습니다. @@ -110,7 +109,7 @@ Each header can be configured or disabled. To read more about it please go to [i $ npm install helmet ``` -Then to use it in your code: +코드에서 Helmet을 사용하는 방법은 문서를 참고하세요 ```js // ... @@ -121,13 +120,10 @@ app.use(helmet()) // ... ``` -## Reduce fingerprinting +## 지문 인식(Fingerprinting) 감소 -It can help to provide an extra layer of security to reduce the ability of attackers to determine -the software that a server uses, known as "fingerprinting." Though not a security issue itself, -reducing the ability to fingerprint an application improves its overall security posture. -Server software can be fingerprinted by quirks in how it responds to specific requests, for example in -the HTTP response headers. +서버가 사용하는 소프트웨어를 공격자가 식별하는 능력을 줄이는 것은 추가적인 보안 계층을 제공할 수 있습니다. 이를 ‘지문 인식(fingerprinting)’이라 합니다. 비록 지문 인식 자체가 직접적인 보안 문제는 아니지만, 이를 줄임으로써 전체적인 보안 수준이 향상됩니다. +서버 소프트웨어는 특정 요청에 대한 응답 방식, 예를 들어 HTTP 응답 헤더 등에서 특이점을 통해 식별될 수 있습니다. 따라서 우수 사례는 다음과 같이 `app.disable()` 메소드를 이용해 이 헤더를 끄는 것입니다. @@ -137,20 +133,15 @@ app.disable('x-powered-by') {% capture powered-advisory %} -Disabling the `X-Powered-By header` does not prevent -a sophisticated attacker from determining that an app is running Express. It may -discourage a casual exploit, but there are other ways to determine an app is running -Express. +`X-Powered-By` 헤더를 비활성화하는 것만으로는 숙련된 공격자가 Express를 사용하는 앱임을 완전히 차단할 수 없습니다. 이는 단순한 공격 시도를 막는 데는 도움이 되지만, 앱이 Express로 작동함을 식별할 수 있는 다른 방법도 존재합니다. {% endcapture %} {% include admonitions/note.html content=powered-advisory %} -Express also sends its own formatted "404 Not Found" messages and formatter error -response messages. These can be changed by -[adding your own not found handler](/en/starter/faq.html#how-do-i-handle-404-responses) -and -[writing your own error handler](/en/guide/error-handling.html#writing-error-handlers): +Express는 자체 포맷의 "404 Not Found" 메시지와 포맷터 오류 응답 메시지도 전송합니다. 이러한 응답은\ +[사용자 정의 404 핸들러 추가](/en/starter/faq.html#how-do-i-handle-404-responses) 및\ +[사용자 정의 에러 핸들러 작성](/en/guide/error-handling.html#writing-error-handlers)을 통해 변경할 수 있습니다. ```js // last app.use calls right before app.listen(): @@ -226,16 +217,16 @@ app.use(session({ })) ``` -## Prevent brute-force attacks against authorization +## 인증에 대한 무차별 대입 공격(Brute-force) 방지 -Make sure login endpoints are protected to make private data more secure. +로그인 엔드포인트를 보호하여 개인정보를 안전하게 유지해야 합니다. -A simple and powerful technique is to block authorization attempts using two metrics: +간단하면서도 효과적인 방법 중 하나는 다음 두 가지 기준으로 인증 시도를 차단하는 것입니다: -1. The number of consecutive failed attempts by the same user name and IP address. -2. The number of failed attempts from an IP address over some long period of time. For example, block an IP address if it makes 100 failed attempts in one day. +1. . +2. IP 주소로부터의 오랜 시간 동안의 실패 시도 횟수입니다. 예를 들어, 하루 동안 100번의 실패 시도를 한 경우 해당 IP 주소를 차단할 수 있습니다. -[rate-limiter-flexible](https://github.com/animir/node-rate-limiter-flexible) package provides tools to make this technique easy and fast. You can find [an example of brute-force protection in the documentation](https://github.com/animir/node-rate-limiter-flexible/wiki/Overall-example#login-endpoint-protection) +[rate-limiter-flexible](https://github.com/animir/node-rate-limiter-flexible) 패키지는 이 기술을 쉽고 빠르게 구현할 수 있는 도구들을 제공합니다. [문서에서 brute-force 방지 예제](https://github.com/animir/node-rate-limiter-flexible/wiki/Overall-example#login-endpoint-protection)를 참고할 수 있습니다. ## 종속 항목이 안전한지 확인 @@ -249,7 +240,7 @@ $ npm audit 더 강한 보안을 원한다면, [Snyk](https://snyk.io/)를 사용하십시오. -Snyk offers both a [command-line tool](https://www.npmjs.com/package/snyk) and a [Github 통합](https://snyk.io/docs/github) that checks your application against [Snyk's open source vulnerability database](https://snyk.io/vuln/) for any known vulnerabilities in your dependencies. Install the CLI as follows: +Snyk offers both a [command-line tool](https://www.npmjs.com/package/snyk) and a [Github 통합](https://snyk.io/docs/github) that checks your application against [Snyk's open source vulnerability database](https://snyk.io/vuln/) for any known vulnerabilities in your dependencies. 다음과 같이 CLI을 설치합니다: ```bash $ npm install -g snyk diff --git a/ko/advanced/developing-template-engines.md b/ko/advanced/developing-template-engines.md index 8155ff7a31..6926558ac1 100644 --- a/ko/advanced/developing-template-engines.md +++ b/ko/advanced/developing-template-engines.md @@ -1,7 +1,7 @@ --- layout: page title: Express용 템플릿 엔진 개발 -description: Learn how to develop custom template engines for Express.js using app.engine(), with examples on creating and integrating your own template rendering logic. +description: App.engine()을 사용하여 Express.js에서 사용자 정의 템플릿 엔진을 개발하는 방법을 학습합니다. 직접 템플릿 렌더링 로직을 생성하고 통합하는 예제를 함께 제공합니다. menu: advanced redirect_from: " " --- diff --git a/ko/advanced/healthcheck-graceful-shutdown.md b/ko/advanced/healthcheck-graceful-shutdown.md index 4ce6f3c04a..b57db7d289 100644 --- a/ko/advanced/healthcheck-graceful-shutdown.md +++ b/ko/advanced/healthcheck-graceful-shutdown.md @@ -1,7 +1,7 @@ --- layout: page title: 상태 검사와 우아한 종료 -description: Learn how to implement health checks and graceful shutdown in Express apps to enhance reliability, manage deployments, and integrate with load balancers like Kubernetes. +description: Express 애플리케이션에서 헬스 체크와 그레이스풀 셧다운(Graceful Shutdown)을 구현하는 방법을 학습합니다. 이 기능은 애플리케이션의 신뢰성을 향상시키고, 배포를 원활하게 관리하며, Kubernetes와 같은 로드 밸런서와의 통합을 지원합니다. menu: advanced redirect_from: " " --- @@ -27,7 +27,7 @@ process.on('SIGTERM', () => { ## Health checks -A load balancer uses health checks to determine if an application instance is healthy and can accept requests. For example, [Kubernetes has two health checks](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/): +로드 밸런서는 헬스 체크를 통해 애플리케이션 인스턴스가 정상적으로 작동 중이며 요청을 수락할 수 있는지 판단합니다. For example, [Kubernetes has two health checks](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/): 로드 밸런서는 상태 확인을 애플리케이션이 장상 작동하고 요청을 받을 수 있는지 판단하는데 사용합니다. - `liveness`: 언제 컨테이너를 재시작할지 결정합니다. diff --git a/ko/advanced/security-updates.md b/ko/advanced/security-updates.md index 82f7cbb834..27d5094aa5 100644 --- a/ko/advanced/security-updates.md +++ b/ko/advanced/security-updates.md @@ -1,7 +1,9 @@ --- layout: page title: Express 보안 업데이트 -description: Review the latest security updates and patches for Express.js, including detailed vulnerability lists for different versions to help maintain a secure application. +description: |- + Express.js의 최신 보안 업데이트와 패치 사항을 확인합니다. + 각 버전에 대한 상세한 취약점 목록을 포함하여, 애플리케이션의 보안을 유지하는 데 도움이 됩니다. menu: advanced redirect_from: " " --- @@ -15,9 +17,7 @@ Node.js 취약성은 Express에 직접 영향을 미칩니다. 따라서 [Node.j 아래의 목록에는 지정된 버전 업데이트에서 수정된 Express 취약성이 열거되어 있습니다. -{% capture security-policy %} -If you believe you have discovered a security vulnerability in Express, please see -[Security Policies and Procedures](/{{page.lang}}/resources/contributing.html#security-policies-and-procedures). +{% capture security-policy %} Express에서 보안 취약점을 발견했다고 생각되면, [보안 정책 및 절차](/{{page.lang}}/resources/contributing.html#security-policies-and-procedures)를 참고해 주시기 바랍니다. {% endcapture %} {% include admonitions/note.html content=security-policy %} @@ -25,19 +25,19 @@ If you believe you have discovered a security vulnerability in Express, please s ## 4.x - 4.21.2 - - The dependency `path-to-regexp` has been updated to address a [vulnerability](https://github.com/pillarjs/path-to-regexp/security/advisories/GHSA-rhx6-c78j-4q9w). + - `path-to-regexp` 모듈이 [보안 취약점](https://github.com/pillarjs/path-to-regexp/security/advisories/GHSA-rhx6-c78j-4q9w)을 해결하기 위해 업데이트되었습니다. - 4.21.1 - - The dependency `cookie` has been updated to address a [vulnerability](https://github.com/jshttp/cookie/security/advisories/GHSA-pxg6-pf52-xh8x), This may affect your application if you use `res.cookie`. + - `cookie` 모듈이 [보안 취약점](https://github.com/jshttp/cookie/security/advisories/GHSA-pxg6-pf52-xh8x)을 해결하기 위해 업데이트되었습니다. 이 취약점은 `res.cookie`를 사용하는 애플리케이션에 영향을 줄 수 있습니다. - 4.20.0 - - Fixed XSS vulnerability in `res.redirect` ([advisory](https://github.com/expressjs/express/security/advisories/GHSA-qw6h-vgh9-j6wx), [CVE-2024-43796](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-43796)). - - The dependency `serve-static` has been updated to address a [vulnerability](https://github.com/advisories/GHSA-cm22-4g7w-348p). - - The dependency `send` has been updated to address a [vulnerability](https://github.com/advisories/GHSA-m6fv-jmcg-4jfg). - - The dependency `path-to-regexp` has been updated to address a [vulnerability](https://github.com/pillarjs/path-to-regexp/security/advisories/GHSA-9wv6-86v2-598j). - - The dependency `body-parser` has been updated to addres a [vulnerability](https://github.com/advisories/GHSA-qwcr-r2fm-qrc7), This may affect your application if you had url enconding activated. + - `res.redirect`에서 발생할 수 있는 XSS 취약점이 수정되었습니다 ([권고문](https://github.com/expressjs/express/security/advisories/GHSA-qw6h-vgh9-j6wx), [CVE-2024-43796](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-43796)). + - `serve-static` 모듈이 [보안 취약점](https://github.com/advisories/GHSA-cm22-4g7w-348p)을 해결하기 위해 업데이트되었습니다. + - `send` 모듈이 [보안 취약점](https://github.com/advisories/GHSA-m6fv-jmcg-4jfg)을 해결하기 위해 업데이트되었습니다. + - `path-to-regexp` 모듈이 [보안 취약점](https://github.com/pillarjs/path-to-regexp/security/advisories/GHSA-9wv6-86v2-598j)을 해결하기 위해 추가로 업데이트되었습니다. + - `body-parser` 모듈이 [보안 취약점](https://github.com/advisories/GHSA-qwcr-r2fm-qrc7)을 해결하기 위해 업데이트되었습니다 이 취약점은 URL 인코딩이 활성화된 경우 애플리케이션에 영향을 줄 수 있습니다. - 4.19.0, 4.19.1 - - Fixed open redirect vulnerability in `res.location` and `res.redirect` ([advisory](https://github.com/expressjs/express/security/advisories/GHSA-rv95-896h-c2vc), [CVE-2024-29041](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-29041)). + - `res.location` 및 `res.redirect`에서 발생할 수 있는 오픈 리디렉션(Open Redirect) 취약점이 수정되었습니다 ([권고문](https://github.com/expressjs/express/security/advisories/GHSA-rv95-896h-c2vc) [CVE-2024-29041](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-29041)) - 4.17.3 - - The dependency `qs` has been updated to address a [vulnerability](https://github.com/advisories/GHSA-hrpp-h998-j3pp). This may affect your application if the following APIs are used: `req.query`, `req.body`, `req.param`. + - `qs` 모듈이 [보안 취약점](https://github.com/advisories/GHSA-hrpp-h998-j3pp)을 해결하기 위해 업데이트되었습니다. 이 취약점은 `req.query`, `req.body`, `req.param` API 사용 시 애플리케이션에 영향을 줄 수 있습니다. - 4.16.0 - 의존성 `forwarded`가 [발견된 취약점](https://npmjs.com/advisories/527)에 따라 업데이트되었습니다. `req.host`, `req.hostname`, `req.ip`, `req.ips`, `req.protocol`을 사용하는 애플리케이션에 영향을 끼칠 수 있습니다. - 의존성 `mime`이 [발견된 취약점](https://npmjs.com/advisories/535)에 따라 업데이트되었으나, Express에 영향을 끼치지는 않습니다. @@ -68,7 +68,7 @@ If you believe you have discovered a security vulnerability in Express, please s 3.x의 알려진 또는 알려지지 않은 보안 및 성능 문제는 마지막 업데이트(2015년 8월 1일) 이후로 처리되지 않고 있습니다. 최신 버전의 Express를 사용할 것을 강력히 권장합니다. -If you are unable to upgrade past 3.x, please consider [Commercial Support Options](/{{ page.lang }}/support#commercial-support-options). +버전 3.x 이상으로 업그레이드할 수 없는 경우, [상업적 지원 옵션](/{{ page.lang }}/support#commercial-support-options)을 고려해주시기 바랍니다. diff --git a/ko/changelog/index.md b/ko/changelog/index.md index c24baa60bf..5718e8cc7d 100644 --- a/ko/changelog/index.md +++ b/ko/changelog/index.md @@ -1,7 +1,7 @@ --- layout: page title: Express changelog -description: Stay updated with the release changelog for Express.js, detailing new features, bug fixes, and important changes across versions. +description: Express.js의 릴리스 변경 로그를 통해 새로운 기능, 버그 수정 사항, 그리고 각 버전별 주요 변경 사항을 최신 상태로 확인하세요. sitemap: false redirect_from: - " " @@ -10,12 +10,8 @@ redirect_from: @@ -30,18 +26,18 @@ All the latest updates, improvements, and fixes to Express {: id="5.x"} -### 5.1.0 - Release date: 2025-03-31 +### 5.1.0 - 릴리즈 날짜: 2025-03-31 {: id="5.0.1"} -The 5.1.0 minor release includes some new features and improvements: +5.1.0 마이너 릴리즈에는 다음과 같은 새로운 기능과 개선 사항이 포함되어 있습니다: -- Support for sending responses as Uint8Array -- Added support for ETag option in `res.sendFile()` -- Added support for adding multiple links with the same rel with `res.links()` -- Performance: Use loop for acceptParams +- 응답을 `Uint8Array` 형식으로 전송하는 기능 지원 +- `res.sendFile()`에서 ETag 옵션 지원 추가 +- `res.links()`에서 동일한 `rel` 값을 갖는 여러 링크 추가 지원 +- 성능 향상: `acceptParams`에 루프 사용 - [body-parser@2.2.0](https://github.com/expressjs/body-parser/releases/tag/v2.2.0) - - Remove legacy node.js support checks for Brotli & `AsyncLocalStorage` + - Brotli 및 `AsyncLocalStorage`에 대한 레거시 Node.js 지원 검사 제거 - Remove `unpipe` & `destroy` - [router@2.2.0](https://github.com/pillarjs/router/releases/tag/v2.2.0) - Restore `debug`. Now with the `router` scope instead of `express`. @@ -55,7 +51,7 @@ The 5.1.0 minor release includes some new features and improvements: - Add package.json funding field to highlight our OpenCollective - See [Changelog v5.1.0](https://github.com/expressjs/express/releases/tag/v5.1.0) -### 5.0.1 - Release date: 2024-10-08 +### 5.0.1 - 릴리즈 날짜: 2024-10-08 {: id="5.0.1"} @@ -63,7 +59,7 @@ The 5.0.1 patch release includes one security fix: - Update [jshttps/cookie](https://www.npmjs.com/package/cookie) to address a [vulnerability](https://github.com/advisories/GHSA-pxg6-pf52-xh8x). -### 5.0.0 - Release date: 2024-09-09 +### 5.0.0 - 릴리즈 날짜: 2024-09-09 {: id="5.0.0"} @@ -73,7 +69,7 @@ Check the [migration guide](/{{page.lang}}/guide/migrating-5.html) with all the {: id="4.x"} -### 4.21.2 - Release date: 2024-11-06 +### 4.21.2 - 릴리즈 날짜: 2024-11-06 {: id="4.21.2"} @@ -81,7 +77,7 @@ The 4.21.2 patch release includes one security fix: - Update [pillajs/path-to-regexp](https://www.npmjs.com/package/path-to-regexp) to address a [vulnerability](https://github.com/advisories/GHSA-rhx6-c78j-4q9w). -### 4.21.1 - Release date: 2024-10-08 +### 4.21.1 - 릴리즈 날짜: 2024-10-08 {: id="4.21.1"} @@ -89,7 +85,7 @@ The 4.21.1 patch release includes one security fix: - Update [jshttps/cookie](https://www.npmjs.com/package/cookie) to address a [vulnerability](https://github.com/advisories/GHSA-pxg6-pf52-xh8x). -### 4.21.0 - Release date: 2024-09-11 +### 4.21.0 - 릴리즈 날짜: 2024-09-11 {: id="4.21.0"} diff --git a/ko/guide/behind-proxies.md b/ko/guide/behind-proxies.md index fa28ab95bb..baa77d017b 100644 --- a/ko/guide/behind-proxies.md +++ b/ko/guide/behind-proxies.md @@ -1,17 +1,17 @@ --- layout: page title: 프록시 환경에서 Express 사용 -description: Learn how to configure Express.js applications to work correctly behind reverse proxies, including using the trust proxy setting to handle client IP addresses. +description: Express.js 애플리케이션을 리버스 프록시 뒤에서 올바르게 작동하도록 설정하는 방법을 알아보십시오. 클라이언트 IP 주소를 처리하기 위해 `trust proxy` 설정을 사용하는 것을 포함합니다. menu: guide redirect_from: " " --- # 프록시 환경에서 Express 사용 -When running an Express app behind a reverse proxy, some of the Express APIs may return different values than expected. In order to adjust for this, the `trust proxy` application setting may be used to expose information provided by the reverse proxy in the Express APIs. The most common issue is express APIs that expose the client's IP address may instead show an internal IP address of the reverse proxy. +Express 앱이 리버스 프록시 뒤에서 실행될 때, 일부 Express API는 예상과 다른 값을 반환할 수 있습니다. 이를 조정하기 위해 `trust proxy` 애플리케이션 설정을 사용하여, Express API에서 리버스 프록시가 제공한 정보를 노출하도록 할 수 있습니다. 가장 흔한 문제는 클라이언트의 IP 주소를 반환하는 Express API가 리버스 프록시의 내부 IP 주소를 대신 보여주는 경우입니다.
-When configuring the `trust proxy` setting, it is important to understand the exact setup of the reverse proxy. Since this setting will trust values provided in the request, it is important that the combination of the setting in Express matches how the reverse proxy operates. +`trust proxy` 설정을 구성할 때, 리버스 프록시의 정확한 구성 방식을 이해하는 것이 중요합니다. 이 설정은 요청에 포함된 값을 신뢰하게 만들기 때문에, Express의 설정이 리버스 프록시의 동작 방식과 일치해야 합니다.
프록시 뒤에서 Express 앱을 실행할 때는, ([app.set()](/{{ page.lang }}/4x/api.html#app.set)을 이용하여) 애플리케이션 변수 `trust proxy`를 다음 표에 나열된 값 중 하나로 설정하십시오. @@ -26,9 +26,7 @@ When configuring the `trust proxy` setting, it is important to understand the ex `false`인 경우, 앱이 직접 인터넷에 연결되는 것으로 인식되며 클라이언트의 IP 주소는 `req.connection.remoteAddress`로부터 도출됩니다. 이 설정이 기본 설정입니다. -
-When setting to `true`, it is important to ensure that the last reverse proxy trusted is removing/overwriting all of the following HTTP headers: `X-Forwarded-For`, `X-Forwarded-Host`, and `X-Forwarded-Proto`, otherwise it may be possible for the client to provide any value. -
+
`trust proxy`를 `true`로 설정할 경우, 마지막으로 신뢰할 수 있는 리버스 프록시가 다음의 HTTP 헤더들을 제거하거나 덮어쓰는지 반드시 확인해야 합니다: `X-Forwarded-For`, `X-Forwarded-Host`, `X-Forwarded-Proto`. 그렇지 않으면 클라이언트가 임의의 값을 제공하는 것이 가능해질 수 있습니다.
@@ -49,18 +47,17 @@ app.set('trust proxy', 'loopback, linklocal, uniquelocal') // specify multiple s app.set('trust proxy', ['loopback', 'linklocal', 'uniquelocal']) // specify multiple subnets as an array ``` -IP 주소 또는 서브넷이 지정되는 경우, 해당 IP 주소 또는 서브넷은 주소 결정 프로세스에서 제외되며, 신뢰할 수 있는 것으로 지정되지 않은 IP 주소 중 애플리케이션 서버에서 가장 가까운 IP 주소가 클라이언트의 IP 주소로 결정됩니다. This works by checking if `req.socket.remoteAddress` is trusted. If so, then each address in `X-Forwarded-For` is checked from right to left until the first non-trusted address. +IP 주소 또는 서브넷이 지정되는 경우, 해당 IP 주소 또는 서브넷은 주소 결정 프로세스에서 제외되며, 신뢰할 수 있는 것으로 지정되지 않은 IP 주소 중 애플리케이션 서버에서 가장 가까운 IP 주소가 클라이언트의 IP 주소로 결정됩니다. 이 설정은 `req.socket.remoteAddress`가 신뢰된 주소인지 확인하는 방식으로 작동합니다. 신뢰된 경우, `X-Forwarded-For` 헤더에 있는 각 IP 주소를 오른쪽에서 왼쪽으로 검사하며, 처음으로 신뢰되지 않은 주소를 만날 때까지 확인합니다. 숫자 -Use the address that is at most `n` number of hops away from the Express application. `req.socket.remoteAddress` is the first hop, and the rest are looked for in the `X-Forwarded-For` header from right to left. A value of `0` means that the first untrusted address would be `req.socket.remoteAddress`, i.e. there is no reverse proxy. +Express 애플리케이션으로부터 최대 `n` 홉(hop) 떨어진 위치에 있는 주소를 사용하게 됩니다. + `req.socket.remoteAddress`는 첫 번째 홉이며, 그 외의 주소들은 `X-Forwarded-For` 헤더에서 오른쪽에서 왼쪽 방향으로 조회됩니다. `0` 값을 설정하면, 첫 번째로 신뢰되지 않은 주소는 `req.socket.remoteAddress`가 되며, 이는 리버스 프록시가 없는 상태를 의미합니다. -
-When using this setting, it is important to ensure there are not multiple, different-length paths to the Express application such that the client can be less than the configured number of hops away, otherwise it may be possible for the client to provide any value. -
+
이 설정을 사용할 때는 Express 애플리케이션까지 도달하는 경로가 하나 이상 존재하지 않도록, 즉 서로 다른 홉 수의 경로가 존재하지 않도록 주의해야 합니다. 그렇지 않으면 클라이언트가 설정된 홉 수보다 가까운 위치에서 접근할 수 있게 되어, 임의의 값을 제공하는 것이 가능해질 수 있습니다.
@@ -80,7 +77,7 @@ app.set('trust proxy', (ip) => { -Enabling `trust proxy` will have the following impact: +`trust proxy`를 활성화하면 다음과 같은 영향을 미칩니다: