C# Switch 식(Expression)

C# 8.0(2019년 9월)부터 도입된 Switch 식(Switch Expression)은 기존의 switch-case 문을 획기적으로 줄여주는 강력한 기능

람다 표현식(=>)을 쓰는 것처럼 간결하고 직관적인 분기 처리가 가능

기존 방식 (Statement)

public string GetGrade(int score)
{
    string grade;
    switch (score)
    {
        case 90:
            grade = "A";
            break;
        case 80:
            grade = "B";
            break;
        default:
            grade = "C";
            break;
    }
    return grade;
}

새로운 방식 (Expression)

public string GetGrade(int score) => score switch
{
    90 => "A",
    80 => "B",
    _  => "C"
};


또는 다른 범위 방식으로 (결과는 다름) 
score switch
{
    >= 90 => "A",
    >= 80 => "B",
    >= 70 => "C",
    _     => "D"
};

• 위치 이동: switch 키워드가 변수 뒤로 이동 (score switch)
• 화살표 사용: case ... : 대신 람다 화살표 =>를 사용
• Default 처리: default: 대신 와일드카드 _를 사용
• 식(Expression): 그 자체가 ‘값’을 반환하므로 메서드의 리턴값으로 바로 사용할 수 있음

강력한 활용 패턴

C# 9.0(2020년 11월)부터 Switch 식이 단순 매핑이 아니라 패턴 매칭(Pattern Matching)과 결합됨

• Switch Expression 자체는 C# 8에서 처음 도입
• Pattern Matching 자체는 C# 7부터 지원
• Relational Pattern, Logical Pattern 등이 C# 9에서 추가

범위 비교 (Relational Pattern)

C# 9.0부터는 when 키워드 없이도 관계 연산자를 직접 사용

int temperature = 28;

string weather = temperature switch
{
    >= 30 => "폭염",
    >= 20 => "쾌적함",
    >= 10 => "쌀쌀함",
    _     => "추움"
};

여러 변수 동시에 비교 (Tuple Pattern)

두 개 이상의 상태를 조합해서 분기해야 할 때, if-else 중첩 없이 튜플 패턴으로 깔끔하게 해결

string state = "Running";
bool hasError = true;

// (상태, 에러여부)를 한 번에 검사
string message = (state, hasError) switch
{
    ("Running", false) => "정상 작동 중",
    ("Running", true)  => "작동 중이나 오류 발생",
    ("Stopped", _)     => "시스템 중지됨", // _는 true/false 상관없음
    _                  => "알 수 없는 상태"
};

객체 속성 비교 (Property Pattern)

객체 내부의 특정 프로퍼티 값에 따라 분기할 수도 있음

var user = new User { Role = "Admin", IsDeleted = false };

string accessLevel = user switch
{
    { Role: "Admin", IsDeleted: false } => "관리자 권한",
    { Role: "User", IsDeleted: false }  => "일반 사용자",
    { IsDeleted: true }                 => "삭제된 계정",
    _                                   => "접근 불가" // null 포함
};

// 객체가 null인 경우도 자동으로 _

리턴값이 없는 메서드(Action) 실행

Action 델리게이트를 반환받아 즉시 실행

switch expression은 “값”을 반환하므로 델리게이트(함수 포인터)를 반환하는 것도 가능

int command = 1;

// 1. 각 조건에 맞는 Action(행동)을 선택하고
// 2. 마지막의 ()로 즉시 실행합니다.
(command switch
{
    1 => (Action)(() => SaveData()),
    2 => () => LoadData(),
    _ => () => Console.WriteLine("대기")
})(); 
// 마지막 ()는 "반환된 델리게이트 실행"

The post C# Switch 식(Expression) appeared first on 어제와 내일의 나 그 사이의 이야기.

1⃣ 사용자가 “Google로 로그인” 버튼을 클릭

Navigation.NavigateTo(..., forceLoad: true)

Blazor의 내부 라우팅이 아닌, 브라우저가 직접 해당 URL(api/auth/Challenge/Google...)로 GET 요청보낸다.

private void LoginWithGoogle()
{
    var returnUrl = "/"; // 로그인 성공 후 돌아올 주소
    var googleLoginUrl = $"/api/auth/Challenge/Google?returnUrl={Uri.EscapeDataString(returnUrl)}";

    // 이 주소로 브라우저가 페이지를 새로고침하며 이동
    Navigation.NavigateTo(googleLoginUrl, forceLoad: true);
}

2⃣ 백엔드의 인증 시작 (AuthController – Challenge)

// AuthController.cs
[HttpGet("Challenge/{provider}")]
public IActionResult Challenge(string provider, string? returnUrl = null)
{
    // ...
    var redirectUrl = Url.Action("Callback", "Auth", ...); // 1. Google이 인증 후 돌아올 우리 API 주소(Callback)를 지정
    var properties = _signInManager.ConfigureExternalAuthenticationProperties(provider, redirectUrl); // 2. 인증 요청에 필요한 속성 구성

    return Challenge(properties, provider); // 3. Google 로그인 페이지로 리디렉션하는 응답 생성
}

• AuthController.cs의 Challenge 메서드가 실행됩니다.
  provider 매개변수에는 “Google”이 전달
• _signInManager는 ASP.NET Core Identity의 핵심 기능으로, 외부 로그인 과정을 도와줌
• return Challenge(properties, provider);는 브라우저에게 HTTP 302 Redirect 응답을 보냄
  이 응답 헤더에는 사용자가 이동해야 할 Google의 로그인 페이지 주소가 포함

3⃣ 외부 공급자 인증 (Google)

사용자는 Google 로그인 페이지로 이동

• 사용자는 자신의 Google 계정으로 로그인하고, 우리 애플리케이션이 요청하는 정보(이메일, 프로필 등)에 대한 접근 권한을 허용
• 인증이 성공적으로 완료되면, Google은 2단계에서 백엔드가 지정했던 콜백 URL(api/Auth/Callback)로 사용자를 다시 리디렉션
  이때 인증 코드 또는 토큰과 함께 사용자를 보냄

4⃣ 백엔드의 콜백 처리 및 로그인/회원가입 (AuthController – Callback)

Google이 사용자를 우리 백엔드의 Callback 엔드포인트로 돌려보냄

AuthController.cs의 Callback (라우팅 경로: externalLogin) 메서드가 실행

// AuthController.cs
[HttpGet("externalLogin")]
public async Task<IActionResult> Callback(...)
{
    // 1. Google이 보내준 정보로 외부 로그인 정보를 가져옴
    var info = await _signInManager.GetExternalLoginInfoAsync();
    if (info == null) { /* 에러 처리 */ }

    // 2. 이 외부 정보(공급자, 키)로 우리 DB에 연결된 사용자가 있는지 확인하고 로그인 시도
    var result = await _signInManager.ExternalLoginSignInAsync(info.LoginProvider, info.ProviderKey, ...);

    if (result.Succeeded)
    {
        // 3a. 성공! 이미 가입하고 연동된 사용자. 로그인 처리 후 returnUrl로 리디렉션
        return LocalRedirect(returnUrl);
    }
    else
    {
        // 3b. 실패. 신규 사용자이거나, 이메일은 같지만 연동되지 않은 사용자.
        return await HandleUserCreationOrLinking(info, returnUrl);
    }
}

HandleUserCreationOrLinking 메서드는 다음 두 가지 시나리오를 처리

• 시나리오 A: 이메일은 존재하지만 소셜 연동이 안 된 경우 (LinkExistingUser)
  • Google에서 받은 이메일로 우리 DB에서 사용자를 찾습니다. (_userManager.FindByEmailAsync)
  • 기존 사용자가 있다면, 해당 계정에 이 Google 로그인 정보를 추가로 연결합니다. (_userManager.AddLoginAsync)
  • 연결 후, 사용자를 로그인시키고 returnUrl로 리디렉션합니다.
• 시나리오 B: 완전히 새로운 사용자인 경우 (CreateNewUserAsync)
  • Google에서 받은 이메일과 이름으로 새로운 ApplicationUser 객체를 만듭니다. 이때 EmailConfirmed는 true로 설정합니다. (소셜 로그인은 이미 이메일이 인증된 것으로 간주)
  • _userManager.CreateAsync(user)로 DB에 새 사용자를 저장합니다.
  • 새로 생성된 사용자 계정에 Google 로그인 정보를 연결합니다. (_userManager.AddLoginAsync)
  • 새 사용자를 로그인시키고 returnUrl로 리디렉션합니다.

5⃣ 완료

로그인 또는 회원가입 및 연동이 모두 성공적으로 끝나면, 백엔드는 최종적으로 LocalRedirect(returnUrl)을 통해 사용자를 맨 처음 Login.razor에서 지정했던 주소(/)로 리디렉션합니다.

이제 사용자는 로그인된 상태로 메인 페이지를 보게 됩니다.

6⃣ AuthController.cs

using Microsoft.AspNetCore.Identity;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.WebUtilities;
using Microsoft.IdentityModel.Tokens;
using Neco.BaseTemplate.Shared.Data;
using Neco.BaseTemplete.Data;
using System.IdentityModel.Tokens.Jwt;
using System.Security.Claims;
using System.Text;
using System.Text.Encodings.Web;

namespace Neco.BaseTemplete.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class AuthController : ControllerBase
    {
        private readonly UserManager<ApplicationUser> _userManager;
        private readonly SignInManager<ApplicationUser> _signInManager;
        private readonly IUserStore<ApplicationUser> _userStore;
        private readonly IEmailSender<ApplicationUser> _emailSender;
        private readonly ILogger<AuthController> _logger;

        public AuthController(
            UserManager<ApplicationUser> userManager,
            SignInManager<ApplicationUser> signInManager,
            IUserStore<ApplicationUser> userStore,
            IEmailSender<ApplicationUser> emailSender,
            ILogger<AuthController> logger)
        {
            _userManager = userManager;
            _signInManager = signInManager;
            _userStore = userStore;
            _emailSender = emailSender;
            _logger = logger;
        }

        #region Basic Authentication

        /// <summary>
        /// Handles user login.
        /// </summary>
        /// <param name="model">Login request DTO (email, password, RememberMe option)</param>
        /// <returns>The login result</returns>
        [HttpPost("login")]
        public async Task<IActionResult> Login([FromBody] LoginUserRequestDTO model)
        {
            try
            {
                var result = await _signInManager.PasswordSignInAsync(
                    model.Email,
                    model.Password,
                    model.RememberMe,
                    lockoutOnFailure: true);

                if (result.Succeeded)
                {
                    _logger.LogInformation("User logged in: {Email}", model.Email);
                    return Ok(new { Success = true });
                }

                if (result.RequiresTwoFactor)
                {
                    return Ok(new { RequiresTwoFactor = true });
                }

                if (result.IsLockedOut)
                {
                    _logger.LogWarning("User account locked out: {Email}", model.Email);
                    return BadRequest("Account locked out");
                }

                return BadRequest("Invalid login attempt");
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Login error for {Email}", model.Email);
                return StatusCode(500, "An error occurred");
            }
        }

        /// <summary>
        /// Handles new user registration.
        /// </summary>
        /// <param name="model">Registration request DTO</param>
        /// <returns>The registration result</returns>
        [HttpPost("register")]
        public async Task<IActionResult> Register([FromBody] CreateUserRequestDTO model)
        {
            if (!ModelState.IsValid)
            {
                return BadRequest(new RegisterUserResponseDTO
                {
                    Status = RegisterUserResponseDTO.ResponseStatus.Fail_RequestInvalid,
                    Errors = ModelState.Values.SelectMany(v => v.Errors).Select(e => e.ErrorMessage)
                });
            }

            var user = CreateUser();
            await _userStore.SetUserNameAsync(user, model.Email, CancellationToken.None);
            var emailStore = GetEmailStore();
            await emailStore.SetEmailAsync(user, model.Email, CancellationToken.None);

            var result = await _userManager.CreateAsync(user, model.Password);

            if (!result.Succeeded)
            {
                _logger.LogInformation("User registration failed: {Email}", model.Email);

                // Handle duplicate email error
                if (result.Errors.Any(e => e.Code == "DuplicateUserName"))
                {
                    return BadRequest(new RegisterUserResponseDTO
                    {
                        Status = RegisterUserResponseDTO.ResponseStatus.Fail_DuplicateEmail,
                    });
                }

                // Handle general Identity errors
                return BadRequest(new RegisterUserResponseDTO
                {
                    Status = RegisterUserResponseDTO.ResponseStatus.Fail_General,
                    Errors = result.Errors.Select(e => e.Description)
                });
            }

            _logger.LogInformation("User created a new account with a password.");

            // Send email confirmation link
            try
            {
                var userId = await _userManager.GetUserIdAsync(user);
                var code = await _userManager.GenerateEmailConfirmationTokenAsync(user);
                code = WebEncoders.Base64UrlEncode(Encoding.UTF8.GetBytes(code));

                // NOTE: For security, it's recommended to configure a fixed base URL
                // from your application's settings rather than relying on the request host.
                var baseUrl = model.BaseUrl ?? $"{Request.Scheme}://{Request.Host.Value}";
                var callbackUrl = $"{baseUrl}/Account/ConfirmEmail?userId={userId}&code={code}";

                await _emailSender.SendConfirmationLinkAsync(user, model.Email, HtmlEncoder.Default.Encode(callbackUrl));
            }
            catch (Exception)
            {
                // Account created successfully but email sending failed.
                return Ok(new RegisterUserResponseDTO
                {
                    Status = RegisterUserResponseDTO.ResponseStatus.Success_EmailWarning,
                    Message = "The account was created, but the verification email sending failed."
                });
            }

            return Ok(new RegisterUserResponseDTO
            {
                Status = RegisterUserResponseDTO.ResponseStatus.Success_NeedConfirmation
            });
        }

        /// <summary>
        /// Resends the email confirmation link.
        /// </summary>
        /// <param name="model">Email confirmation request DTO</param>
        /// <returns>The result of the process</returns>
        [HttpPost("emailConfirm")]
        public async Task<IActionResult> ResendEmailConfirm([FromBody] RequestEmailConfirmDTO model)
        {
            if (!ModelState.IsValid)
            {
                // Always return a success response for security (to avoid user enumeration).
                return Ok(new ResponseEmailConfirmDTO
                {
                    Status = ResponseEmailConfirmDTO.ResponseStatus.Success,
                    Message = "The confirmation email has been sent successfully."
                });
            }

            try
            {
                var user = await _userManager.FindByEmailAsync(model.Email);

                // Even if the user doesn't exist or is already confirmed, return a success response for security.
                if (user == null || user.EmailConfirmed)
                {
                    return Ok(new ResponseEmailConfirmDTO
                    {
                        Status = ResponseEmailConfirmDTO.ResponseStatus.Success,
                        Message = "The confirmation email has been sent successfully."
                    });
                }

                // Generate and send the email confirmation link
                var userId = await _userManager.GetUserIdAsync(user);
                var code = await _userManager.GenerateEmailConfirmationTokenAsync(user);
                code = WebEncoders.Base64UrlEncode(Encoding.UTF8.GetBytes(code));

                // NOTE: It is recommended to use a pre-configured base URL.
                var baseUrl = model.BaseUrl ?? $"{Request.Scheme}://{Request.Host.Value}";
                var callbackUrl = $"{baseUrl}/Account/ConfirmEmail?userId={userId}&code={code}";

                await _emailSender.SendConfirmationLinkAsync(user, model.Email, HtmlEncoder.Default.Encode(callbackUrl));

                return Ok(new ResponseEmailConfirmDTO
                {
                    Status = ResponseEmailConfirmDTO.ResponseStatus.Success,
                    Message = "The confirmation email has been sent successfully."
                });
            }
            catch (Exception)
            {
                // Mail server or other exception occurred.
                return BadRequest(new ResponseEmailConfirmDTO
                {
                    Status = ResponseEmailConfirmDTO.ResponseStatus.Fail,
                    Message = $"An error occurred while processing your request. (Server Error)"
                });
            }
        }

        /// <summary>
        /// Handles password reset requests.
        /// </summary>
        /// <param name="model">Password reset request DTO</param>
        /// <returns>The result of the process</returns>
        [HttpPost("resetPassword")]
        public async Task<IActionResult> ResetPassword([FromBody] ResetPasswordRequestDTO model)
        {
            var user = await _userManager.FindByEmailAsync(model.Email);
            if (user == null)
            {
                return BadRequest("User not found");
            }

            var resetToken = await _userManager.GeneratePasswordResetTokenAsync(user);
            var callbackUrl = $"{model.BaseUrl}/Account/ResetPassword?email={model.Email}&token={resetToken}";

            await _emailSender.SendPasswordResetLinkAsync(user, model.Email, callbackUrl);

            return Ok("Password reset link sent");
        }

        /// <summary>
        /// Handles user logout.
        /// </summary>
        /// <returns>The logout result</returns>
        [HttpPost("logout")]
        public async Task<IActionResult> Logout()
        {
            await _signInManager.SignOutAsync();
            return Ok("Logged out successfully");
        }

        /// <summary>
        /// Handles the generation of a JWT token.
        /// </summary>
        /// <param name="model">Login request DTO (email, password)</param>
        /// <returns>Token information</returns>
        [HttpPost("token")]
        public async Task<IActionResult> GenerateToken([FromBody] LoginUserRequestDTO model)
        {
            var user = await _userManager.FindByEmailAsync(model.Email);
            if (user == null || !await _userManager.CheckPasswordAsync(user, model.Password))
            {
                return Unauthorized("Invalid credentials");
            }

            var claims = new[]
            {
                new Claim(ClaimTypes.Name, user.UserName),
                new Claim(ClaimTypes.Email, user.Email)
            };

            // WARNING: Do not hard-code the key in production.
            // Move this to a secure configuration file (e.g., appsettings.json)
            // and use a strong, randomly generated key.
            var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("A_Very_Strong_And_Secret_Key_For_JWT_Auth"));
            var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);

            var token = new JwtSecurityToken(
                issuer: "yourdomain.com",
                audience: "yourdomain.com",
                claims: claims,
                expires: DateTime.Now.AddMinutes(30),
                signingCredentials: creds);

            return Ok(new { token = new JwtSecurityTokenHandler().WriteToken(token) });
        }

        #endregion

        #region External Authentication (OAuth)

        /// <summary>
        /// Initiates a challenge request to an external authentication provider (e.g., Google).
        /// </summary>
        /// <param name="provider">The name of the authentication provider (e.g., "Google")</param>
        /// <param name="returnUrl">The URL to redirect to after successful authentication</param>
        /// <returns>A challenge result to the external provider</returns>
        [HttpGet("Challenge/{provider}")]
        public IActionResult Challenge(string provider, string? returnUrl = null)
        {
            _logger.LogInformation("Starting {Provider} login", provider);

            if (string.IsNullOrWhiteSpace(provider))
            {
                return BadRequest(new { error = "Provider not specified." });
            }

            // Normalize and validate returnUrl
            returnUrl = NormalizeReturnUrl(returnUrl);

            // Set the callback URL
            var redirectUrl = Url.Action("Callback", "Auth", new { returnUrl }, Request.Scheme);

            // Configure authentication properties
            var properties = _signInManager.ConfigureExternalAuthenticationProperties(provider, redirectUrl);

            return Challenge(properties, provider);
        }

        /// <summary>
        /// Handles the callback from an external authentication provider.
        /// </summary>
        /// <param name="returnUrl">The URL to redirect to after successful authentication</param>
        /// <param name="remoteError">Error message from the external provider</param>
        /// <returns>An appropriate response based on the authentication result</returns>
        [HttpGet("externalLogin")]
        public async Task<IActionResult> Callback(string? returnUrl = null, string? remoteError = null)
        {
            try
            {
                returnUrl = NormalizeReturnUrl(returnUrl);

                if (!string.IsNullOrEmpty(remoteError))
                {
                    _logger.LogError("External provider error: {RemoteError}", remoteError);
                    return Redirect($"/login?error={Uri.EscapeDataString(remoteError)}");
                }

                var info = await _signInManager.GetExternalLoginInfoAsync();
                if (info == null)
                {
                    _logger.LogError("Could not retrieve external login info");
                    return Redirect("/login?error=external_login_failed");
                }

                // Attempt to sign in an existing user
                var result = await _signInManager.ExternalLoginSignInAsync(
                    info.LoginProvider,
                    info.ProviderKey,
                    isPersistent: false,
                    bypassTwoFactor: true);

                if (result.Succeeded)
                {
                    var user = await _userManager.FindByLoginAsync(info.LoginProvider, info.ProviderKey);
                    _logger.LogInformation("User {Email} successfully logged in", user?.Email);
                    return LocalRedirect(returnUrl);
                }

                if (result.IsLockedOut)
                {
                    _logger.LogWarning("Attempt to log in with a locked-out account");
                    return Redirect("/login?error=locked_out");
                }

                // New user or linking an existing user
                return await HandleUserCreationOrLinking(info, returnUrl);
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Error occurred while processing external login");
                return Redirect("/login?error=server_error");
            }
        }

        #endregion

        #region Helper Methods

        /// <summary>
        /// Normalizes and validates the returnUrl.
        /// </summary>
        private string NormalizeReturnUrl(string? returnUrl)
        {
            if (string.IsNullOrWhiteSpace(returnUrl))
                return "/";

            if (Uri.TryCreate(returnUrl, UriKind.Absolute, out var uri))
                returnUrl = uri.PathAndQuery;

            return Url.IsLocalUrl(returnUrl) ? returnUrl : "/";
        }

        /// <summary>
        /// Handles new user creation or linking an existing user to an external login.
        /// </summary>
        private async Task<IActionResult> HandleUserCreationOrLinking(ExternalLoginInfo info, string returnUrl)
        {
            var email = info.Principal.FindFirstValue(ClaimTypes.Email);
            if (string.IsNullOrEmpty(email))
            {
                _logger.LogError("Missing email information from external provider {Provider}", info.LoginProvider);
                return Redirect("/login?error=email_required");
            }

            var existingUser = await _userManager.FindByEmailAsync(email);
            return existingUser != null
                ? await LinkExistingUser(existingUser, info, returnUrl)
                : await CreateNewUserAsync(info, returnUrl);
        }

        /// <summary>
        /// Links external login information to an existing user.
        /// </summary>
        private async Task<IActionResult> LinkExistingUser(ApplicationUser user, ExternalLoginInfo info, string returnUrl)
        {
            var addLoginResult = await _userManager.AddLoginAsync(user, info);
            if (addLoginResult.Succeeded)
            {
                _logger.LogInformation("Successfully linked {Provider} login to existing user {Email}", info.LoginProvider, user.Email);
                await _signInManager.SignInAsync(user, isPersistent: false, info.LoginProvider);
                return LocalRedirect(returnUrl);
            }

            _logger.LogError("Failed to link external login to existing user: {Errors}",
                string.Join(", ", addLoginResult.Errors.Select(e => e.Description)));
            return Redirect("/login?error=link_failed");
        }

        /// <summary>
        /// Creates a new user based on external login information.
        /// </summary>
        private async Task<IActionResult> CreateNewUserAsync(ExternalLoginInfo info, string returnUrl)
        {
            var email = info.Principal.FindFirstValue(ClaimTypes.Email);
            if (string.IsNullOrEmpty(email))
            {
                _logger.LogError("Missing email information from external provider");
                return BadRequest(new { error = "Email information was not provided." });
            }

            var userName = email.Split('@')[0];
            var user = new ApplicationUser
            {
                UserName = email,
                Email = email,
                NickName = userName,
                EmailConfirmed = true // Email is already confirmed via external provider
            };

            var createResult = await _userManager.CreateAsync(user);
            if (!createResult.Succeeded)
            {
                _logger.LogError("User creation failed: {Errors}",
                    string.Join(", ", createResult.Errors.Select(e => e.Description)));

                // Attempt to create an alternative user name on a naming conflict
                if (createResult.Errors.Any(e => e.Code == "DuplicateUserName"))
                {
                    user.UserName = $"{userName}_{Guid.NewGuid().ToString("N").Substring(0, 4)}";
                    createResult = await _userManager.CreateAsync(user);

                    if (!createResult.Succeeded)
                    {
                        return BadRequest(new
                        {
                            error = "Account creation failed",
                            details = createResult.Errors.Select(e => e.Description)
                        });
                    }
                }
                else
                {
                    return BadRequest(new
                    {
                        error = "Account creation failed",
                        details = createResult.Errors.Select(e => e.Description)
                    });
                }
            }

            // Link external login information
            var addLoginResult = await _userManager.AddLoginAsync(user, info);
            if (!addLoginResult.Succeeded)
            {
                _logger.LogError("Failed to add login information: {Errors}",
                    string.Join(", ", addLoginResult.Errors.Select(e => e.Description)));

                // Rollback: Delete the created user
                await _userManager.DeleteAsync(user);

                return BadRequest(new
                {
                    error = "Failed to link external login information",
                    details = addLoginResult.Errors.Select(e => e.Description)
                });
            }

            _logger.LogInformation("New user created and logged in successfully: {Email}", email);
            await _signInManager.SignInAsync(user, isPersistent: false, info.LoginProvider);

            return LocalRedirect(returnUrl);
        }

        private ApplicationUser CreateUser()
        {
            try
            {
                return Activator.CreateInstance<ApplicationUser>();
            }
            catch
            {
                throw new InvalidOperationException($"Can't create an instance of '{nameof(ApplicationUser)}'. " +
                    $"Ensure that '{nameof(ApplicationUser)}' is not an abstract class and has a parameterless constructor.");
            }
        }

        private IUserEmailStore<ApplicationUser> GetEmailStore()
        {
            if (!_userManager.SupportsUserEmail)
            {
                throw new NotSupportedException("The default UI requires a user store with email support.");
            }
            return (IUserEmailStore<ApplicationUser>)_userStore;
        }

        #endregion

        #region Profile Management

        /// <summary>
        /// Handles user profile updates.
        /// </summary>
        /// <param name="model">Update request DTO</param>
        /// <returns>The result of the process</returns>
        [HttpPut("updateProfile")]
        public async Task<IActionResult> UpdateProfile([FromBody] UpdateUserProfileDTO model)
        {
            var user = await _userManager.FindByIdAsync(model.Email);
            if (user == null)
            {
                return NotFound("User not found");
            }

            user.NickName = model.Nickname;
            user.PhoneNumber = model.PhoneNumber;

            var result = await _userManager.UpdateAsync(user);
            if (!result.Succeeded)
            {
                return BadRequest(result.Errors.Select(e => e.Description));
            }

            return Ok("Profile updated successfully");
        }

        /// <summary>
        /// Handles user deletion.
        /// </summary>
        /// <param name="userId">The ID of the user to delete</param>
        /// <returns>The result of the process</returns>
        [HttpDelete("deleteUser/{userId}")]
        public async Task<IActionResult> DeleteUser(string userId)
        {
            var user = await _userManager.FindByIdAsync(userId);
            if (user == null)
            {
                return NotFound("User not found");
            }

            var result = await _userManager.DeleteAsync(user);
            if (!result.Succeeded)
            {
                return BadRequest(result.Errors.Select(e => e.Description));
            }

            return Ok("User deleted successfully");
        }

        #endregion
    }
}

private void LoginWithGoogle()
{
    try
    {
        var returnUrl = "/";
        var googleLoginUrl = $"/api/auth/Challenge/Google?returnUrl={Uri.EscapeDataString(returnUrl)}";

        // Redirect in the current window instead of a popup
        // This is a placeholder for a client-side navigation method, e.g., in Blazor
        // Navigation.NavigateTo(googleLoginUrl, forceLoad: true);
    }
    catch (Exception ex)
    {
        // Error handling
        Console.WriteLine($"Google login error: {ex.Message}");
    }
}

The post ASP.NET Core Identity를 활용한 구글 로그인(OAuth) 전체 흐름 분석 appeared first on 어제와 내일의 나 그 사이의 이야기.

Ubuntu export 명령어

1⃣ 개요

export 명령어는 현재 셸 환경에 환경 변수를 등록하거나 수정하는 데 사용

등록된 변수는 현재 셸과 그 자식 프로세스에서 사용할 수 있음

2⃣ 기본 문법

export 변수명=값

또는

export 변수명

• 변수명=값 : 새 환경 변수를 만들거나 기존 변수 값을 변경
• 변수명 : 이미 선언된 변수를 환경 변수로 승격

3⃣ 특징

• 환경 변수는 프로세스 간 전달 가능 (부모 → 자식).
• export로 설정한 변수는 현재 세션에서만 유효.
• 영구적으로 유지하려면 ~/.bashrc 또는 ~/.bash_profile에 추가해야 함.

4⃣ 확인 방법

echo $변수명       # 변수 값 출력
printenv 변수명    # 환경 변수 확인
env                # 전체 환경 변수 목록

.NET에서의 사용 예시

1⃣ ASP.NET Core에서 환경 지정

export ASPNETCORE_ENVIRONMENT=Development
export ASPNETCORE_ENVIRONMENT=Staging
export ASPNETCORE_ENVIRONMENT=Production

export DOTNET_ENVIRONMENT=Development
export DOTNET_ENVIRONMENT=Staging // 실제 운영 환경(Production)과 거의 동일하지만, 사용자에게는 서비스되지 않는 사전 검증용 환경
export DOTNET_ENVIRONMENT=Production

dotnet run

• 예를 들어 Development로 설정하면, 개발 모드 환경 설정(appsettings.Development.json)을 자동으로 사용

2⃣ .NET에서 특정 포트로 실행

# 5005번 포트로 애플리케이션 실행
export ASPNETCORE_URLS="http://localhost:5005"

dotnet run

• ASPNETCORE_URLS 환경 변수를 이용해 실행 시 포트를 변경할 수 있음

3⃣ 영구 설정

# 1. .bashrc 파일에 환경 변수 설정 명령어를 추가
echo 'export DOTNET_ENVIRONMENT=Production' >> ~/.bashrc

# 2. 수정된 .bashrc 설정을 현재 터미널 세션에 바로 적용
source ~/.bashrc

# 3. 설정 확인
echo $DOTNET_ENVIRONMENT

The post Ubuntu export 명령어 (.NET) appeared first on 어제와 내일의 나 그 사이의 이야기.

미들웨어(Middleware)

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-8.0

ASP.NET Core의 미들웨어는 모든 HTTP 요청과 응답 파이프라인을 형성하는 일련의 구성 요소입니다.

각 미들웨어 구성 요소는 다음을 수행할 수 있습니다:

• 들어오는 요청을 검사합니다.
• 요청 또는 응답을 수정합니다 (필요한 경우).
• 파이프라인의 다음 미들웨어를 호출하거나, 프로세스를 단락(short-circuit)시키고 자체적으로 응답을 생성합니다.

이러한 파이프라인을 통해 애플리케이션의 로직을 모듈화하고, 인증, 로깅, 오류 처리, 라우팅 등과 같은 기능을 깔끔하고 유지 관리하기 쉬운 방식으로 추가할 수 있습니다.

미들웨어 체인 (요청 파이프라인)

ASP.NET Core 요청 파이프라인은 차례로 호출되는 일련의 요청 대리자로 구성됩니다.

요청 파이프라인을 일련의 연결된 파이프라고 상상해 보세요.

각 미들웨어 조각은 이 파이프라인의 밸브와 같아서, 정보의 흐름을 제어하고 다양한 단계에서 특정 작업을 적용할 수 있습니다.

미들웨어를 등록하는 순서는 매우 중요하며, 등록된 순서대로 실행됩니다.

각 델리게이트는 다음 델리게이트를 호출하기 전과 후에 작업을 수행할 수 있습니다.

예외 처리 델리게이트는 파이프라인의 후반 단계에서 발생하는 예외를 Catch할 수 있도록 파이프라인의 초기에 호출되어야 합니다.

가장 간단한 ASP.NET Core 앱은 모든 요청을 처리하는 단일 요청 델리게이트를 설정합니다.

이 경우에는 실제 요청 파이프라인이 포함되지 않습니다.

대신, 모든 HTTP 요청에 대한 응답으로 단일 익명 함수가 호출됩니다.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello world!");
});

app.Run(); // 이 app.Run은 위의 app.Run이 파이프라인을 종료하므로 실행되지 않습니다.

Use 메서드를 사용하면 여러 요청 델리게이트를 체인으로 연결할 수 있습니다.

이때 next 매개변수는 파이프라인의 다음 델리게이트를 나타냅니다.

next 매개변수를 호출하지 않음으로써 파이프라인을 단락(short-circuit)시킬 수 있습니다.

다음 예시에서 보여주듯이, 일반적으로 next 델리게이트를 호출하기 전과 후에 모두 작업을 수행할 수 있습니다.

var builder = WebApplication.CreateBuilder(args); // 웹 애플리케이션 빌더를 생성합니다.
var app = builder.Build(); // 빌더를 사용하여 웹 애플리케이션 인스턴스를 생성합니다.

// 첫 번째 미들웨어: app.Use()를 사용하여 파이프라인에 추가합니다.
app.Use(async (context, next) =>
{
    // 응답에 쓸 수 있는 작업을 수행합니다. (예: 헤더 추가, 응답의 시작 부분 작성)
    // 이 부분의 코드는 다음 미들웨어가 실행되기 전에 실행됩니다.

    await next.Invoke(); // 다음 미들웨어(이 경우 app.Run)를 호출하여 제어를 넘깁니다.

    // 응답에 쓰지 않는 로깅 또는 다른 작업을 수행합니다.
    // 이 부분의 코드는 다음 미들웨어가 실행된 후(응답이 생성된 후) 실행됩니다.
});

// 두 번째 미들웨어: app.Run()을 사용하여 파이프라인에 추가합니다.
// app.Run()은 파이프라인을 종료하는 미들웨어입니다.
app.Run(async context =>
{
    // 이 미들웨어는 "Hello from 2nd delegate."를 응답에 작성하고 파이프라인을 종료합니다.
    await context.Response.WriteAsync("Hello from 2nd delegate.");
});

// 이 app.Run()은 위의 app.Run()이 이미 파이프라인을 종료했기 때문에 실행되지 않습니다.
app.Run();

요청 파이프라인 단락(Short-circuiting)

ASP.NET Core의 미들웨어 파이프라인에서, 특정 델리게이트(미들웨어)가 요청을 다음 델리게이트로 전달하지 않을 때 이를 요청 파이프라인을 단락(short-circuiting)시킨다고 합니다.

파이프라인 단락은 불필요한 작업을 피할 수 있기 때문에 종종 유용합니다.

예를 들어, 정적 파일 미들웨어(Static File Middleware)는 요청된 파일이 정적 파일(이미지, CSS, JavaScript 등)일 경우 해당 요청을 처리하고

파이프라인의 나머지 부분을 단락시킴으로써 종료 미들웨어(terminal middleware) 역할을 할 수 있습니다.

이렇게 되면 정적 파일을 제공한 후에는 인증이나 라우팅과 같은 다른 미들웨어들이 실행될 필요가 없으므로 효율성이 높아집니다.

단락과 next.Invoke() 이후 코드 실행

파이프라인의 추가적인 처리를 종료시키는 미들웨어보다 앞서 파이프라인에 추가된 미들웨어는 여전히 next.Invoke() 구문 이후의 코드를 처리합니다.

즉, 비록 파이프라인이 단락되어 최종 응답이 더 이상 아래로 전달되지 않더라도, next.Invoke()를 호출했던 이전 미들웨어들은 응답이 완료된 후 자신의 후처리 로직을 실행할 수 있습니다.

경고: 응답 전송 후 작업 주의

응답이 클라이언트에게 이미 전송되었거나 전송되기 시작한 후에는 next.Invoke()를 호출하거나 응답에 쓰려고 시도하지 마세요.

HttpResponse가 시작된 후에는 응답에 변경을 가하려고 하면 예외가 발생합니다.

예를 들어, 응답이 시작된 후 헤더나 상태 코드를 설정하려고 하면 예외가 발생합니다.

next.Invoke() 호출 후 응답 본문에 쓰는 것은 다음과 같은 문제를 야기할 수 있습니다:

• 프로토콜 위반: 명시된 Content-Length보다 더 많은 내용을 작성하는 것과 같은 프로토콜 위반을 초래할 수 있습니다.
• 본문 형식 손상: CSS 파일에 HTML 푸터(footer)를 작성하는 것처럼 본문 형식을 손상시킬 수 있습니다.

HasStarted 속성은 헤더가 전송되었는지 또는 본문이 작성되었는지 여부를 나타내는 유용한 힌트가 될 수 있습니다.

app.Use vs. app.Run

이 두 메서드는 파이프라인에 미들웨어를 추가하는 데 기본적이지만, 핵심적인 차이점이 있습니다:

app.Use(async (context, next) => { ... })

• 요청 수정 불가:
  마지막 단계이므로 요청을 다음으로 전달하기 전에 수정할 수 없습니다.
• 비종료(Non-Terminal) 미들웨어:
  이 유형의 미들웨어는 일반적으로 어떤 작업을 수행한 다음, next 델리게이트를 호출하여 파이프라인의 다음 미들웨어로 제어를 전달합니다.
• 요청/응답 수정 가능:
  요청을 다음으로 전달하기 전에 요청이나 응답을 변경할 수 있습니다.
• 예시:
  인증, 로깅, 커스텀 헤더 추가 등.

app.Run(async (context) => { ... })

• 종료(Terminal) 미들웨어:
  이 미들웨어는 next를 호출하지 않습니다.
  파이프라인을 종료하고 자체적으로 응답을 생성합니다.
• 최종 응답에 주로 사용:
  더 이상 처리가 필요 없는 요청(예: 간단한 메시지 반환)을 처리하는 데 일반적으로 사용됩니다.

// 여러 app.Run 호출의 결과

app.Run(async (HttpContext context) => {
    await context.Response.WriteAsync("Hello");
});

app.Run(async (HttpContext context) => {
    await context.Response.WriteAsync("Hello again");
});

app.Run(); // 이 app.Run은 위의 app.Run들이 이미 파이프라인을 종료했기 때문에 절대 실행되지 않습니다.

이 코드에서는 오직 첫 번째 app.Run 미들웨어만 실행됩니다.

“Hello”를 응답에 작성하여 파이프라인을 종료하고, 그 뒤의 app.Run (이것은 “Hello again”을 작성할 것임)은 실행될 기회를 얻지 못합니다.

// app.Use와 app.Run으로 미들웨어 체인 연결하기

// 미들웨어 1
app.Use(async (context, next) => {
    await context.Response.WriteAsync("Hello "); // 1. "Hello " 작성
    await next(context); // 2. 다음 미들웨어 호출
});

// 미들웨어 2
app.Use(async (context, next) => {
    await context.Response.WriteAsync("Hello again "); // 3. "Hello again " 작성
    await next(context); // 4. 다음 미들웨어 호출 (이 경우 app.Run)
});

// 미들웨어 3 (종료 미들웨어)
app.Run(async (HttpContext context) => {
    await context.Response.WriteAsync("Hello again"); // 5. "Hello again" 작성 후 파이프라인 종료
});

이 코드는 미들웨어를 올바르게 연결하는 방법을 보여줍니다.

1. 첫 번째 app.Use는 응답에 “Hello “를 작성하고 next를 호출하여 다음 미들웨어로 제어를 전달합니다.
2. 두 번째 app.Use는 “Hello again “을 작성하고 역시 next를 호출합니다.
3. 마지막 app.Run (종료 미들웨어)는 “Hello again”을 작성하고 파이프라인을 종료합니다.

ASP.NET Core의 커스텀 미들웨어

ASP.NET Core는 다양한 내장 미들웨어 구성 요소를 제공하지만, 때로는 애플리케이션 고유의 특정 요구 사항을 해결하기 위해 자신만의 커스텀 미들웨어를 만들어야 할 수도 있습니다.

커스텀 미들웨어를 통해 다음을 수행할 수 있습니다:

• 로직 캡슐화:
  관련 작업(예: 로깅, 보안 검사, 사용자 정의 헤더)을 재사용 가능한 구성 요소로 묶습니다.
• 동작 사용자 정의:
  애플리케이션의 요구 사항에 정확히 맞게 요청/응답 파이프라인을 조정합니다.
• 코드 구성 개선:
  미들웨어 코드를 깔끔하고 유지 관리하기 쉽게 만듭니다.

커스텀 미들웨어 클래스의 구조

IMiddleware 구현: 이 인터페이스는 단 하나의 메서드 InvokeAsync(HttpContext context, RequestDelegate next)를 요구합니다.

이 메서드는 미들웨어 로직의 핵심입니다

InvokeAsync 또는 Invoke 메서드

• context:
  HttpContext는 요청 및 응답 객체에 대한 접근을 제공합니다.
• next:
  RequestDelegate는 파이프라인의 다음 미들웨어를 호출할 수 있도록 합니다.

// MyCustomMiddleware.cs
namespace MiddlewareExample.CustomMiddleware
{
    public class MyCustomMiddleware : IMiddleware // IMiddleware 인터페이스 구현
    {
        public async Task InvokeAsync(HttpContext context, RequestDelegate next)
        {
            await context.Response.WriteAsync("My Custom Middleware - Starts\n"); // 1. 응답 시작 부분에 출력
            await next(context); // 2. 다음 미들웨어 호출
            await context.Response.WriteAsync("My Custom Middleware - Ends\n"); // 3. 다음 미들웨어 완료 후 응답 끝 부분에 출력
        }
    }

    // 쉽게 등록하기 위한 확장 메서드
    public static class CustomMiddlewareExtension
    {
        public static IApplicationBuilder UseMyCustomMiddleware(this IApplicationBuilder app)
        {
            return app.UseMiddleware<MyCustomMiddleware>();
        }
    }
}

// Program.cs (또는 Startup.cs)
using MiddlewareExample.CustomMiddleware;

// ... (다른 설정 코드) ...

builder.Services.AddTransient<MyCustomMiddleware>(); // 트랜지언트 서비스로 등록

app.Use(async (HttpContext context, RequestDelegate next) => {
    await context.Response.WriteAsync("From Middleware 1\n"); // 첫 번째 미들웨어: 시작 부분
    await next(context);
});

app.UseMyCustomMiddleware(); // 확장 메서드를 사용하여 커스텀 미들웨어 추가

app.Run(async (HttpContext context) => {
    await context.Response.WriteAsync("From Middleware 3\n"); // 세 번째 미들웨어: 파이프라인 종료
});

• 등록:
  ASP.NET Core가 필요할 때 MyCustomMiddleware 인스턴스를 생성할 수 있도록 이를 트랜지언트 서비스로 등록합니다.
• 파이프라인 통합:
  app.UseMyCustomMiddleware() 확장 메서드는 커스텀 미들웨어를 파이프라인에 추가합니다.
• 실행 순서:
  미들웨어 구성 요소는 파이프라인에 추가된 순서대로 실행됩니다. 이 경우 순서는 미들웨어 1, MyCustomMiddleware, 그리고 미들웨어 3이 됩니다.

커스텀 컨벤셔널 미들웨어 (Custom Conventional Middleware)

ASP.NET Core 미들웨어에는 두 가지 유형이 있습니다: 컨벤셔널(Conventional)과 팩토리 기반(Factory-based)

예시에서 보여진 컨벤셔널 미들웨어는 HTTP 요청 및 응답 처리를 위한 커스텀 로직을 캡슐화하는 간단하면서도 강력한 방법입니다.

주요 특징

• 클래스 기반:
  컨벤셔널 미들웨어는 클래스로 구현됩니다.
• 생성자 주입:
  의존성(있는 경우)을 생성자를 통해 받습니다.
• Invoke 메서드:
  이 메서드는 각 요청을 처리하는 로직을 포함하는 미들웨어의 핵심입니다.
• RequestDelegate:
  Invoke 메서드는 RequestDelegate 매개변수(_next로 명명)를 받습니다. 이 델리게이트는 파이프라인의 다음 미들웨어를 나타냅니다.
• 유연성:
  Invoke 메서드 내에서 요청 및 응답 객체를 완벽하게 제어할 수 있습니다.

// NameConcatenationMiddleware.cs
public class NameConcatenationMiddleware
{
    private readonly RequestDelegate _next;

    public NameConcatenationMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        if (context.Request.Query.ContainsKey("firstname") &&
            context.Request.Query.ContainsKey("lastname"))
        {
            string fullName = $"{context.Request.Query["firstname"]} {context.Request.Query["lastname"]}";
            await context.Response.WriteAsync(fullName);
            return; // 명시적으로 반환하여 다음 미들웨어 호출 방지
        }
        
        await _next(context);
    }
}

// MiddlewareExtensions.cs
public static class MiddlewareExtensions
{
    public static IApplicationBuilder UseNameConcatenation(this IApplicationBuilder builder)
    {
        return builder.UseMiddleware<NameConcatenationMiddleware>();
    }
}

미들웨어 파이프라인의 이상적인 순서

미들웨어의 순서는 애플리케이션의 동작과 효율성, 보안에 큰 영향을 미칩니다.

다음은 일반적으로 권장되는 이상적인 순서입니다

예외/오류 처리(Exception/Error Handling):

• 목적: 파이프라인의 어느 곳에서든 발생하는 예외를 Catch하고 처리합니다.
• 예시: UseExceptionHandler (프로덕션용), UseDeveloperExceptionPage (개발 환경용).
• 이유: 예외를 초기에 Catch하여 파이프라인 아래로 전파되어 더 큰 문제를 일으키는 것을 방지합니다.

HTTPS 리디렉션(HTTPS Redirection):

• 목적: 보안을 위해 HTTP 요청을 HTTPS로 리디렉션합니다.
• 예시: UseHttpsRedirection.
• 이유: 보안을 최우선으로 하여 모든 통신이 암호화되도록 합니다.

정적 파일(Static Files):

• 목적: 이미지, CSS, JavaScript 파일과 같은 정적 파일을 클라이언트에게 직접 제공합니다.
• 예시: UseStaticFiles.
• 이유: 정적 파일 요청은 빠르게 처리되어야 하며, 불필요하게 파이프라인의 다른 무거운 구성 요소를 거치지 않도록 일찍 처리합니다.

라우팅(Routing):

• 목적: URL을 기반으로 들어오는 요청을 특정 엔드포인트에 매칭합니다.
• 예시: UseRouting, UseEndpoints.
• 이유: 라우팅은 애플리케이션의 핵심 로직이 요청을 어떻게 처리할지 결정하는 기반이 됩니다.

CORS (Cross-Origin Resource Sharing):

• 목적: 다른 도메인으로부터의 안전한 교차 출처(cross-origin) 요청을 가능하게 합니다.
• 예시: UseCors.
• 이유: 인증/인가 전에 위치하여, 사전 요청(preflight request)이 불필요하게 인증/인가 미들웨어를 거치지 않도록 합니다.

인증(Authentication):

• 목적: 사용자 신원을 확인하고 사용자 주체(principal)를 설정합니다.
• 예시: UseAuthentication.
• 이유: 사용자가 누구인지 확인한 후에 리소스에 대한 접근 권한을 부여할 수 있습니다.

인가(Authorization):

• 목적: 사용자가 특정 리소스에 접근하거나 특정 작업을 수행할 수 있는지 여부를 결정합니다.
• 예시: UseAuthorization.
• 이유: 인증된 사용자에게만 권한 부여 여부를 검사합니다.

커스텀 미들웨어(Custom Middleware):

• 목적: 로깅, 기능 플래그 등 애플리케이션별 미들웨어 구성 요소를 처리합니다.
• 이유: 애플리케이션별 로직을 적절한 단계에서 파이프라인 내에 배치합니다.

MVC/Razor Pages/Minimal APIs:

• 목적: 실제 애플리케이션의 최종 엔드포인트 처리 로직을 실행합니다.
• 예시: MapControllers(), MapRazorPages(), MapGet() 등.

Program.cs 파일에 미들웨어 구성 요소가 추가되는 순서는 요청 시 미들웨어 구성 요소가 호출되는 순서를 정의하며, 응답 시에는 역순으로 호출됩니다.

이러한 순서는 보안, 성능 및 기능에 매우 중요합니다.

Program.cs의 다음 강조 표시된 코드는 보안 관련 미들웨어 구성 요소를 일반적으로 권장되는 순서로 추가하는 예시입니다:

using Microsoft.AspNetCore.Identity;
using Microsoft.EntityFrameworkCore;
using WebMiddleware.Data;

var builder = WebApplication.CreateBuilder(args);

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection")
    ?? throw new InvalidOperationException("Connection string 'DefaultConnection' not found.");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();

builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();
builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseMigrationsEndPoint();
}
else
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
// app.UseCookiePolicy();

app.UseRouting();
// app.UseRateLimiter();
// app.UseRequestLocalization();
// app.UseCors();

app.UseAuthentication();
app.UseAuthorization();
// app.UseSession();
// app.UseResponseCompression();
// app.UseResponseCaching();

app.MapRazorPages();
app.MapDefaultControllerRoute();

app.Run();

UseWhen()

UseWhen()은 ASP.NET Core의 IApplicationBuilder 인터페이스에 있는 강력한 확장 메서드입니다.

이는 조건(predicate)에 따라 미들웨어를 요청 파이프라인에 조건부로 추가할 수 있도록 합니다.

즉, 특정 조건이 충족될 때만 특정 미들웨어 구성 요소가 실행되는 동적인 파이프라인을 만들 수 있습니다.

app.UseWhen(
    context => /* 여기에 조건 */, // HttpContext를 받아 true/false 반환
    app => /* 이 분기에서 실행될 미들웨어 구성 */ // 조건이 true일 때 실행될 미들웨어 파이프라인
);

• context:
  현재 요청을 나타내는 HttpContext 객체입니다.
• Predicate (조건):
  HttpContext를 받아들이고 미들웨어 분기가 실행되어야 할 경우 true를, 그렇지 않을 경우 false를 반환하는 함수입니다.
• Middleware Configuration (미들웨어 구성):
  조건이 true일 때 실행되어야 할 미들웨어 구성 요소를 구성하는 액션입니다.
  여기서 app.Use(), app.Run(), 또는 다른 미들웨어 등록 메서드를 사용합니다.

UseWhen() 작동 방식

• 조건 평가:
  요청이 들어오면 UseWhen() 메서드는 먼저 HttpContext에 대해 조건 함수를 평가합니다.
• 분기(조건이 true일 경우):
  조건이 true를 반환하면, 구성 액션에 지정된 미들웨어 분기가 실행됩니다.
  요청은 이 분기를 통해 흐르며, 수정되거나 응답을 생성할 수 있습니다.
• 메인 파이프라인 재진입:
  분기가 실행된 후(또는 조건이 false여서 건너뛰어진 경우), 요청 흐름은 메인 파이프라인으로 다시 진입하여 UseWhen() 호출 뒤에 등록된 다음 미들웨어 구성 요소로 계속 진행됩니다.

app.UseWhen(
    context => context.Request.Query.ContainsKey("username"), // 조건: 쿼리 문자열에 "username"이 있는지 확인
    app => {
        app.Use(async (context, next) =>
        {
            await context.Response.WriteAsync("Hello from Middleware branch\n"); // 분기 미들웨어: "Hello from Middleware branch" 작성
            await next(); // 다음 미들웨어 호출
        });
    });

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from middleware at main chain"); // 메인 파이프라인 미들웨어
});

• 조건:
  context.Request.Query.ContainsKey("username") 조건은 쿼리 문자열에 “username”이라는 매개변수가 포함되어 있는지 확인합니다.
• 분기 미들웨어:
  “username” 매개변수가 존재하면 분기 미들웨어가 실행됩니다.
  이 미들웨어는 응답에 “Hello from Middleware branch”를 작성하고 next를 호출하여 나머지 파이프라인이 계속되도록 합니다.
• 메인 파이프라인:
  마지막 app.Run 미들웨어는 메인 파이프라인의 일부입니다.
  이는 응답에 “Hello from middleware at main chain”을 작성합니다.

UseWhen() 사용 시점

• 조건부 기능:
  요청에 따라 특정 기능을 활성화하거나 비활성화합니다 (예: 특정 사용자에게만 로깅, 쿼리 매개변수에 따른 캐싱 규칙 적용).
• 동적 파이프라인:
  다양한 요청에 맞춰 조정되는 파이프라인을 만듭니다 (예: 특정 경로에 대해 다른 인증 미들웨어).
• A/B 테스트:
  실험을 위해 사용자 하위 집합을 대체 미들웨어 분기를 통해 라우팅합니다.
• 디버깅 및 진단:
  개발 환경에서만 진단 미들웨어를 적용합니다.

The post ASP.NET Core의 미들웨어(Middleware) appeared first on 어제와 내일의 나 그 사이의 이야기.

.NET의 파이프 작업

https://learn.microsoft.com/en-us/dotnet/standard/io/pipe-operations

파이프는 프로세스 간 통신(Interprocess Communication, IPC)을 위한 수단을 제공합니다.

파이프에는 두 가지 유형이 있습니다:

• 익명 파이프 (Anonymous Pipes)
• 명명된 파이프 (Named Pipes)

익명 파이프 (Anonymous Pipes)

익명 파이프는 로컬 컴퓨터에서 프로세스 간 통신을 제공합니다.

익명 파이프는 명명된 파이프보다 오버헤드가 적지만 제공하는 서비스가 제한적입니다.

익명 파이프는 단방향이며 네트워크를 통해 사용할 수 없습니다. 또한 단일 서버 인스턴스만 지원합니다.

익명 파이프는 스레드 간 통신, 또는 파이프 핸들을 자식 프로세스가 생성될 때 쉽게 전달할 수 있는 부모-자식 프로세스 간 통신에 유용합니다.

.NET에서는 AnonymousPipeServerStream 및 AnonymousPipeClientStream 클래스를 사용하여 익명 파이프를 구현합니다.

익명 파이프 (Anonymous Pipes) 사용 방법

https://learn.microsoft.com/en-us/dotnet/standard/io/how-to-use-anonymous-pipes-for-local-interprocess-communication

예제 1: 서버 프로세스 (부모 프로세스)

다음 예제는 익명 파이프를 사용하여 부모 프로세스에서 자식 프로세스로 문자열을 보내는 방법을 보여줍니다.

이 예제에서는 부모 프로세스에 PipeDirection.Out 값을 가진 AnonymousPipeServerStream 객체를 생성합니다.

그런 다음 부모 프로세스는 클라이언트 핸들을 사용하여 AnonymousPipeClientStream 객체를 생성하는 자식 프로세스를 시작합니다.

자식 프로세스는 PipeDirection.In 값을 가집니다.

이후 부모 프로세스는 사용자가 입력한 문자열을 자식 프로세스로 보냅니다.

해당 문자열은 자식 프로세스의 콘솔에 표시됩니다. 다음은 서버 프로세스(부모 프로세스) 코드입니다.

using System;
using System.IO;
using System.IO.Pipes;
using System.Diagnostics; // Process 클래스를 사용하기 위해 추가

class PipeServer
{
    static void Main()
    {
        Process pipeClient = new Process(); // 자식 프로세스를 제어할 Process 객체 생성

        pipeClient.StartInfo.FileName = "pipeClient.exe"; // 실행할 자식 프로세스의 파일 이름 설정

        // AnonymousPipeServerStream 객체 생성
        // PipeDirection.Out: 서버 -> 클라이언트로 데이터를 보냄 (단방향)
        // HandleInheritability.Inheritable: 자식 프로세스가 이 파이프 핸들을 상속받을 수 있도록 설정
        using (AnonymousPipeServerStream pipeServer =
            new AnonymousPipeServerStream(PipeDirection.Out,
            HandleInheritability.Inheritable))
        {
            Console.WriteLine($"[SERVER] 현재 전송 모드: {pipeServer.TransmissionMode}.");

            // 자식 프로세스에게 서버 파이프의 클라이언트 핸들을 문자열로 전달합니다.
            pipeClient.StartInfo.Arguments =
                pipeServer.GetClientHandleAsString();
            pipeClient.StartInfo.UseShellExecute = false; // 셸 실행 대신 직접 프로세스 시작
            pipeClient.Start(); // 자식 프로세스 시작

            // 자식 프로세스가 핸들을 상속받은 후, 부모 프로세스는 자신의 클라이언트 핸들 복사본을 해제합니다.
            // 이는 불필요한 리소스 유지를 방지합니다.
            pipeServer.DisposeLocalCopyOfClientHandle();

            try
            {
                // 사용자 입력을 읽고 그 내용을 클라이언트 프로세스로 보냅니다.
                using (StreamWriter sw = new StreamWriter(pipeServer))
                {
                    sw.AutoFlush = true; // 매 쓰기 작업 후 스트림 자동 플러시 설정

                    // '동기화 메시지'를 클라이언트로 보내고 클라이언트가 이를 받을 때까지 기다립니다.
                    sw.WriteLine("SYNC");
                    pipeServer.WaitForPipeDrain(); // 파이프에 기록된 모든 데이터가 전송될 때까지 대기

                    // 콘솔 입력을 클라이언트 프로세스로 보냅니다.
                    Console.Write("[SERVER] 텍스트를 입력하세요: ");
                    sw.WriteLine(Console.ReadLine());
                }
            }
            // 파이프가 끊어지거나 연결이 해제될 때 발생하는 IOException을 잡습니다.
            catch (IOException e)
            {
                Console.WriteLine($"[SERVER] 오류: {e.Message}");
            }
        } // using 블록을 벗어나면 pipeServer는 자동으로 Dispose됩니다.

        // 자식 프로세스가 종료될 때까지 기다립니다.
        pipeClient.WaitForExit();
        // 자식 프로세스 객체를 닫습니다.
        pipeClient.Close();
        Console.WriteLine("[SERVER] 클라이언트 종료. 서버도 종료합니다.");
    }
}

예제 2: 클라이언트 프로세스 (자식 프로세스)

다음 예제는 클라이언트 프로세스를 보여줍니다.

서버 프로세스는 클라이언트 프로세스를 시작하고 해당 프로세스에 클라이언트 핸들을 전달합니다.

클라이언트 코드로부터 생성된 실행 파일은 pipeClient.exe라는 이름으로 서버 실행 파일과 동일한 디렉토리에 복사되어야 서버 프로세스를 실행하기 전에 올바르게 동작합니다.

using System;
using System.IO;
using System.IO.Pipes;

class PipeClient
{
    static void Main(string[] args)
    {
        // 프로그램 인수가 있는지 확인합니다.
        // 서버가 클라이언트 핸들을 인수로 전달하기 때문에 필요합니다.
        if (args.Length > 0)
        {
            // AnonymousPipeClientStream 객체를 생성합니다.
            // PipeDirection.In: 클라이언트는 서버로부터 데이터를 받음 (단방향)
            // args[0]: 서버가 전달한 파이프 핸들 문자열
            using (PipeStream pipeClient =
                new AnonymousPipeClientStream(PipeDirection.In, args[0]))
            {
                Console.WriteLine($"[CLIENT] 현재 전송 모드: {pipeClient.TransmissionMode}.");

                // 파이프 스트림에서 텍스트를 읽기 위한 StreamReader 생성
                using (StreamReader sr = new StreamReader(pipeClient))
                {
                    string temp;

                    // 서버로부터 '동기화 메시지'가 올 때까지 기다립니다.
                    do
                    {
                        Console.WriteLine("[CLIENT] 동기화 대기 중...");
                        temp = sr.ReadLine();
                    }
                    while (!temp.StartsWith("SYNC")); // 'SYNC'로 시작하는 메시지를 받을 때까지 반복

                    // 서버 데이터를 읽고 콘솔에 출력합니다.
                    while ((temp = sr.ReadLine()) != null) // 스트림의 끝(null)이 아닐 때까지 읽기
                    {
                        Console.WriteLine("[CLIENT] 에코: " + temp);
                    }
                }
            } // using 블록을 벗어나면 pipeClient는 자동으로 Dispose됩니다.
        }
        Console.Write("[CLIENT] 계속하려면 Enter 키를 누르세요...");
        Console.ReadLine(); // 사용자가 Enter를 누를 때까지 대기
    }
}

명명된 파이프 (Named Pipes)

명명된 파이프는 파이프 서버와 하나 이상의 파이프 클라이언트 간 프로세스 간 통신을 제공합니다.

명명된 파이프는 단방향 또는 양방향이 될 수 있습니다.

이는 메시지 기반 통신을 지원하며, 여러 클라이언트가 동일한 파이프 이름을 사용하여 서버 프로세스에 동시에 연결할 수 있도록 합니다.

명명된 파이프는 또한 가장(impersonation)을 지원하는데, 이를 통해 연결 프로세스가 원격 서버에서 자신의 권한을 사용할 수 있습니다.

.NET에서는 NamedPipeServerStream 및 NamedPipeClientStream 클래스를 사용하여 명명된 파이프를 구현합니다.

가장(Impersonation)이란?

컴퓨터 시스템에서 어떤 리소스(예: 파일, 네트워크 공유, 데이터베이스)에 접근하려면 해당 작업을 수행하는 사용자 계정의 권한이 필요

일반적으로 서버 애플리케이션은 특정 계정(예: 시스템 계정, 서비스 계정)의 권한으로 실행됩니다.

만약 서버가 클라이언트가 요청한 작업을 클라이언트 자신의 권한으로 수행해야 할 때가 있습니다. 예를 들어:

• 클라이언트가 접근 권한을 가진 특정 파일 읽기/쓰기:
  서버는 클라이언트가 보낸 파일 경로에 대해 읽기/쓰기 요청을 받았습니다.
  하지만 서버는 해당 파일에 직접 접근할 권한이 없고, 오직 클라이언트 계정만 그 파일에 접근할 권한을 가지고 있을 수 있습니다.
• 클라이언트의 네트워크 자격 증명 사용:
  클라이언트가 원격 네트워크 공유에 있는 리소스에 접근하고 싶을 때,
  서버가 클라이언트를 ‘가장’하여 클라이언트의 네트워크 자격 증명(사용자 이름과 비밀번호)을 사용하여 해당 공유에 접근할 수 있습니다.

명명된 파이프(Named Pipes) 사용 방법

https://learn.microsoft.com/en-us/dotnet/standard/io/how-to-use-named-pipes-for-network-interprocess-communication

예제 1: NamedPipeServerStream 클래스를 사용하여 명명된 파이프 생성하기

다음 예제는 NamedPipeServerStream 클래스를 사용하여 명명된 파이프를 생성하는 방법을 보여줍니다.

이 예제에서 서버 프로세스는 4개의 스레드를 생성합니다. 각 스레드는 하나의 클라이언트 연결을 수락할 수 있습니다.

연결된 클라이언트 프로세스는 서버에 파일 이름을 제공합니다.

만약 클라이언트가 충분한 권한을 가지고 있다면, 서버 프로세스는 해당 파일을 열고 그 내용을 다시 클라이언트에게 보냅니다.

using System;
using System.IO;
using System.IO.Pipes;
using System.Text;
using System.Threading;

public class PipeServer
{
    // 동시에 처리할 서버 스레드의 개수 (클라이언트 연결을 수락할 인스턴스 수)
    private static int numThreads = 4;

    public static void Main()
    {
        int i;
        // 서버 스레드를 담을 배열 선언
        Thread?[] servers = new Thread[numThreads];

        Console.WriteLine("\n*** 명명된 파이프 서버 스트림과 가장(impersonation) 예제 ***\n");
        Console.WriteLine("클라이언트 연결 대기 중...\n");

        // numThreads 개수만큼 서버 스레드를 생성하고 시작합니다.
        for (i = 0; i < numThreads; i++)
        {
            servers[i] = new Thread(ServerThread); // ServerThread 메서드를 실행할 새 스레드 생성
            servers[i]?.Start(); // 스레드 시작
        }

        // 서버 스레드가 시작될 시간을 잠시 기다립니다.
        Thread.Sleep(250);

        // 모든 서버 스레드가 작업을 완료할 때까지 대기하는 루프
        // 'i'는 아직 완료되지 않은 스레드의 개수를 추적합니다.
        while (i > 0)
        {
            for (int j = 0; j < numThreads; j++)
            {
                if (servers[j] != null) // 스레드가 아직 활성 상태인 경우
                {
                    // 스레드가 250ms 내에 완료되는지 확인합니다.
                    // 완료되면 해당 스레드를 null로 설정하고 카운트를 줄입니다.
                    if (servers[j]!.Join(250))
                    {
                        Console.WriteLine($"서버 스레드[{servers[j]!.ManagedThreadId}] 작업 완료.");
                        servers[j] = null; // 완료된 스레드 참조 제거
                        i--;               // 완료되지 않은 스레드 개수 감소
                    }
                }
            }
        }
        Console.WriteLine("\n서버 스레드 모두 소진, 종료합니다.");
    }

    // 각 클라이언트 연결을 처리할 서버 스레드의 진입점 메서드
    private static void ServerThread(object? data)
    {
        // NamedPipeServerStream 인스턴스 생성
        // "testpipe": 파이프 이름 (클라이언트가 이 이름으로 연결 시도)
        // PipeDirection.InOut: 양방향 통신
        // numThreads: 이 파이프 이름으로 동시에 허용할 서버 인스턴스(클라이언트 연결)의 최대 수
        NamedPipeServerStream pipeServer =
            new NamedPipeServerStream("testpipe", PipeDirection.InOut, numThreads);

        int threadId = Thread.CurrentThread.ManagedThreadId; // 현재 스레드의 ID

        // 클라이언트가 연결될 때까지 대기합니다.
        // 이 메서드는 블로킹(blocking) 호출입니다.
        pipeServer.WaitForConnection();

        Console.WriteLine($"클라이언트가 스레드[{threadId}]에 연결되었습니다.");
        try
        {
            // 클라이언트로부터 요청을 읽습니다.
            // 클라이언트가 파이프에 데이터를 쓰면, 클라이언트의 보안 토큰을 사용할 수 있게 됩니다.
            StreamString ss = new StreamString(pipeServer);

            // 연결된 클라이언트에게 서버임을 증명하는 문자열을 보냅니다.
            // 클라이언트는 이 문자열을 예상하고 있습니다.
            ss.WriteString("나는 유일한 참된 서버입니다!");
            // 클라이언트로부터 파일 이름을 읽습니다.
            string filename = ss.ReadString();

            // 클라이언트를 가장(impersonate)하여 파일 내용을 읽어 스트림으로 보냅니다.
            // ReadFileToStream 클래스는 파일 읽기 로직을 캡슐화합니다.
            ReadFileToStream fileReader = new ReadFileToStream(ss, filename);

            // 현재 가장하고 있는 사용자의 이름을 출력합니다.
            Console.WriteLine($"파일 읽기: {filename} (스레드[{threadId}]) 사용자: {pipeServer.GetImpersonationUserName()}로.");
            // 클라이언트를 가장한 보안 컨텍스트 내에서 fileReader.Start 메서드를 실행합니다.
            // 이 시점부터 Start() 메서드 내의 파일 접근은 클라이언트의 권한으로 이루어집니다.
            pipeServer.RunAsClient(fileReader.Start);
        }
        // 파이프가 끊어지거나 연결이 해제될 때 발생하는 IOException을 잡습니다.
        catch (IOException e)
        {
            Console.WriteLine($"오류: {e.Message}");
        }
        finally
        {
            // 파이프 서버 스트림을 닫고 리소스를 해제합니다.
            pipeServer.Close();
            Console.WriteLine($"스레드[{threadId}] 파이프 서버 닫힘.");
        }
    }
}

// 스트림에서 문자열을 읽고 쓰기 위한 데이터 프로토콜을 정의하는 클래스
public class StreamString
{
    private Stream ioStream; // 기본 스트림 (NamedPipeServerStream 또는 NamedPipeClientStream)
    private UnicodeEncoding streamEncoding; // 문자열 인코딩 방식

    public StreamString(Stream ioStream)
    {
        this.ioStream = ioStream;
        streamEncoding = new UnicodeEncoding(); // UTF-16 인코딩 사용
    }

    // 스트림에서 문자열을 읽습니다.
    public string ReadString()
    {
        // 먼저 문자열의 길이를 2바이트로 읽습니다. (Big-endian 방식으로)
        int len = 0;
        len = ioStream.ReadByte() * 256; // 첫 번째 바이트 (상위 8비트)
        len += ioStream.ReadByte();      // 두 번째 바이트 (하위 8비트)

        // 읽을 길이만큼의 바이트 배열을 생성합니다.
        byte[] inBuffer = new byte[len];
        // 스트림에서 해당 길이만큼의 바이트를 읽어 버퍼에 채웁니다.
        ioStream.Read(inBuffer, 0, len);

        // 바이트 배열을 문자열로 디코딩하여 반환합니다.
        return streamEncoding.GetString(inBuffer);
    }

    // 스트림에 문자열을 씁니다.
    public int WriteString(string outString)
    {
        // 문자열을 바이트 배열로 인코딩합니다.
        byte[] outBuffer = streamEncoding.GetBytes(outString);
        int len = outBuffer.Length;

        // 문자열 길이가 UInt16.MaxValue (65535)를 초과하면 잘라냅니다.
        // (프로토콜이 2바이트 길이 필드를 사용하므로 최대 65535 바이트까지 표현 가능)
        if (len > UInt16.MaxValue)
        {
            len = (int)UInt16.MaxValue;
        }

        // 문자열의 길이를 2바이트로 스트림에 씁니다. (Big-endian 방식으로)
        ioStream.WriteByte((byte)(len / 256)); // 상위 바이트
        ioStream.WriteByte((byte)(len & 255)); // 하위 바이트
        // 문자열 바이트 배열을 스트림에 씁니다.
        ioStream.Write(outBuffer, 0, len);
        // 버퍼에 남아있는 데이터를 즉시 스트림으로 밀어 넣습니다.
        ioStream.Flush();

        // 전송된 총 바이트 수 (문자열 바이트 + 길이 2바이트)를 반환합니다.
        return outBuffer.Length + 2;
    }
}

// 가장된 사용자(클라이언트)의 컨텍스트에서 실행될 메서드를 포함하는 클래스
public class ReadFileToStream
{
    private string fn; // 읽을 파일 이름
    private StreamString ss; // 파일 내용을 쓸 스트림 (StreamString 헬퍼 사용)

    public ReadFileToStream(StreamString str, string filename)
    {
        fn = filename;
        ss = str;
    }

    // 이 메서드는 pipeServer.RunAsClient()에 의해 호출되며,
    // 호출되는 동안 현재 스레드의 보안 컨텍스트가 클라이언트로 변경됩니다.
    public void Start()
    {
        // 클라이언트의 권한으로 파일을 읽습니다.
        string contents = File.ReadAllText(fn);
        // 읽은 파일 내용을 스트림을 통해 클라이언트에게 다시 보냅니다.
        ss.WriteString(contents);
    }
}

예제 2: NamedPipeClientStream 클래스를 사용하는 클라이언트 프로세스

다음 예제는 NamedPipeClientStream 클래스를 사용하는 클라이언트 프로세스를 보여줍니다.

이 클라이언트는 서버 프로세스에 연결하여 서버로 파일 이름을 전송합니다.

이 예제에서는 가장(impersonation) 기능을 사용하므로, 클라이언트 애플리케이션을 실행하는 사용자 계정에 해당 파일에 접근할 수 있는 권한이 있어야 합니다.

그러면 서버는 파일 내용을 다시 클라이언트에게 전송하고, 클라이언트는 그 내용을 콘솔에 표시합니다.

using System;
using System.Diagnostics; // 프로세스 관련 기능을 위해 추가
using System.IO;          // 파일 및 스트림 관련 기능을 위해 추가
using System.IO.Pipes;    // Named Pipe 관련 기능을 위해 추가
using System.Security.Principal; // TokenImpersonationLevel을 위해 추가
using System.Text;        // 인코딩을 위해 추가
using System.Threading;   // 스레드 및 Sleep을 위해 추가

public class PipeClient
{
    // 생성할 클라이언트 프로세스의 개수
    private static int numClients = 4;

    public static void Main(string[] args)
    {
        // 프로그램이 'spawnclient' 인수를 가지고 실행되었는지 확인합니다.
        // 이 인수는 메인 프로세스가 다른 클라이언트 프로세스를 시작할 때 사용됩니다.
        if (args.Length > 0)
        {
            if (args[0] == "spawnclient")
            {
                // 'spawnclient' 인수가 있는 경우, 명명된 파이프 클라이언트를 생성하고 서버에 연결합니다.
                var pipeClient =
                    new NamedPipeClientStream(
                        ".",                 // 파이프가 로컬 컴퓨터에 있음을 나타냅니다. (서버 주소)
                        "testpipe",          // 연결할 파이프 이름 (서버의 파이프 이름과 일치해야 합니다)
                        PipeDirection.InOut, // 양방향 통신
                        PipeOptions.None,    // 추가 파이프 옵션 없음
                        TokenImpersonationLevel.Impersonation); // 클라이언트의 보안 토큰을 서버로 전송하여 가장을 허용합니다.

                Console.WriteLine("서버에 연결 중...\n");
                // 서버에 연결될 때까지 대기합니다.
                pipeClient.Connect();

                var ss = new StreamString(pipeClient);
                // 서버의 서명 문자열("I am the one true server!")을 읽어 유효성을 검사합니다.
                if (ss.ReadString() == "I am the one true server!")
                {
                    // 첫 번째 쓰기 작업과 함께 클라이언트의 보안 토큰이 서버로 전송됩니다.
                    // 서버가 파일 내용을 반환할 파일 이름을 서버로 보냅니다.
                    ss.WriteString("c:\\textfile.txt"); // 서버가 읽을 파일 경로를 지정합니다.

                    // 서버로부터 파일 내용을 읽어 콘솔에 출력합니다.
                    Console.Write(ss.ReadString());
                }
                else
                {
                    Console.WriteLine("서버를 확인할 수 없습니다.");
                }
                // 파이프 클라이언트 스트림을 닫고 리소스를 해제합니다.
                pipeClient.Close();
                // 클라이언트 프로세스가 결과를 표시할 시간을 주기 위해 4초 동안 대기합니다.
                Thread.Sleep(4000);
            }
        }
        else // 'spawnclient' 인수가 없는 경우, 여러 클라이언트 프로세스를 시작합니다.
        {
            Console.WriteLine("\n*** 가장(impersonation) 예제를 포함한 명명된 파이프 클라이언트 스트림 ***\n");
            // 클라이언트 프로세스를 시작하는 헬퍼 함수를 호출합니다.
            StartClients();
        }
    }

    // 파이프 클라이언트 프로세스를 생성하는 헬퍼 함수
    private static void StartClients()
    {
        // 현재 실행 중인 프로세스의 전체 명령줄을 가져옵니다. (예: "C:\path\to\YourApp.exe")
        string currentProcessName = Environment.CommandLine;

        // Visual Studio에서 실행될 때 추가되는 따옴표나 공백을 제거합니다.
        currentProcessName = currentProcessName.Trim('"', ' ');

        // 확장자를 .exe로 변경하여 실행 파일 경로를 확보합니다.
        currentProcessName = Path.ChangeExtension(currentProcessName, ".exe");
        Process?[] plist = new Process?[numClients]; // 생성될 클라이언트 프로세스들을 저장할 배열

        Console.WriteLine("클라이언트 프로세스들을 생성 중...\n");

        // 현재 디렉토리 경로가 명령줄에 포함되어 있다면 제거합니다.
        // 이는 Process.Start가 올바른 실행 파일을 찾도록 돕기 위함입니다.
        if (currentProcessName.Contains(Environment.CurrentDirectory))
        {
            currentProcessName = currentProcessName.Replace(Environment.CurrentDirectory, String.Empty);
        }

        // Visual Studio 실행 시 발생할 수 있는 추가적인 문자(백슬래시, 따옴표)를 제거합니다.
        currentProcessName = currentProcessName.Replace("\\", String.Empty);
        currentProcessName = currentProcessName.Replace("\"", String.Empty);

        int i;
        for (i = 0; i < numClients; i++)
        {
            // '이' 프로그램(PipeClient) 자체를 새 프로세스로 시작하되,
            // 'spawnclient' 인수를 전달하여 명명된 파이프 클라이언트 모드로 실행되도록 합니다.
            plist[i] = Process.Start(currentProcessName, "spawnclient");
        }

        // 모든 클라이언트 프로세스가 종료될 때까지 대기하는 루프
        // 'i'는 아직 종료되지 않은 프로세스의 개수를 추적합니다.
        while (i > 0)
        {
            for (int j = 0; j < numClients; j++)
            {
                if (plist[j] != null) // 프로세스가 아직 활성 상태인 경우
                {
                    // 프로세스가 종료되었는지 확인합니다.
                    if (plist[j]!.HasExited)
                    {
                        Console.WriteLine($"클라이언트 프로세스[{plist[j]?.Id}]가 종료되었습니다.");
                        plist[j] = null; // 종료된 프로세스 참조 제거
                        i--;             // 종료되지 않은 프로세스 개수 감소
                    }
                    else
                    {
                        // 아직 종료되지 않았다면 잠시 대기합니다.
                        Thread.Sleep(250);
                    }
                }
            }
        }
        Console.WriteLine("\n클라이언트 프로세스들이 모두 완료되어 종료합니다.");
    }
}

// 스트림에서 문자열을 읽고 쓰기 위한 데이터 프로토콜을 정의하는 클래스
// (이 클래스는 서버 예제와 동일합니다)
public class StreamString
{
    private Stream ioStream;           // 기본 스트림 (NamedPipeClientStream)
    private UnicodeEncoding streamEncoding; // 문자열 인코딩 방식

    public StreamString(Stream ioStream)
    {
        this.ioStream = ioStream;
        streamEncoding = new UnicodeEncoding(); // UTF-16 인코딩 사용
    }

    // 스트림에서 문자열을 읽습니다.
    public string ReadString()
    {
        // 먼저 문자열의 길이를 2바이트로 읽습니다. (Big-endian 방식으로)
        int len;
        len = ioStream.ReadByte() * 256; // 첫 번째 바이트 (상위 8비트)
        len += ioStream.ReadByte();      // 두 번째 바이트 (하위 8비트)

        // 읽을 길이만큼의 바이트 배열을 생성합니다.
        var inBuffer = new byte[len];
        // 스트림에서 해당 길이만큼의 바이트를 읽어 버퍼에 채웁니다.
        ioStream.Read(inBuffer, 0, len);

        // 바이트 배열을 문자열로 디코딩하여 반환합니다.
        return streamEncoding.GetString(inBuffer);
    }

    // 스트림에 문자열을 씁니다.
    public int WriteString(string outString)
    {
        // 문자열을 바이트 배열로 인코딩합니다.
        byte[] outBuffer = streamEncoding.GetBytes(outString);
        int len = outBuffer.Length;

        // 문자열 길이가 UInt16.MaxValue (65535)를 초과하면 잘라냅니다.
        // (프로토콜이 2바이트 길이 필드를 사용하므로 최대 65535 바이트까지 표현 가능)
        if (len > UInt16.MaxValue)
        {
            len = (int)UInt16.MaxValue;
        }

        // 문자열의 길이를 2바이트로 스트림에 씁니다. (Big-endian 방식으로)
        ioStream.WriteByte((byte)(len / 256)); // 상위 바이트
        ioStream.WriteByte((byte)(len & 255)); // 하위 바이트
        // 문자열 바이트 배열을 스트림에 씁니다.
        ioStream.Write(outBuffer, 0, len);
        // 버퍼에 남아있는 데이터를 즉시 스트림으로 밀어 넣습니다.
        ioStream.Flush();

        // 전송된 총 바이트 수 (문자열 바이트 + 길이 2바이트)를 반환합니다.
        return outBuffer.Length + 2;
    }
}

강력한 프로그래밍: Named Pipe 클라이언트/서버 설정

이 예제에서 클라이언트와 서버 프로세스는 동일한 컴퓨터에서 실행되도록 설계되었습니다.

그래서 NamedPipeClientStream 객체에 제공된 서버 이름이 “.” 입니다.

만약 클라이언트와 서버 프로세스가 다른 컴퓨터에 있다면, “.” 은 서버 프로세스를 실행하는 컴퓨터의 네트워크 이름으로 대체되어야 합니다.

추가 정리

명명된 파이프에 대한 동작 개념

명명된 파이프는 파일 시스템의 ‘이름’이라는 개념을 빌려와 프로세스들이 서로를 찾아 연결할 수 있게 해주지만, 실제 데이터 교환은 메모리를 통해 이루어지는 IPC(프로세스 간 통신) 메커니즘입니다.

이러한 특성 덕분에 명명된 파이프는 로컬 컴퓨터 내의 여러 프로세스 간 통신에 매우 효율적이며, Windows에서는 네트워크를 통해 다른 컴퓨터의 파이프에도 연결할 수 있어 더욱 유연하게 사용할 수 있습니다.

The post .NET의 파이프 작업 (Pipe Operations in .NET) appeared first on 어제와 내일의 나 그 사이의 이야기.

개요

Microsoft.Extensions.Hosting 네임스페이스는 .NET 애플리케이션의 호스팅 모델(Hosting Model)을 제공하는 핵심 구성 요소입니다.

Host 클래스는 이 모델의 시작점 역할을 하며, 애플리케이션의 생명 주기(lifecycle), 구성(configuration), 의존성 주입(dependency injection, DI), 로깅(logging) 등 다양한 인프라 서비스를 중앙 집중식으로 관리합니다.

이 호스팅 모델은 ASP.NET Core 애플리케이션에서 시작되었지만, 현재는 콘솔 애플리케이션, 백그라운드 서비스, Windows 서비스, WPF 애플리케이션 등 다양한 종류의 .NET 애플리케이션에서 표준적인 방식으로 사용되고 있습니다.

1. Host 클래스의 목적과 역할

Host 클래스는 특정 애플리케이션 유형에 구애받지 않고, 공통적인 인프라 기능을 쉽게 통합하고 관리할 수 있도록 설계되었습니다.

• 생명 주기 관리: 애플리케이션의 시작(StartAsync) 및 종료(StopAsync)를 관리하고, 이 과정에서 필요한 서비스들이 올바른 순서로 초기화되고 정리될 수 있도록 합니다.
• 의존성 주입 (DI): 애플리케이션 전반에 걸쳐 강력한 DI 컨테이너를 제공하여, 서비스 간의 느슨한 결합을 촉진하고 테스트 용이성을 향상시킵니다.
• 구성 (Configuration): appsettings.json, 환경 변수, 명령줄 인수 등 다양한 소스에서 설정을 로드하고 관리하는 일관된 방법을 제공합니다.
• 로깅 (Logging): 다양한 로깅 프로바이더(콘솔, 파일, 데이터베이스 등)를 쉽게 통합하고, 로깅 레벨을 유연하게 제어할 수 있도록 합니다.
• 백그라운드 서비스 (IHostedService): 장시간 실행되는 백그라운드 작업을 호스트의 생명 주기에 통합하여 관리할 수 있도록 합니다. 이는 API를 제공하지 않고 단순히 작업을 수행하는 서비스에 특히 유용합니다.

2. Host 클래스 핵심 인터페이스 및 메서드

Host 클래스 자체보다는, 이와 관련된 IHost 및 IHostBuilder 인터페이스를 이해하는 것이 중요합니다.

(1) IHostBuilder 인터페이스

IHostBuilder는 호스트를 구성(Configure)하는 데 사용되는 인터페이스입니다.

Host.CreateDefaultBuilder() 메서드가 반환하는 객체가 바로 IHostBuilder 타입입니다.

이 빌더를 통해 다음을 정의할 수 있습니다:

• ConfigureAppConfiguration:
  설정 소스(파일, 환경 변수 등)를 추가하거나 커스터마이징합니다.

.ConfigureAppConfiguration((context, config) =>
{
    config.AddJsonFile("custom.json", optional: true)
          .AddEnvironmentVariables()
          .AddCommandLine(args);
})

• ConfigureLogging:
  로깅 프로바이더(콘솔, 디버그, 파일 등)를 추가하고 로깅 필터링 규칙을 정의합니다.

.ConfigureLogging((context, logging) =>
{
    logging.AddConsole()
           .AddDebug()
           .SetMinimumLevel(LogLevel.Information);
})

• ConfigureServices:
  의존성 주입 컨테이너에 애플리케이션의 서비스들을 등록합니다.
  AddSingleton, AddScoped, AddTransient 등의 메서드를 사용하여 서비스의 생명 주기를 지정할 수 있습니다.

.ConfigureServices((context, services) =>
{
    services.AddSingleton<ISingletonService, SingletonService>();
    services.AddScoped<IScopedService, ScopedService>();
    services.AddTransient<ITransientService, TransientService>();
    services.AddHostedService<MyBackgroundService>();
})

• UseConsoleLifetime:
  콘솔 애플리케이션의 경우, Ctrl+C와 같은 콘솔 시그널을 감지하여 호스트를 정상적으로 종료하도록 설정합니다.
  (이는 Host.CreateDefaultBuilder()에 의해 기본적으로 포함됩니다.)
• Build():
  IHostBuilder에 정의된 모든 구성을 기반으로 최종 IHost 인스턴스를 생성합니다.

(2) IHost 인터페이스

IHost는 빌드된 호스트 인스턴스를 나타내며, 실제로 애플리케이션을 실행하고 관리하는 데 사용됩니다.

주요 메서드는 다음과 같습니다

• Services:
  등록된 모든 서비스 인스턴스에 접근할 수 있는 IServiceProvider를 제공합니다.
  이를 통해 런타임에 필요한 서비스를 resolve(가져오기)할 수 있습니다.
• StartAsync(CancellationToken cancellationToken):
  호스트를 비동기적으로 시작합니다. 이 메서드가 호출되면 등록된 모든 IHostedService 인스턴스의 StartAsync 메서드가 호출됩니다.
• StopAsync(CancellationToken cancellationToken):
  호스트를 비동기적으로 종료합니다. 등록된 모든 IHostedService 인스턴스의 StopAsync 메서드가 호출되어 리소스를 정리할 기회를 줍니다.
• RunAsync(CancellationToken cancellationToken = default):
  StartAsync를 호출하고, 호스트가 종료될 때까지 대기한 후 StopAsync를 호출합니다.
  대부분의 콘솔 애플리케이션에서 메인 실행 루프로 사용됩니다.

(3) IHostedService 인터페이스

IHostedService는 호스트의 생명 주기에 통합되어 백그라운드 작업을 수행하는 서비스들을 정의하는 인터페이스입니다.

StartAsync와 StopAsync 두 가지 메서드를 구현해야 합니다.

• StartAsync(CancellationToken cancellationToken):
  호스트가 시작될 때 호출됩니다. 장시간 실행되는 작업을 시작하는 데 사용됩니다.
• StopAsync(CancellationToken cancellationToken):
  호스트가 종료될 때 호출됩니다. StartAsync에서 시작된 작업을 정상적으로 중지하고 리소스를 정리하는 데 사용됩니다.

3. Host.CreateDefaultBuilder() 메서드의 이점

이 메서드는 많은 “관습(conventions)”을 제공하여 애플리케이션 초기 설정을 간소화하는 장점이 있습니다.

• 일관성:
  모든 .NET 애플리케이션 유형(웹, 콘솔, 백그라운드 서비스)에서 동일한 방식으로 인프라를 설정할 수 있게 하여 코드의 일관성을 유지합니다.
• 생산성:
  설정, 로깅, DI 등 반복적인 초기화 코드를 작성할 필요 없이 바로 비즈니스 로직에 집중할 수 있도록 합니다.
• 확장성:
  기본 설정을 사용하면서도 ConfigureAppConfiguration, ConfigureServices 등의 메서드를 통해 언제든지 필요에 따라 커스터마이징하고 확장할 수 있습니다.
• 테스트 용이성:
  DI 컨테이너를 중심으로 설계되어, 단위 테스트 및 통합 테스트에서 의존성을 쉽게 Mocking하거나 대체할 수 있습니다.
  참고: Mocking – 테스트 코드 작성 시 가짜 객체(Mock)를 만들어 실제 객체 대신 사용하는 기법

예시 코드: 콘솔 애플리케이션에서 Host 사용하기

콘솔 애플리케이션에서 Host 클래스를 사용하여 백그라운드 서비스(카운터)를 실행하고, 설정 및 로깅을 사용하는 예제

• Microsoft.Extensions.Hosting NuGet 패키지를 설치

dotnet add package Microsoft.Extensions.Hosting

• appsettings.json 파일을 추가하고 내용을 작성합니다.

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AppConfig": {
    "IntervalSeconds": 2
  }
}

• Services/MyBackgroundService.cs (커스텀 IHostedService 구현):

using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Configuration; // IConfiguration 주입을 위해 추가
using System;
using System.Threading;
using System.Threading.Tasks;

namespace MyConsoleApp.Services
{
    // IHostedService를 구현하여 호스트의 생명 주기에 통합될 백그라운드 서비스를 정의합니다.
    public class MyBackgroundService : IHostedService, IDisposable
    {
        private readonly ILogger<MyBackgroundService> _logger;
        private readonly IConfiguration _configuration;
        private Timer? _timer;
        private int _executionCount = 0;
        private int _intervalSeconds;

        public MyBackgroundService(ILogger<MyBackgroundService> logger, IConfiguration configuration)
        {
            _logger = logger;
            _configuration = configuration;

            // appsettings.json에서 설정 값 읽기
            _intervalSeconds = _configuration.GetValue<int>("AppConfig:IntervalSeconds", 5); // 기본값 5초
        }

        // 호스트가 시작될 때 호출됩니다.
        public Task StartAsync(CancellationToken cancellationToken)
        {
            _logger.LogInformation("MyBackgroundService가 시작되었습니다.");

            // 타이머를 설정하여 지정된 간격마다 DoWork 메서드를 호출합니다.
            _timer = new Timer(DoWork, null, TimeSpan.Zero, TimeSpan.FromSeconds(_intervalSeconds));

            return Task.CompletedTask; // 비동기 작업 시작을 알리고 즉시 반환
        }

        // 타이머에 의해 주기적으로 호출되는 실제 작업 메서드
        private void DoWork(object? state)
        {
            var count = Interlocked.Increment(ref _executionCount);
            _logger.LogInformation(
                "MyBackgroundService가 {count}번째 작업을 수행 중입니다. 현재 시간: {time}",
                count, DateTimeOffset.Now);
        }

        // 호스트가 종료될 때 호출됩니다.
        public Task StopAsync(CancellationToken cancellationToken)
        {
            _logger.LogInformation("MyBackgroundService가 중지되고 있습니다.");

            // 타이머를 중지하고 리소스를 해제합니다.
            // Change(Timeout.Infinite, 0)은 타이머를 비활성화하는 표준 방법입니다.
            _timer?.Change(Timeout.Infinite, 0);

            _logger.LogInformation("MyBackgroundService가 중지되었습니다.");
            return Task.CompletedTask; // 작업 완료를 알립니다.
        }

        // 리소스 해제를 위한 Dispose 메서드 (IHostedService는 IDisposable을 구현하는 경우가 많음)
        public void Dispose()
        {
            _timer?.Dispose();
        }
    }
}

• Program.cs 구현:

using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using MyConsoleApp.Services; // MyBackgroundService를 사용하기 위해 추가
using System;
using System.Threading.Tasks;

namespace MyConsoleApp
{
    public class Program
    {
        public static async Task Main(string[] args)
        {
            Console.WriteLine("콘솔 애플리케이션 호스트가 시작됩니다. 종료하려면 Ctrl+C를 누르세요.");

            // 1. IHostBuilder 인스턴스 생성: Host.CreateDefaultBuilder()는 기본적인 구성(config, logging, DI)을 설정합니다.
            var builder = Host.CreateDefaultBuilder(args)
                // 2. 서비스 컨테이너 구성: 의존성 주입을 위한 서비스들을 등록합니다.
                .ConfigureServices((hostContext, services) =>
                {
                    // MyBackgroundService를 IHostedService로 등록합니다.
                    // 호스트가 시작될 때 StartAsync가 호출되고, 종료될 때 StopAsync가 호출됩니다.
                    services.AddHostedService<MyBackgroundService>();

                    // 여기에 다른 서비스들도 등록할 수 있습니다. 예:
                    // services.AddSingleton<IMyService, MyService>();
                    // services.AddScoped<IOtherService, OtherService>();
                })
                // 3. 로깅 구성 (선택 사항: CreateDefaultBuilder가 기본 설정 제공하지만, 커스터마이징 가능)
                .ConfigureLogging(logging =>
                {
                    logging.ClearProviders(); // 기본 로깅 프로바이더를 지우고 새로 추가하거나
                    logging.AddConsole();    // 콘솔 로거를 추가합니다.
                    // logging.AddDebug();    // 디버그 로거 추가
                });
                // 4. 기타 구성 (선택 사항: 파일 경로, 환경 등)
                // .UseContentRoot(Directory.GetCurrentDirectory())
                // .UseEnvironment("Development")
                // .ConfigureAppConfiguration((hostingContext, config) => {
                //    config.AddJsonFile("custom.json", optional: true);
                // });

            // 5. IHost 인스턴스 빌드: 구성된 빌더를 바탕으로 실제 호스트를 생성합니다.
            var host = builder.Build();

            // 6. 호스트 실행: 등록된 모든 IHostedService를 시작하고 애플리케이션 종료를 대기합니다.
            // Ctrl+C 시그널을 감지하여 정상적으로 종료됩니다.
            await host.RunAsync();

            Console.WriteLine("콘솔 애플리케이션 호스트가 종료되었습니다.");
        }
    }
}

The post Microsoft.Extensions.Hosting, 호스팅 모델(Hosting Model) appeared first on 어제와 내일의 나 그 사이의 이야기.

Swagger(스웨거)란 무엇인가?

Swagger는 현재 OpenAPI Specification (OAS)라는 이름으로 표준화된 RESTful API 명세 및 문서화 도구입니다.

2015년 SmartBear Software에서 OpenAPI Initiative에 기증한 후, 현재는 Linux Foundation 산하에서 관리되고 있습니다.

핵심 개념

• API 명세의 표준화: REST API의 엔드포인트, 파라미터, 응답 구조를 JSON/YAML 형식으로 정의
• Code-First 접근: 소스코드로부터 API 문서를 자동 생성하여 문서와 구현 간 불일치 방지
• Interactive Documentation: 브라우저에서 직접 API를 테스트할 수 있는 UI 제공

Swagger가 필요한 이유

1. 개발 생산성 향상

• 자동 문서화: 수동으로 API 문서를 작성하고 유지보수하는 비용 절약
• 실시간 동기화: 코드 변경 시 문서가 자동으로 업데이트
• 타입 안전성: .NET의 강타입 시스템을 활용한 정확한 스키마 생성

2. 팀 협업 효율성

• 프론트엔드-백엔드 협업: 명확한 API 계약 정의를 통한 병렬 개발 지원
• API 계약 테스트: 구현 전 API 설계 검증 가능
• 버전 관리: API 변경사항 추적 및 하위 호환성 관리

3. 운영 및 테스트

• 통합 테스트: CI/CD 파이프라인에서 자동화된 API 테스트
• 모니터링: API 사용 패턴 분석 및 성능 모니터링 기반 제공

Swashbuckle.AspNetCore 아키텍처

Swashbuckle.AspNetCore는 .NET에서 Swagger/OpenAPI를 구현하는 가장 널리 사용되는 라이브러리입니다.

.NET 6+ 프로젝트에서 Swagger 구성

1. 패키지 설치

# Package Manager Console
Install-Package Swashbuckle.AspNetCore

# .NET CLI
dotnet add package Swashbuckle.AspNetCore

2. 기본 구성 (Program.cs)

var builder = WebApplication.CreateBuilder(args);

// 컨트롤러 서비스 등록
builder.Services.AddControllers();

// Swagger 서비스 등록
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen(options =>
{
    options.SwaggerDoc("v1", new OpenApiInfo
    {
        Version = "v1",
        Title = "My API",
        Description = "ASP.NET Core Web API for demonstration",
        Contact = new OpenApiContact
        {
            Name = "Developer Name",
            Email = "developer@example.com"
        }
    });
});

var app = builder.Build();

// 개발 환경에서만 Swagger 활성화
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI(options =>
    {
        options.SwaggerEndpoint("/swagger/v1/swagger.json", "My API V1");
        options.RoutePrefix = string.Empty; // 루트 경로에서 Swagger UI 제공
    });
}

app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

app.Run();

SwaggerGen의 동작 원리

SwaggerGen은 다음과 같은 과정을 통해 OpenAPI 문서를 생성합니다:

1. 어셈블리 스캔: 등록된 컨트롤러와 액션 메서드 탐색
2. 메타데이터 추출: 라우트, HTTP 메서드, 파라미터, 반환 타입 분석
3. 스키마 생성: .NET 타입을 JSON Schema로 변환
4. 문서 조합: OpenAPI 3.0 사양에 맞는 JSON 문서 생성

생성되는 OpenAPI 문서 예시

{
  "openapi": "3.0.1",
  "info": {
    "title": "My API",
    "version": "v1"
  },
  "paths": {
    "/api/products": {
      "get": {
        "tags": ["Products"],
        "summary": "제품 목록 조회",
        "responses": {
          "200": {
            "description": "성공",
            "content": {
              "application/json": {
                "schema": {
                  "type": "array",
                  "items": {
                    "$ref": "#/components/schemas/Product"
                  }
                }
              }
            }
          }
        }
      }
    }
  },
  "components": {
    "schemas": {
      "Product": {
        "type": "object",
        "properties": {
          "id": { "type": "integer", "format": "int32" },
          "name": { "type": "string", "nullable": true }
        }
      }
    }
  }
}

Swagger UI 고급 활용

Swagger UI는 생성된 OpenAPI 문서를 기반으로 다음 기능을 제공합니다:

주요 기능

• HTTP 메서드별 분류: GET, POST, PUT, DELETE 등 시각적 구분
• 스키마 검증: 요청/응답 데이터 구조 실시간 검증
• Try it Out: 브라우저에서 직접 API 호출 및 결과 확인
• 모델 정의: 복잡한 객체 구조의 시각적 표현
• 인증 통합: 다양한 인증 방식 지원 (Bearer, API Key 등)

커스터마이징 옵션

app.UseSwaggerUI(options =>
{
    options.SwaggerEndpoint("/swagger/v1/swagger.json", "My API V1");
    options.DocumentTitle = "My API Documentation";
    options.DefaultModelsExpandDepth(2);
    options.DefaultModelRendering(ModelRendering.Model);
    options.DisplayRequestDuration();
    options.EnableDeepLinking();
    options.EnableFilter();
    options.ShowExtensions();
});

실무 필수 확장 기능

1. XML 주석 통합

프로젝트 파일 설정:

<PropertyGroup>
  <GenerateDocumentationFile>true</GenerateDocumentationFile>
  <NoWarn>$(NoWarn);1591</NoWarn>
</PropertyGroup>

Program.cs 구성:

builder.Services.AddSwaggerGen(options =>
{
    var xmlFilename = $"{Assembly.GetExecutingAssembly().GetName().Name}.xml";
    options.IncludeXmlComments(Path.Combine(AppContext.BaseDirectory, xmlFilename));
    
    // 상속된 XML 주석 포함
    options.IncludeXmlComments(Path.Combine(AppContext.BaseDirectory, "MyModels.xml"));
});

컨트롤러 예시:

/// <summary>
/// 제품 관리 API
/// </summary>
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    /// <summary>
    /// 제품 목록을 조회합니다.
    /// </summary>
    /// <param name="pageSize">페이지당 항목 수 (기본값: 10)</param>
    /// <returns>제품 목록</returns>
    /// <response code="200">성공적으로 조회됨</response>
    /// <response code="400">잘못된 요청 파라미터</response>
    [HttpGet]
    [ProducesResponseType(typeof(IEnumerable<Product>), StatusCodes.Status200OK)]
    [ProducesResponseType(StatusCodes.Status400BadRequest)]
    public async Task<ActionResult<IEnumerable<Product>>> GetProducts(
        [FromQuery] int pageSize = 10)
    {
        // 구현 로직
    }
}

2. JWT Bearer 인증 통합

builder.Services.AddSwaggerGen(options =>
{
    options.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme
    {
        Name = "Authorization",
        Type = SecuritySchemeType.Http,
        Scheme = "Bearer",
        BearerFormat = "JWT",
        In = ParameterLocation.Header,
        Description = "JWT Authorization header using the Bearer scheme. Example: \"Authorization: Bearer {token}\""
    });

    options.AddSecurityRequirement(new OpenApiSecurityRequirement
    {
        {
            new OpenApiSecurityScheme
            {
                Reference = new OpenApiReference
                {
                    Type = ReferenceType.SecurityScheme,
                    Id = "Bearer"
                }
            },
            Array.Empty<string>()
        }
    });
});

3. API 버전 관리

패키지 설치:

dotnet add package Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer

구성:

builder.Services.AddApiVersioning(options =>
{
    options.DefaultApiVersion = new ApiVersion(1, 0);
    options.AssumeDefaultVersionWhenUnspecified = true;
    options.ApiVersionReader = ApiVersionReader.Combine(
        new UrlSegmentApiVersionReader(),
        new HeaderApiVersionReader("X-Version"),
        new MediaTypeApiVersionReader("ver"));
});

builder.Services.AddVersionedApiExplorer(setup =>
{
    setup.GroupNameFormat = "'v'VVV";
    setup.SubstituteApiVersionInUrl = true;
});

builder.Services.AddSwaggerGen();
builder.Services.ConfigureOptions<ConfigureSwaggerOptions>();

4. 사용자 정의 스키마 필터

public class EnumSchemaFilter : ISchemaFilter
{
    public void Apply(OpenApiSchema schema, SchemaFilterContext context)
    {
        if (context.Type.IsEnum)
        {
            schema.Enum.Clear();
            Enum.GetNames(context.Type)
                .ToList()
                .ForEach(name => schema.Enum.Add(new OpenApiString(name)));
        }
    }
}

// 등록
builder.Services.AddSwaggerGen(options =>
{
    options.SchemaFilter<EnumSchemaFilter>();
});

성능 최적화 및 모범 사례

1. 프로덕션 환경 고려사항

// 조건부 Swagger 활성화
if (app.Environment.IsDevelopment() || app.Environment.IsStaging())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

// 또는 구성 기반 활성화
if (builder.Configuration.GetValue<bool>("EnableSwagger"))
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

2. 대용량 API 문서 최적화

builder.Services.AddSwaggerGen(options =>
{
    // 불필요한 스키마 제외
    options.SchemaFilter<ExcludeInternalTypesFilter>();
    
    // 문서 압축
    options.EnableAnnotations();
    
    // 메모리 사용량 최적화
    options.UseAllOfToExtendReferenceSchemas();
    options.UseOneOfForPolymorphism();
});

3. 보안 강화

app.UseSwagger(options =>
{
    // JSON 문서 접근 제한
    options.PreSerializeFilters.Add((swagger, httpReq) =>
    {
        if (!httpReq.Headers.ContainsKey("X-API-Key"))
        {
            throw new UnauthorizedAccessException();
        }
    });
});

트러블슈팅 가이드

일반적인 문제와 해결책

모니터링 및 분석

Application Insights 통합

builder.Services.AddApplicationInsightsTelemetry();

// Swagger 사용량 추적
app.UseSwagger(options =>
{
    options.PreSerializeFilters.Add((swagger, httpReq) =>
    {
        var telemetryClient = httpReq.HttpContext.RequestServices
            .GetRequiredService<TelemetryClient>();
        telemetryClient.TrackEvent("SwaggerAccessed");
    });
});

요약 및 베스트 프랙티스

핵심 도구 정리

개발팀을 위한 권장사항

1. 개발 초기부터 Swagger 도입하여 API 설계 단계에서 문서화
2. XML 주석을 활용한 상세한 API 설명 작성
3. DTO 패턴 적용으로 명확한 API 계약 정의
4. 버전 관리 전략 수립으로 하위 호환성 보장
5. 보안 설정 통합으로 실제 운영 환경과 일치하는 테스트 환경 구축
6. CI/CD 파이프라인에 OpenAPI 스펙 검증 단계 포함

이러한 접근을 통해 Swagger/OpenAPI는 단순한 문서화 도구를 넘어서 API 개발 생명주기 전반을 지원하는 핵심 인프라가 될 수 있습니다.

The post Swagger/OpenAPI for .NET appeared first on 어제와 내일의 나 그 사이의 이야기.

1. 개요

C# 애플리케이션이 소스 코드에서 실행 가능한 프로그램으로 변환되는 과정은 여러 단계로 이루어져 있습니다.

C# 컴파일러, 중간 언어(IL), 어셈블리(DLL, EXE), JIT 컴파일러 간의 관계와 전체 실행 흐름을 설명합니다.

2. 전체 실행 흐름

C# 소스 코드 → C# 컴파일러(Roslyn) → IL 코드 포함 DLL/EXE → CLR 로딩 → JIT 컴파일러 → 네이티브 머신 코드 → CPU 실행

3. C# 컴파일러 (로슬린 – Roslyn)

역할

• C# 소스 코드(.cs 파일)를 중간 언어(IL, Intermediate Language)로 변환

특징

• Microsoft의 오픈 소스 컴파일러 플랫폼
• csc.exe로 실행되거나 dotnet build 명령어 실행 시 자동 호출
• 어휘 분석, 구문 분석, 의미 분석, IL 생성의 단계적 작업 수행
• 주요 최적화는 JIT 컴파일 단계로 미루어짐

컴파일러 파이프라인 구성요소

• Syntax Tree API: 소스 코드의 구문적 구조 표현
• Semantic Model API: 코드의 의미론적 정보 제공
• Compilation API: 컴파일 과정 제어
• Workspace API: 솔루션, 프로젝트, 문서 등 작업 환경 관리

C# 코드 예시

public class Program 
{
    public static void Main() 
    {
        Console.WriteLine("Hello, World!");
    }
}

4. 중간 언어 (IL, Intermediate Language)

특징

• CPU 아키텍처에 독립적인 저수준 언어
• .dll 또는 .exe 파일 내에 포함됨
• 인간이 읽을 수 있는 형태(ILASM)로도 표현 가능
• CLR(공통 언어 런타임)이 이해하는 언어
• 스택 기반 명령어 집합으로 구성

주요 특성

• 스택 기반 명령어 집합: 주로 스택을 사용하여 연산 수행
• 객체 지향 지원: 클래스, 상속, 가상 메서드 등 지원
• 타입 안전성: 강력한 타입 시스템 유지
• 메타데이터 통합: 코드와 메타데이터가 밀접하게 연결

IL 코드 예시

// 위 C# 코드의 IL 표현 (간략화)
.method public hidebysig static void Main() cil managed {
  .entrypoint
  ldstr "Hello, World!"
  call void [System.Console]System.Console::WriteLine(string)
  ret
}

5. DLL과 EXE 파일 (어셈블리)

공통점

• 모두 PE(Portable Executable) 형식의 파일
• 메타데이터(형식 정보)와 IL 코드 포함
• .NET 어셈블리로서 버전 관리, 보안 정보 등 포함

차이점

어셈블리 구성요소

• 매니페스트: 어셈블리 ID, 버전, 문화권, 강력한 이름 등의 정보
• 타입 메타데이터: 클래스, 메서드, 프로퍼티 등의 정보
• IL 코드: 실행 가능한 중간 언어 코드
• 리소스: 이미지, 문자열 등 포함 가능

6. CLR(공통 언어 런타임)

역할

• .NET 애플리케이션의 실행 환경 제공
• 메모리 관리, 보안, 예외 처리 등 다양한 서비스 제공

주요 구성요소

• 클래스 로더: 필요한 타입을 메모리에 로드
• JIT 컴파일러: IL을 네이티브 코드로 변환
• 가비지 컬렉터: 자동 메모리 관리
• 보안 시스템: 코드 접근 보안(CAS) 등 제공
• 스레드 관리: 다중 스레드 실행 지원
• 예외 처리기: 예외 발생 및 처리 관리

7. JIT 컴파일러 (Just-In-Time)

역할

• IL 코드를 네이티브 머신 코드로 변환
• 실행 시점에 최적화 수행

작동 과정

1. 애플리케이션 실행 시 CLR 로드
2. 메서드 첫 호출 시 해당 IL 코드 JIT 컴파일
3. 컴파일된 네이티브 코드 캐싱 (재사용)
4. 실제 CPU에서 실행

최적화 기법

• 인라인 확장: 작은 메서드를 호출 위치에 직접 삽입
• 가상 메서드 최적화: 런타임 시 실제 타입 기반 최적화
• 루프 최적화: 루프 언롤링, 벡터화 등
• 불필요한 경계 검사 제거: 배열 접근 최적화
• 상수 폴딩: 컴파일 시점에 상수 표현식 계산
• 티어드 컴파일: 처음에는 빠르게 컴파일된 덜 최적화된 코드 실행, 후에 더 최적화된 버전으로 대체

8. 상세 실행 흐름

1. C# 소스 코드 작성
   • 개발자가 .cs 파일에 C# 코드 작성
2. C# 컴파일러(Roslyn) 처리
   • 어휘 분석(Lexical Analysis): 소스 코드를 토큰으로 분리
   • 구문 분석(Syntax Analysis): 토큰을 구문 트리로 구성
   • 의미 분석(Semantic Analysis): 타입 체킹, 타입 추론 등
   • IL 코드 생성: 컴파일된 중간 언어(IL) 생성
   • 메타데이터 생성: 타입 정보, 어셈블리 참조 등 생성
3. 어셈블리 생성
   • 컴파일된 IL 코드와 메타데이터가 PE(Portable Executable) 형식의 파일(.dll 또는 .exe)로 패키징
   • 어셈블리 매니페스트 포함: 버전, 문화권, 강력한 이름 등의 정보
4. 애플리케이션 실행
   • .exe 파일 실행시 CLR(공통 언어 런타임) 호스트(예: CoreCLR)가 로드됨
   • CLR은 메타데이터를 읽고 필요한 어셈블리 로드
5. JIT 컴파일
   • 메서드가 처음 호출될 때 JIT 컴파일러가 해당 메서드의 IL 코드를 네이티브 코드로 변환
   • 티어드 컴파일 적용 시 점진적 최적화
6. 실행
   • 생성된 네이티브 코드가 CPU에서 직접 실행
   • 가비지 컬렉션, 예외 처리 등 CLR 서비스가 실행 중 관리

9. 코드 변환 예시

C# 코드

public static int AddNumbers(int a, int b) {
    return a + b;
}

변환된 IL 코드

.method public static int32 AddNumbers(int32 a, int32 b) cil managed {
    .maxstack 2
    ldarg.0     // a를 스택에 로드
    ldarg.1     // b를 스택에 로드
    add         // 스택의 두 값을 더함
    ret         // 결과 반환
}

x86-64 네이티브 코드 (JIT 컴파일 후)

mov eax, ecx    ; 첫 번째 인수(a)를 eax로 이동
add eax, edx    ; 두 번째 인수(b)를 더함
ret             ; 결과(eax에 저장됨) 반환

10. 추가 정보

AOT(Ahead-of-Time) 컴파일

• JIT 대신 미리 네이티브 코드로 컴파일하는 방식
• 초기 시작 시간 단축 및 메모리 사용량 감소
• 모바일/임베디드 환경에 적합
• 일부 동적 기능 제한 (리플렉션 등)
• .NET 6 이상에서 Native AOT 지원

티어드 컴파일(Tiered Compilation)

• 처음에는 빠른 컴파일 우선으로 덜 최적화된 코드 생성
• 자주 사용되는 메서드는 백그라운드에서 더 많은 최적화 적용
• 시작 시간과 장기 실행 성능 사이의 균형 제공

11. 결론

.NET의 컴파일 및 실행 모델은 플랫폼 독립성과 성능 사이의 균형을 효과적으로 맞추고 있습니다.

C# 소스 코드가 Roslyn 컴파일러를 통해 IL로 변환되고, 이후 JIT 컴파일러에 의해 필요할 때 네이티브 코드로 변환되는 과정은 다양한 플랫폼에서의 실행을 가능하게 하면서도 최적화된 성능을 제공합니다.

최근 버전의 .NET에서는 AOT 컴파일, 티어드 컴파일 등 더 다양한 최적화 기법을 도입하여 성능을 더욱 향상시키고 있으며, 이는 클라우드 네이티브 애플리케이션과 마이크로서비스 아키텍처에서 특히 중요한 역할을 합니다.

The post .NET / C# Compiler, IL, DLL, EXE, JIT appeared first on 어제와 내일의 나 그 사이의 이야기.

Dependency Inversion Principle(DIP, 의존성 역전 원리)

https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles#dependency-inversion

The direction of dependency within the application should be in the direction of abstraction, not implementation details.
애플리케이션 내의 종속성 방향은 구현 세부 사항이 아닌 추상화 방향이어야 합니다.
Most applications are written such that compile-time dependency flows in the direction of runtime execution, producing a direct dependency graph.
대부분의 애플리케이션은 컴파일 타임 종속성이 런타임 실행 방향으로 흐르도록 작성되어 직접적인 종속성 그래프를 생성합니다.

That is, if class A calls a method of class B and class B calls a method of class C, then at compile time class A will depend on class B, and class B will depend on class C.
즉, class A가 class B의 메서드를 호출하고 class B가 class C의 메서드를 호출하는 경우 컴파일 타임에 class A는 class B에 종속되고 class B는 class C에 종속됩니다.

코드 구조에서 세부 구현 내용에 의존하지 말고, 더 추상적이고 일반적인 개념에 의존해야 한다는 뜻
이렇게 하면 코드가 더 유연해지고, 변경하기 쉽고, 재사용하기도 쉬워진다.
예를 들어, 어떤 기능을 직접 호출하는 것보다 그 기능을 일반적으로 설명하는 인터페이스를 사용하는 것이 더 좋다는 의미)

Applying the dependency inversion principle allows A to call methods on an abstraction that B implements, making it possible for A to call B at run time, but for B to depend on an interface controlled by A at compile time (thus, inverting the typical compile-time dependency).
종속성 반전 원칙을 적용하면 A가 B가 구현하는 추상화에 대한 메서드를 호출할 수 있으므로 A가 런타임에 B를 호출할 수 있지만 B는 컴파일 타임에 A에 의해 제어되는 인터페이스에 의존할 수 있습니다
(따라서 일반적인 컴파일 타임 종속성을 반전시킵니다). 

At run time, the flow of program execution remains unchanged, but the introduction of interfaces means that different implementations of these interfaces can easily be plugged in.
런타임에 프로그램 실행의 흐름은 변경되지 않지만 인터페이스의 도입은 이러한 인터페이스의 다른 구현을 쉽게 연결할 수 있음을 의미합니다.

Dependency inversion is a key part of building loosely coupled applications, since implementation details can be written to depend on and implement higher-level abstractions, rather than the other way around.
종속성 반전은 느슨하게 결합된 애플리케이션을 구축하는 데 있어 중요한 부분인데, 그 이유는 구현 세부 정보를 작성하여 더 높은 수준의 추상화에 의존하고 구현하도록 할 수 있기 때문입니다.

The resulting applications are more testable, modular, and maintainable as a result.
그 결과 응용 프로그램은 더 쉽게 테스트할 수 있고, 모듈화되며, 유지 관리가 더 용이합니다. 

The practice of dependency injection is made possible by following the dependency inversion principle.
종속성 주입의 연습은 종속성 반전 원칙을 따름으로써 가능합니다.

애플리케이션의 의존성을 구체적인 구현이 아니라 추상화된 개념에 맞추는 것

대부분의 애플리케이션은 A 클래스가 B 클래스를, B 클래스가 C 클래스를 호출하는 형태로 작성됩니다.

이는 A가 B에, B가 C에 의존하게 만든다는 뜻입니다. 종속성 반전 원칙을 적용하면 A는 B의 구체적인 구현이 아니라 B가 구현하는 추상 개념에 의존하게 됩니다.

이렇게 하면 코드를 더 쉽게 테스트할 수 있고, 변경 및 유지보수가 용이해집니다.

간단히 말해, 코드를 유연하고 재사용 가능하게 만들어줍니다.

종속성 반전 적용 전

// 엔진 클래스
public class Engine
{
    public void Start()
    {
        Console.WriteLine("Engine starts.");
    }
}

// 자동차 클래스
public class Car
{
    private Engine _engine = new Engine();

    public void Start()
    {
        _engine.Start();
        Console.WriteLine("Car starts.");
    }
}

// 메인 프로그램
public class Program
{
    public static void Main(string[] args)
    {
        Car car = new Car();
        car.Start();
    }
}

종속성 반전 적용 후

// 인터페이스 정의
public interface IEngine
{
    void Start();
}

// 엔진 클래스
public class Engine : IEngine
{
    public void Start()
    {
        Console.WriteLine("Engine starts.");
    }
}

// 전기 엔진 클래스
public class ElectricEngine : IEngine
{
    public void Start()
    {
        Console.WriteLine("Electric engine starts.");
    }
}

// 자동차 클래스
public class Car
{
    private IEngine _engine;

    public Car(IEngine engine)
    {
        _engine = engine;
    }

    public void Start()
    {
        _engine.Start();
        Console.WriteLine("Car starts.");
    }
}

// 메인 프로그램
public class Program
{
    public static void Main(string[] args)
    {
        IEngine engine = new Engine();
        Car car = new Car(engine);
        car.Start();
        
        IEngine electricEngine = new ElectricEngine();
        Car electricCar = new Car(electricEngine);
        electricCar.Start();
    }
}

The post Dependency Inversion Principle(DIP, 의존성 역전 원리) appeared first on 어제와 내일의 나 그 사이의 이야기.

https://azure.microsoft.com/ko-kr

The post Deploying ASP.NET Web API To Azure appeared first on 어제와 내일의 나 그 사이의 이야기.