G7 통합 소셜 로그인 플러그인 - Glitter Social Login

네이버 · 카카오 · 구글 · 페이스북 · GitHub 소셜 로그인을 Gnuboard7에 통합하고, 회원가입부터 기존 회원 연동, 마이페이지 계정 관리, Provider 표시 순서까지 관리할 수 있는 소셜 로그인 플러그인입니다.

소개

Glitter Social Login은 Gnuboard7에서 Naver, Kakao, Google, Facebook, GitHub OAuth 로그인을 사용할 수 있도록 하는 플러그인입니다.

단순히 로그인 화면에 소셜 로그인 버튼을 추가하는 데 그치지 않고 다음 흐름을 함께 제공합니다.

• 소셜 계정을 이용한 로그인 및 회원가입
• Provider별 정책을 적용한 기존 Gnuboard7 회원과의 조건부 자동 연동
• 마이페이지에서 소셜 계정 직접 연결 및 연결 해제
• 관리자에서 Provider별 활성화 및 OAuth Credential 설정
• 로그인·회원가입·마이페이지의 Provider 표시 순서 관리
• 한국어·영어 UI
• Provider별 로컬 브랜드 아이콘

현재 버전은 1.5.1이며, manifest 기준 Gnuboard7 7.0.11 이상, Composer 기준 **PHP 8.2 이상 (^8.2)**을 대상으로 합니다.

지원 Provider

소셜 계정의 기본 identity는 이메일이 아니라 (provider, provider_user_id) 조합입니다.

같은 이메일 주소를 사용하더라도 Provider와 Provider User ID가 다르면 별개의 소셜 identity로 취급합니다. 이미 다른 회원에게 연결된 동일 social identity를 다시 연결하는 것도 허용하지 않습니다.

로그인과 소셜 회원가입

사용자가 소셜 로그인 버튼을 선택하면 해당 Provider의 OAuth 인증을 거쳐 계정을 확인합니다.

이미 (provider, provider_user_id)가 연결된 소셜 계정이라면 연결된 Gnuboard7 회원의 상태와 잠금 여부 등을 확인한 뒤 로그인 흐름을 진행합니다. 연결된 계정이 없다면 Provider별 이메일 정책과 기존 Gnuboard7 회원의 이메일 인증 상태를 확인합니다.

조건을 충족하는 기존 회원이 발견되면 해당 회원과 social identity를 연결할 수 있습니다. 연결 가능한 기존 회원이 없다면 OAuth callback에서 즉시 회원을 생성하지 않고 pending Social Registration으로 이동합니다.

신규 가입 과정에서는 필요한 회원 정보를 확인하고 이용약관 및 개인정보 처리 동의를 별도로 받습니다. OAuth Provider에 대한 동의가 Gnuboard7 회원가입 동의를 대신하지 않습니다.

Provider에서 가입에 사용할 수 있는 이메일을 얻지 못한 경우에도 가입 흐름은 계속할 수 있지만, 최종 회원가입에는 유효한 이메일 입력이 필요합니다. 따라서 이메일 없이 최종 회원가입을 완료하는 구조는 아닙니다.

같은 이메일이라고 무조건 계정을 합치지 않습니다

소셜 로그인에서 이메일 주소는 Provider마다 신뢰할 수 있는 조건이 서로 다릅니다.

Glitter Social Login은 모든 Provider를 동일하게 취급하지 않고 Provider별 이메일 정책을 적용합니다.

Naver

Naver는 플러그인 자체 NaverProvider를 통해 연동합니다.

OAuth profile의 response.id를 social identity에 사용하며, 이메일은 정상적인 Naver profile 응답과 유효한 이메일 형식 등 필요한 조건을 확인한 경우 기존 회원 매칭에 사용할 수 있습니다.

Naver에는 Google의 email_verified와 동일한 필드가 없으므로 이를 임의로 동일하게 해석하지 않습니다.

Kakao

Kakao 이메일을 기존 회원 매칭에 사용하려면 다음 조건을 모두 만족해야 합니다.

• is_email_valid === true
• is_email_verified === true

따라서 Kakao 계정에 이메일 주소가 존재한다는 이유만으로 기존 회원과 자동 연결하지 않습니다.

Google

Google은 Laravel Socialite의 Google Provider를 사용합니다.

기존 회원 이메일 매칭에는 email_verified 조건을 확인합니다.

Facebook

Facebook은 Laravel Socialite의 Facebook Provider를 사용합니다.

현재 Facebook 이메일은 기존 회원 자동 이메일 매칭에 사용하지 않습니다.

이미 연결된 Facebook 계정은 Provider User ID를 기준으로 기존 회원을 찾아 로그인합니다.

GitHub

GitHub는 Laravel Socialite의 GitHub Provider를 사용하며 user:email scope를 통해 이메일 정보를 조회합니다.

기존 회원 매칭에는 primary이면서 verified인 이메일을 사용합니다.

이 조건을 만족하는 이메일을 얻지 못하면 자동 기존 회원 매칭에 사용하지 않으며, 신규 가입을 진행하려면 pending registration에서 유효한 이메일을 입력해야 합니다.

기존 Gnuboard7 회원 측 조건

Provider 쪽 이메일 조건을 통과하는 것만으로는 충분하지 않습니다.

기존 Gnuboard7 회원과 자동 연동하려면 기존 회원의 이메일도 인증된 상태여야 합니다.

이메일 주소가 같으면 무조건 기존 계정과 합치는 것이 아니라, Provider별 이메일 검증 조건과 기존 회원의 이메일 인증 상태를 함께 확인합니다.

로그인 완료와 1회용 Exchange

1.5.1에서는 OAuth callback 이후 최종 로그인 토큰을 URL query에 직접 전달하지 않습니다.

대신 짧은 수명의 1회용 exchange code를 사용합니다.

• exchange code의 유효시간은 60초입니다.
• DB에는 raw code 자체가 아니라 SHA-256 hash를 저장합니다.
• OAuth를 시작한 브라우저 session과 exchange를 결합합니다.
• 소비되지 않았고 만료되지 않은 exchange만 사용할 수 있습니다.
• 조건부 1회 소비 방식으로 재사용을 방지합니다.
• 다른 session에서 가져온 exchange code의 사용을 허용하지 않도록 검증합니다.
• 최종 exchange 단계에서 회원의 활성 상태와 잠금 상태 등을 다시 확인합니다.

즉 URL에는 최종 bearer token 대신 짧은 수명의 opaque exchange code만 전달되고, 실제 bearer token은 exchange가 정상적으로 소비된 뒤 발급됩니다.

이 구조는 OAuth state 검증과 별개입니다. OAuth state는 Socialite의 session 기반 검증을 사용하며, exchange session binding은 callback 이후 최종 로그인 교환을 위한 추가 경계입니다.

로그인 가능 상태 확인

소셜 계정이 연결되어 있다는 사실만으로 즉시 로그인 토큰을 발급하지 않습니다.

현재 1.5.1 구현에서는 로그인 과정에서 회원이 Active 상태인지, 계정이 잠겨 있지 않은지 확인하며, 최종 exchange 단계에서도 회원을 다시 조회해 조건을 재검사합니다.

이 검사는 소셜 로그인 경로에 필요한 fail-closed 경계를 두기 위한 것이며, Gnuboard7의 일반 비밀번호 로그인 lifecycle 전체와 완전히 동일하다는 의미는 아닙니다.

2FA 및 본인확인 관련 현재 범위

Glitter Social Login은 Gnuboard7의 public IdentityVerificationService를 이용하는 본인확인 경로를 포함합니다.

신규 가입에서 signup-before-submit 정책을 사용하는 경우에는 Signup purpose의 본인확인을 거쳐 가입을 진행할 수 있습니다.

다만 현재 1.5.1 소스에는 다음 제한이 있습니다.

• signup-after-create 정책이 필요한 신규 Social User 생성은 fail-closed합니다.
• 전역 2FA가 활성화된 상태에서 신규 Social User 생성은 fail-closed합니다.
• 기존 2FA 계정의 소셜 로그인은 challenge 완료 후에도 최종 exchange에서 추가 인증 필요 여부를 다시 검사하는 현재 구현 때문에 로그인 완료까지 이어지지 않는 제한이 있습니다.

따라서 현재 버전을 2FA 소셜 로그인 완전 지원 또는 Gnuboard7 일반 인증과 완전히 동일한 2FA lifecycle이라고 설명하지 않습니다.

마이페이지에서 소셜 계정 관리

로그인한 회원은 마이페이지에서 활성화된 소셜 Provider의 연결 상태를 확인할 수 있습니다.

연결되지 않은 Provider는 직접 연결할 수 있고, 이미 연결된 Provider는 조건에 따라 연결을 해제할 수 있습니다.

계정 연결 과정에서는 인증된 현재 회원과 OAuth callback 사이의 연결을 유지하기 위해 1회용 link nonce를 사용합니다.

연결 과정에서는 회원 상태를 다시 확인하고 social identity 충돌을 검사합니다. 동일 identity가 이미 다른 회원에게 연결되어 있다면 연결을 거부하며, 같은 회원에게 이미 연결된 identity는 중복 레코드를 만들지 않도록 처리합니다.

또한 소셜 로그인으로 생성되어 실제 비밀번호가 없는 회원이 마지막 로그인 수단까지 해제하여 더 이상 로그인할 수 없게 되는 상황을 방지합니다.

실제 비밀번호를 설정한 회원은 해당 상태에 맞게 소셜 계정을 관리할 수 있습니다.

Provider 표시 순서 설정

1.5.0부터 관리자에서 소셜 로그인 Provider의 표시 순서를 변경할 수 있으며, 이 기능은 1.5.1에서도 유지됩니다.

관리 화면에서는 활성화된 Provider가 둘 이상인 경우 다음 방식을 사용할 수 있습니다.

• Drag & Drop 정렬
• Move Up
• Move Down

설정한 순서는 다음 화면에 공통으로 적용됩니다.

• 로그인
• 회원가입
• 마이페이지 소셜 계정 관리

기본 순서는 다음과 같습니다.

1. Naver
2. Kakao
3. Google
4. Facebook
5. GitHub

Provider를 일시적으로 비활성화해도 전체 순서에서 기존 위치를 보존하도록 구성되어 있어, 다시 활성화했을 때 기존 순서를 기준으로 표시할 수 있습니다.

Provider가 하나 이하인 경우에는 불필요한 정렬 UI를 표시하지 않습니다.

관리자 설정

관리자는 각 Provider별로 다음 항목을 설정할 수 있습니다.

• Provider 활성화 / 비활성화
• Client ID 또는 App ID
• Client Secret 또는 App Secret
• Provider 표시 순서

Client Secret과 App Secret은 민감한 설정값으로 정의되며 관리자 화면에서는 password input을 사용합니다.

각 OAuth Provider의 개발자 콘솔에는 해당 사이트의 callback URL을 별도로 등록해야 합니다.

Callback 경로의 기본 형식은 다음과 같습니다.

/api/plugins/glitter-social_login/{provider}/callback

OAuth App 생성과 Client ID/Secret 발급 자체를 플러그인이 대신 수행하지는 않습니다.

Redirect, OAuth State 및 Rate Limit

OAuth 시작과 callback은 Socialite의 session 기반 OAuth state 검증을 사용합니다. 플러그인은 이 흐름을 stateless 방식으로 우회하지 않습니다.

로그인 후 이동할 redirect path도 검증하며 외부 absolute URL, protocol-relative URL 등 허용하지 않는 형태는 안전한 내부 경로로 대체합니다.

OAuth 시작/callback, 최종 exchange, 가입·본인확인, 계정 연결/해제 등의 주요 흐름에는 용도에 맞는 rate limiting을 적용합니다.

템플릿 파일을 직접 수정하지 않는 UI 구성

Glitter Social Login은 Gnuboard7의 로그인·회원가입·마이페이지 템플릿 파일을 직접 수정하는 방식이 아닙니다.

core.layout_extension.after_apply hook을 이용하여 필요한 Social Login UI를 삽입합니다.

따라서 플러그인 기능을 위해 Gnuboard7 기본 템플릿에 Social Login 전용 코드를 직접 넣는 구조를 피했습니다.

로그인·회원가입·마이페이지의 알려진 layout 구조를 대상으로 위젯을 삽입하고, 이미 동일 위젯이 있으면 중복 삽입하지 않습니다.

다만 UI 삽입은 알려진 heading/form/profile 구조 등을 기준으로 하므로 임의의 모든 외부 템플릿과의 호환성을 보장하지 않습니다. 인식할 수 없는 구조에서는 무리하게 삽입하지 않는 방식입니다.

Provider 브랜드 아이콘

Provider 아이콘은 플러그인 내부의 로컬 resource를 사용합니다.

• Naver SVG
• Kakao PNG
• Google SVG
• Facebook SVG
• GitHub SVG

아이콘 파일을 읽어 data URI로 사용하므로 로그인 버튼 표시를 위해 외부 이미지 서버를 hotlink하지 않습니다.

설정 변경 후 관련 화면 갱신

Social Login 관리자 설정이 저장되면 다음 공개 화면의 layout cache를 무효화하도록 구성되어 있습니다.

• auth/login
• auth/register
• mypage/profile

Provider 활성화 상태나 표시 순서 등의 설정 변경이 관련 화면에 반영될 수 있도록 플러그인 자체에서 cache invalidation을 처리합니다.

계정 및 OAuth 처리

플러그인은 OAuth와 소셜 계정 처리 과정에서 다음과 같은 구조를 사용합니다.

• 허용된 Provider 목록 검증
• (provider, provider_user_id) 기반 social identity
• DB unique constraint를 통한 동일 social identity 중복 방지
• Provider별 이메일 검증 정책
• 기존 회원의 이메일 인증 상태 확인
• 회원 Active/lock 상태 확인 및 최종 exchange 전 재검사
• OAuth session state 검증
• Redirect path 검증
• OAuth 및 exchange/linking 관련 rate limiting
• session-bound DB 기반 1회용 로그인 exchange
• 마이페이지 계정 연결용 1회용 nonce
• User/SocialAccount 생성 및 연결 과정의 transaction/locking
• 마지막 로그인 수단의 무분별한 해제 방지
• OAuth Credential의 민감 설정 처리

이러한 구현은 OAuth 및 계정 연동 과정에 필요한 여러 보호 경계를 제공하기 위한 것이며, 모든 외부 OAuth 환경이나 모든 형태의 보안 위협을 포괄적으로 보장한다는 의미는 아닙니다.

Database 및 MariaDB

소셜 계정은 Provider별 테이블을 따로 만드는 방식이 아니라 공통 Social Login 계정 구조를 사용합니다.

주요 identity는 다음 조합으로 관리됩니다.

(provider, provider_user_id)

현재 플러그인은 다음 목적의 데이터 구조를 사용합니다.

• 소셜 계정과 회원 연결
• 동일 Provider identity 중복 방지
• 회원별 Provider 조회
• 계정 연결용 nonce
• 소셜 전용 회원의 실제 비밀번호 보유 상태 관리
• 최종 로그인용 짧은 수명의 exchange code 관리

1.5.1의 exchange 데이터에는 code hash, 회원 ID, session binding hash, redirect path, 만료 시각 및 소비 시각 등이 사용됩니다.

MariaDB에서 자동 생성되는 긴 index 이름으로 문제가 발생할 수 있는 경우를 고려하여 주요 unique index에는 명시적으로 짧은 이름을 사용합니다.

Provider가 추가될 때마다 Provider 전용 회원 테이블을 새로 만드는 구조는 아닙니다.

PHP Dependency와 Vendor Bundle

주요 PHP dependency는 다음과 같습니다.

• Laravel Socialite
• SocialiteProviders Manager
• SocialiteProviders Kakao

Naver는 plugin-local Provider를 사용하고 Google, Facebook, GitHub는 Laravel Socialite Provider를 이용합니다. Kakao는 SocialiteProviders Kakao를 사용합니다.

배포 패키지는 raw vendor/ 디렉터리를 그대로 포함하는 대신 Gnuboard7의 vendor bundle 구조에 맞춘 다음 파일을 제공합니다.

vendor-bundle.json
vendor-bundle.zip

vendor-bundle.json에는 번들 생성 정보, Composer 파일 hash, bundle hash, PHP requirement 및 포함 패키지 정보가 기록됩니다. 설치·업데이트 시 필요한 dependency가 없다는 의미가 아니라, Gnuboard7의 vendor bundle lifecycle을 통해 dependency를 설치하도록 구성된 배포 방식입니다.

한국어 · 영어 UI

현재 소스에서 확인되는 UI 언어는 다음 두 가지입니다.

• 한국어
• 영어

관리자 설정뿐 아니라 로그인·회원가입 버튼, 마이페이지 계정 연결 상태, 연결/해제 메시지, 오류 및 rate-limit 메시지 등 Social Login에 필요한 사용자 인터페이스를 번역 리소스로 제공합니다.

설치 요구 사항

• Gnuboard7 >=7.0.11
• PHP ^8.2

현재 plugin.json 기준:

Plugin ID : glitter-social_login
Version   : 1.5.1
Vendor    : Glitter.kr
License   : MIT

관리자 페이지에서 설치

1. GitHub 저장소에서 설치

관리자 → 플러그인 관리 → 수동 설치 → GitHub

저장소:

https://github.com/glitter-node/glitter-social_login

설치가 완료된 후 Glitter 소셜 로그인 플러그인을 활성화합니다.

2. ZIP 패키지 설치

Release package:

glitter-social_login-v1.5.1.zip

Release:

https://github.com/glitter-node/glitter-social_login/releases/tag/v1.5.1

관리자 → 플러그인 관리 → 수동 설치 → 파일 업로드 방식으로 설치할 수 있습니다.

설치와 업데이트는 migration, vendor bundle, route/hook/autoload 및 layout/cache 반영이 필요한 플러그인 lifecycle과 연결되어 있으므로, 운영 중인 설치본을 단순 파일 덮어쓰기로 교체하는 방식보다 Gnuboard7의 공식 플러그인 설치·업데이트 lifecycle을 사용하는 것을 권장합니다.

설치 후 필요한 설정

플러그인을 설치한 것만으로 각 OAuth Provider의 외부 설정까지 자동으로 완료되는 것은 아닙니다.

일반적인 설정 흐름은 다음과 같습니다.

1. Glitter Social Login 설치 및 활성화
2. 관리자 > Glitter 소셜 로그인 > 설정으로 이동
3. 사용할 Provider 활성화
4. 해당 Provider에서 OAuth App 생성
5. Client ID/App ID 및 Client Secret/App Secret 설정
6. Provider 개발자 콘솔에 callback URL 등록
7. 필요한 경우 Provider 표시 순서 조정

각 Provider의 정책과 개발자 콘솔 설정은 해당 서비스의 OAuth 정책에 따라 별도로 구성해야 합니다.

1.5.1 주요 변경 사항

로그인 eligibility 재검사

연결된 소셜 계정으로 로그인할 때 회원의 Active 상태와 lock 상태를 확인하고, 최종 exchange 단계에서도 회원 상태를 다시 확인하도록 인증 경계를 보강했습니다.

Pending Social Registration

미연결 social identity에 대해 OAuth callback에서 즉시 User를 생성하지 않고 pending registration을 거쳐 필요한 회원정보와 가입 동의를 확인하도록 구성했습니다.

Provider에서 사용할 수 있는 이메일을 얻지 못한 경우에는 사용자가 유효한 이메일을 입력해야 최종 가입할 수 있습니다.

가입 본인확인 정책 처리

지원되는 signup-before-submit 정책에서는 Gnuboard7의 public Identity Verification 서비스를 이용해 가입 전 본인확인을 진행할 수 있습니다.

현재 안전하게 완료할 수 없는 가입 후 본인확인 정책이나 신규 가입+전역 2FA 조건은 fail-closed합니다.

User/SocialAccount 원자적 처리

신규 회원과 SocialAccount 생성, 기존 회원 연결 및 수동 연결 과정에서 transaction, locking 및 unique constraint를 이용해 중복 identity와 동시 요청에 대한 처리를 보강했습니다.

Session-bound DB Exchange

최종 bearer token을 URL에 직접 전달하지 않고 60초 수명의 1회용 exchange code를 사용합니다.

DB에는 raw code 대신 hash를 저장하고, initiating browser session과 결합하여 조건부 1회 소비합니다.

UI 주입 보강

알려진 로그인·회원가입·마이페이지 layout 구조를 대상으로 UI를 삽입하고 중복 삽입을 방지합니다. 인식할 수 없는 외부 템플릿 구조에는 무리하게 삽입하지 않습니다.

2FA 현재 제한

Gnuboard7 Login-purpose 본인확인 challenge를 이용하는 경로는 구현되어 있으나, 현재 1.5.1에서는 기존 2FA 계정의 challenge 완료 후 최종 exchange까지 정상적으로 이어지지 않는 제한이 있습니다.

따라서 이 버전에서는 2FA 소셜 로그인을 완전 지원 기능으로 안내하지 않습니다.

1.5.0 주요 변경 사항

Provider 표시 순서 관리

로그인·회원가입·마이페이지에 표시되는 Provider 순서를 관리자가 직접 설정할 수 있습니다.

Drag & Drop과 명시적인 이동 버튼을 함께 제공하며 비활성 Provider의 기존 위치도 보존합니다.

관련 Layout Cache 갱신

Social Login 설정 저장 후 로그인·회원가입·마이페이지 관련 layout cache를 무효화하여 변경된 설정이 다시 구성될 수 있도록 했습니다.

버전별 주요 변화

버전 주요 변경

1.5.1 로그인 eligibility 재검사, pending Social Registration, 가입 consent/IDV 정책 처리, User/SocialAccount 원자적 처리, session-bound DB exchange, UI 주입 보강

1.5.0 Provider 표시 순서 설정, 이동 UI, 비활성 Provider 위치 보존, 관련 layout cache invalidation

1.4.0 GitHub OAuth 로그인·가입·수동 연동, primary/verified email 처리

1.3.0 Facebook OAuth 로그인·가입·수동 연동, Facebook email 자동 매칭 제외

1.2.0 Naver OAuth 로그인·가입·수동 연동 및 profile 처리

1.1.1 MariaDB 호환을 위한 명시적인 짧은 unique index name 적용

1.1.0 glitter-social-login plugin identity 및 관련 namespace·route·settings 정리

지원 환경

항목 요구사항

Plugin Glitter Social Login Version 1.5.1 Identifier glitter-social_login Vendor Glitter.kr Gnuboard7 7.0.11 이상 PHP 8.2 이상 (^8.2) UI Language 한국어, 영어 License MIT

알아두어야 할 점

• Provider별 이메일 검증 정책은 서로 다릅니다.
• 같은 이메일 주소라는 이유만으로 기존 회원과 무조건 자동 연결하지 않습니다.
• 기존 회원 이메일 자동 연결에는 Provider별 조건뿐 아니라 기존 Gnuboard7 회원의 이메일 인증 상태도 필요합니다.
• Facebook 이메일은 현재 기존 회원 자동 이메일 매칭에 사용하지 않습니다.
• Provider에서 가입에 사용할 이메일을 얻지 못하면 신규 가입 과정에서 유효한 이메일을 입력해야 합니다.
• OAuth App과 Credential은 각 Provider에서 운영자가 직접 준비해야 합니다.
• 모든 외부 Gnuboard7 템플릿 구조와의 호환성을 보장하지는 않습니다.
• 소셜 전용 회원은 다른 로그인 방법 없이 마지막 소셜 계정을 해제할 수 없습니다.
• 현재 1.5.1에서는 기존 2FA 계정의 소셜 로그인 완료 흐름에 제한이 있습니다.
• 실제 OAuth 동작은 각 Provider의 서비스 상태와 OAuth App 설정 및 정책에도 영향을 받습니다.

요약

Glitter Social Login 1.5.1은 Gnuboard7에서 Naver, Kakao, Google, Facebook, GitHub를 하나의 플러그인으로 관리하기 위한 Social Login 확장입니다.

로그인 버튼 제공뿐 아니라 pending 방식의 소셜 회원가입, Provider별 정책을 고려한 기존 회원 연동, 마이페이지 계정 연결·해제, 관리자 Provider 활성화 및 Credential 관리, 표시 순서 설정까지 하나의 흐름으로 구성합니다.

계정 연동에서는 이메일 주소 자체를 social identity로 간주하지 않고 (provider, provider_user_id)를 기본 identity로 사용하면서 Provider별 이메일 검증 정책과 기존 회원의 이메일 인증 상태를 별도로 확인합니다.

1.5.1에서는 여기에 로그인 eligibility 재검사, pending registration과 명시적 가입 동의, 가입 IDV 정책 처리, User/SocialAccount 원자적 처리, session-bound DB 기반 1회용 exchange 및 UI 주입 보강이 추가되었습니다.

설치

G7 관리자에서 GitHub 저장소를 이용하거나 Release package를 사용할 수 있습니다.

GitHub 저장소:

https://github.com/glitter-node/glitter-social_login

v1.5.1 Release:

https://github.com/glitter-node/glitter-social_login/releases/tag/v1.5.1

배포 패키지:

glitter-social_login-v1.5.1.zip
glitter-social_login-v1.5.1.tar.gz

Glitter Social Login 1.5.1
Vendor: Glitter.kr
License: MIT