shell + base64 

echo -n "${APP_KEY}:${APP_SECRET}" | base64
read more

OAuth Grant Type란?

OAuth Grant Type란?

OAuth 2.0의 Grant Type(권한 부여 유형)은 클라이언트가 인증 서버로부터 액세스 토큰을 받기 위해 사용하는 인증 및 권한 위임 방식입니다. 각각의 Grant Type은 다양한 환경(웹, 모바일, 서버 등)과 보안 요구사항에 맞춰 설계되어 있으며, 각 방식마다 인증 절차와 필요한 정보가 다릅니다123.

주요 OAuth 2.0 Grant Type 종류

Grant Type 특징 및 사용 환경 주요 용도
Authorization Code 서버사이드(웹) 애플리케이션, 가장 안전 사용자가 브라우저에서 인증 후, 클라이언트가 받은 코드를 서버에서 토큰으로 교환245
PKCE (Proof Key for Code Exchange) 모바일/SPA 등 공개 클라이언트, Authorization Code 보안 강화 코드 탈취 방지, 추가 검증값(code verifier/challenge) 사용24
Implicit (Deprecated) SPA, 모바일 등 클라이언트 사이드 토큰을 브라우저로 직접 반환, 보안 취약해 OAuth 2.1에서 폐기 예정245
Resource Owner Password Credentials (Deprecated) 신뢰할 수 있는 앱(내부), 보안 취약 사용자의 ID/PW를 직접 받아 토큰 발급, 외부 앱에는 권장하지 않음24
Client Credentials 서버 간 통신, 사용자 개입 없음 클라이언트의 ID/Secret만으로 토큰 발급, 서버-서버, 데몬 등245
Device Code 입력장치 제한된 디바이스(스마트TV 등) 별도 기기에서 인증 후 디바이스에 토큰 발급5
Refresh Token Access Token 재발급 Access Token 만료 시 재인증 없이 새 토큰 발급, Authorization Code/Password 방식에서 주로 사용24

각 Grant Type의 간단 설명

1. Authorization Code Grant

read more

gcp + apigee + attach 

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
echo "PROJECT_ID=${PROJECT_ID}"

export INSTANCE_NAME=eval-instance
export ENV_NAME=eval
export PREV_INSTANCE_STATE=

echo "waiting for runtime instance ${INSTANCE_NAME} to be active"

while : ; do
  export INSTANCE_STATE=$(
    curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/instances/${INSTANCE_NAME}" |
      jq "select(.state != null) | .state" --raw-output
  )

  [[ "${INSTANCE_STATE}" == "${PREV_INSTANCE_STATE}" ]] || (
    echo
    echo "INSTANCE_STATE=${INSTANCE_STATE}"
  )

  export PREV_INSTANCE_STATE=${INSTANCE_STATE}

  [[ "${INSTANCE_STATE}" != "ACTIVE" ]] || break

  echo -n "."
  sleep 5
done

echo
echo "instance created, waiting for environment ${ENV_NAME} to be attached to instance"

while : ; do
  export ATTACHMENT_DONE=$(
    curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/instances/${INSTANCE_NAME}/attachments" |
      jq "select(.attachments != null) | .attachments[] | select(.environment == \"${ENV_NAME}\") | .environment" --join-output
  )

  [[ "${ATTACHMENT_DONE}" != "${ENV_NAME}" ]] || break

  echo -n "."
  sleep 5
done

echo "***ORG IS READY TO USE***"

apigee를 테스트해 보면서 제일 적응 안 되는 부분이 인스턴스를 붙이는 부분이라고 생각된다.

read more

GCP + apigee + debug

1
apigee debug

GCP apigee 세션을 진행하다보니 각 호출에 대해 디버깅 할 수 있는 Step이 있어 기록으로 남겨본다.

read more

REST 응답에 meta data를 포함하는 것

1
rest 응답에 메타정보를 포함하는 방식

REST API 설계의 기본이라는 동영상을 보다보니, 데이터 이외에 메타정보를 포함하는 내용이 나온다.

REST를 구성하면서 한 번도 생각해 본적이 없는 것이라 살짝 당혹스럽다.

물론 차세대라고 불리는 SI 할 때는 응답전문에 복수의 배열이 포함될수 있음으로 배열명과 동일한 _변수를 반드시 선언하는 식으로 많이들 하긴 했었다만.

이것을 좀더 나이스한 메타정보로 어찌해 볼 생각은 왜 못했을까 싶다.

1
GET, POST의 용법에 대해서도 다시 생각한다

물론 기본은 기본이지만 나는 대부분 GET과 POST로 모든것을 다 처리하고 있었는데 말이다.

read more

http에서 Cache-Control 설명

Cache-Control 설명

Cache-Control은 HTTP/1.1에서 도입된 표준 헤더로, 브라우저, 프록시 서버 등 다양한 캐시 주체가 리소스를 어떻게 저장하고 재사용할지 제어하는 역할을 합니다. 이 헤더는 요청(request)과 응답(response) 모두에서 사용되며, 웹 리소스의 캐싱 정책을 세밀하게 지정할 수 있습니다123.

주요 Cache-Control 지시어

  • max-age=초 리소스가 캐시에 저장될 수 있는 최대 시간을 초 단위로 지정합니다. 예를 들어, Cache-Control: max-age=120은 120초 동안 캐시가 유효함을 의미합니다145.
  • no-cache 캐시에 저장은 가능하지만, 실제로 사용하기 전에 반드시 원 서버에 유효성 검사를 해야 합니다. 즉, 매번 서버에 변경 여부를 확인합니다162.
  • no-store 어떤 캐시에도 저장하지 않음을 의미합니다. 민감한 정보나 보안이 중요한 데이터에 주로 사용됩니다162.
  • public 모든 캐시(브라우저, 프록시 등)에 저장할 수 있음을 나타냅니다. 인증이 필요한 응답도 캐시할 수 있게 허용합니다12.
  • private 오직 개인 사용자(브라우저) 캐시에만 저장할 수 있고, 프록시와 같은 공유 캐시에는 저장하지 않습니다. 기본값이 private인 경우가 많습니다12.
  • s-maxage=초 프록시(공유 캐시)에만 적용되는 max-age 값입니다. 개인 캐시에는 영향을 주지 않습니다1.

동작 예시

read more

SAML이란?

SAML이란?

**SAML(Security Assertion Markup Language)**은 XML 기반의 개방형 표준 프로토콜로, 서로 다른 시스템 간에 사용자 인증 및 권한 부여 정보를 안전하게 교환할 수 있도록 설계되었습니다123. SAML은 주로 기업 환경에서 싱글 사인온(SSO, Single Sign-On) 구현에 널리 사용되며, 사용자가 한 번만 로그인하면 다양한 웹 애플리케이션이나 서비스에 반복 로그인 없이 접근할 수 있게 해줍니다456.

주요 구성 요소

  • ID 공급자(IdP, Identity Provider): 사용자의 신원을 인증하고, 인증 정보를 서비스 공급자에게 전달하는 역할을 합니다126.
  • 서비스 공급자(SP, Service Provider): 사용자가 접근하려는 웹 애플리케이션이나 서비스로, IdP로부터 받은 인증 정보를 바탕으로 접근 권한을 부여합니다126.

동작 원리

  1. 사용자가 서비스 공급자(SP)에 접근을 시도합니다.
  2. SP는 사용자를 ID 공급자(IdP)로 리디렉션하여 인증을 요청합니다.
  3. 사용자가 IdP에서 로그인하면, IdP는 인증된 사용자 정보를 SAML 어설션(assertion) 형태의 XML 문서로 SP에 전달합니다7.
  4. SP는 이 어설션을 검증한 후 사용자의 접근을 허가합니다891.

이 과정에서 사용자는 여러 서비스에 반복적으로 로그인할 필요 없이 한 번의 인증만으로 다양한 리소스에 접근할 수 있습니다.

read more

go 바이너리에 frontend를 포함시키는 방법

filebrowser를 fork해서 뭔가 수정을 좀 해보려고 하는데, 포함된 front를 막연하게 build하고 go runtime에서 해당 dist 폴더를 참조하는 줄 알았더니, go 바이너리에 아예 포함시키나 보다.

[filebrowser_tag_editor]$ mv frontend frontend.back
[filebrowser_tag_editor]$ rm filebrowser
[filebrowser_tag_editor]$ go build
cmd/root.go:26:2: no required module provides package github.com/filebrowser/filebrowser/v2/frontend; to add it:
        go get github.com/filebrowser/filebrowser/v2/frontend

혹시나 하는 마음에 frontend를 아예 없애버리고 buid를 했더니, 정확하게 메시지를 보여준다.

read more

rocky + SELinux 

setenforce 0
restorecon -v /usr/local/toy_redis_to_posgres/toy_redis_to_postgres
setenforce 1
read more

minikube + podman

발단은 OpenFaaS라는 녀석을 써볼까 싶어 시작 한 것인데. 이 녀석이 k8s를 필요로 하고, 두 가지 방법이 권장된다.

k8s 혹은 docker swarm.

나는 podman에 치중하고 있음으로, 당연 swarm이 있을리 없고, 단일 컴퓨트를 사용하고 있기 때문에, k8s도 가지고 있지 않다.

궁여지책으로 minikube를 생각했더니, 이론상으로는 되는데, 현실적인 문제에 직면하는 것 같다.

Minikube에서 “The ‘podman’ driver should not be used with root privileges"라는 메시지가 나타나는 이유는, Podman 드라이버가 root 권한이 아닌 일반 사용자(rootless)로 실행되는 것이 보안상 권장되기 때문입니다. Podman은 기본적으로 rootless(비루트) 컨테이너 실행을 지향하며, root 권한으로 실행할 경우 보안 위험이 커질 수 있습니다.

read more