[SLACK] 슬랙 메세지 알람받기(incoming webhook) 준비

slack ?

슬랙(Slack)은 이 중요한 커뮤니케이션의 효율성을 높이기 위한 도구다. 슬랙의 공개 채널, 비공개 그룹, 직접 메시징 기능은 팀원들에게 각 주제에 맞는 모드로 커뮤니케이션할 수 있는 옵션을 제공한다. 보통 채널을 만들어 메신저를 기본으로 사용한다. 또한 구글,트렐로,깃헙 등을 연동 할수있다. 그외에도 수많은 앱을 연동 할수있다.


aws 모니터링

aws cloudwatch나 cloudtrail의 특정 알람을 람다를 통해 슬랙으로 보내 모니터링을 하는게 대세인 듯 하다.


슬랙 incoming webhook 준비

1. 가입은 패스
2. 워크스페이스 만들기
워크스페이스

3. 앱만들기
앱만들기

4. 채널 만들기
채널생성

5. incoming webhook 생성
incomingwebhook
채널선택
웹훅주소생성

6. 호출테스트
호출

7. 호출테스트
메세지알람


[해외 SMS] nexmo sms verify

Verify API 제공

The Verify API enables you to confirm that you can contact a user at a specific number.

  • Protect against spam, by preventing spammers from creating multiple accounts
  • Monitor suspicious activity, by forcing an account user to verify ownership of a number
  • Reach your users at any time, by ensuring that you have their correct phone number

The general workflow is shown in the following sequence diagram:
flow

Node.js를 사용한 테스트

  1. npm init 초기화
  2. npm install nexmo

  3. nexmo npm 선언

    1
    2
    3
    4
    5
    6
    const Nexmo = require('nexmo');

    const nexmo = new Nexmo({
    apiKey: 'xxxxx',
    apiSecret: 'xxxxx',
    });
  4. code 요청하기

    1
    2
    3
    4
    5
    6
    7
    8
    nexmo.verify.request({
    number: '받을휴대번호',
    brand: 'Nexmo',
    code_length: '4'
    }, (err, result) => {
    console.log(err);
    console.log(result);
    });
  5. 결과확인(첫번째가 정상, 두번째는 중복발생불가)

    1
    2
    3
    4
    5
    6
    7
    8
    { request_id: 'dd0ffecfbab1459bba27cb8fc219cfd2', status: '0' }

    OR

    { request_id: 'dd0ffecfbab1459bba27cb8fc219cfd2',
    status: '10',
    error_text:
    'Concurrent verifications to the same number are not allowed' }
  6. 문자메세지 확인
    sms

  7. code 확인하기(받은 request_id로 요청,문자로 받은 코드4자리)

    1
    2
    3
    4
    5
    6
    nexmo.verify.check({
    request_id: 'dd0ffecfbab1459bba27cb8fc219cfd2',
    code: '0000'
    }, (err, result) => {
    console.log(err ? err : result)
    });
  8. 결과확인

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22

    정상
    { request_id: 'dd0ffecfbab1459bba27cb8fc219cfd2',
    status: '0',
    event_id: '1C0000001295AD96',
    price: '0.10000000',
    currency: 'EUR' }

    OR

    코드번호 불일치
    { request_id: 'dd0ffecfbab1459bba27cb8fc219cfd2',
    status: '16',
    error_text: 'The code provided does not match the expected value' }

    OR

    요청을 찾을수없음
    { status: '6',
    error_text:
    'The Nexmo platform was unable to process this message for the following reason: Request \'dd0ffecfbab1459bba27cb8fc219cfd2\' was not found or it has been verified
    already.' }

verify 자체개발 vs verify api 사용

  • verify 자체 개발시 난수발생(4자리,6자리) and 메모리db에 임시저장 확인시 조회 and 로그 자체기록

  • verify api 사용시 따로 메모리db 구축안하고 돈이 더 들어간다. 성공시 0.1 유로? 비싸다. 그냥 sms보내면 0.04유로
    대신 분석 및 로그조회가 가능하다

analytics

참고사이트

https://developer.nexmo.com/verify/overview

[SNS LOGIN] SNS 로그인시 받는 DATA분석 및 활용

FACEBOOK RESPONSE DATA

1
2
3
4
5
6
7
8
9
10
{
"authResponse": {
"accessToken": "EAAUNGBaxD3QBAN5ZAwP",
"userID": "238",
"expiresIn": 5278,
"signedRequest": "JwLCSwZmTIr6UP82lL1CFOL24nvtAp3aYmJB7pbemjI.eyJ1c2VyX2lkIjoiMjM4OTE2Nzg5NDUwODY0NiIsImNvZGUiOiJBUUNvR1RsUENrVnpsZWd3eDNRYi05bHJmNGU5X0dKd0bXRzdHR3U1JRSVVXRlRFU1RTNUM3YkJrRWYyOGx1RTRfZm5ZRnZNemNXYnQ0dEt0VkgtbVI2ZjB6OFhweHdNZFhjamRZMlI1VHdUSHRpY05yMkU4U3o1bllkSFdvc0tFbkhFTUJ3ejdFZkhlQXg1LVcyNyIsImFsZ29yaXRobSI6IkhNQUMtU0hBMjU2IiwiaXNzdWVkX2F0IjoxNTY0MDE4MzIyfQ",
"data_access_expiration_time": 1571794322
},
"status": "connected"
}

status는 앱 사용자의 로그인 상태를 지정합니다. status는 다음 중 하나일 수 있습니다.

  • connected - 사용자가 Facebook에 로그인하고 앱에 로그인했습니다.
  • not_authorized - 사용자가 Facebook에는 로그인했지만 앱에 로그인하지 않았습니다.
  • unknown - 사용자가 Facebook에 로그인하지 않았으므로 앱에 로그인했는지 알 수 없습니다. 또는 이전에 FB.logout()이 호출되었으므로 Facebook에 연결할 수 없습니다.
  • connected 상태인 경우 authResponse가 포함되며 다음과 같이 구성되어 있습니다.
    • accessToken - 앱 사용자의 액세스 토큰이 포함되어 있습니다.
    • expiresIn - 토큰이 만료되어 갱신해야 하는 UNIX 시간을 표시합니다.
    • reauthorize_required_in - 로그인이 만료되어 재인증이 필요하기 전까지의 시간(초)입니다.
    • signedRequest - 앱 사용자에 대한 정보를 포함하는 서명된 매개변수입니다.
    • userID - 앱 사용자의 ID입니다.

connected 가 정상적으로 되었을 경우 profile (정보)조회 가능 사전 앱 설정에 따라 제한할수있고
요청하는 DATA를 지정 (예시로 이메일 또는 이름 등 )하여 받을 수 있음.


GOOGLE+ RESPONSE DATA

gauth.currentUser.get().getAuthResponse()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

{
"token_type": "Bearer",
"login_hint": "AJDL5jnuaIYokj9TBX5defwHDYlm3wwAS_3ha8RuzhYS2JNg",
"expires_in": 3600,
"id_token": "eyJhbGciOiJSUzI1yNXFpMGFmMnZxb2tpNzVxdDlpbmtpbGNlOTVzaXUyLmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwic3ViIjoiMTE1MDY1ODEwODA4OTgxMjY1NzgwIiwiZW1haWwiOiJEVMM3JMaEs4N2RXbHZsM2VmQS9zOTYtYy9waG90by5qcGciLCJnaXZlbl9uYW1lIjoi64Ko6riwIiwiZmFtaWx5X25hbWUiOiLsnKQiLCJsb2NhbGUiOiJrbyIsImlhdCI6MTU2NDAxOTA0MiwiZXhwIjoxNTY0MDIyNjQyLCJqdGkiOiI4ZDc0MWVhMTgzMzhjM2FlY2Q1OTVlYWVhNTgxMWI5MWRkYWUyM2I5In0.aKUSck0apteYWhRLKdsWs21xqICkkmWDnA9rc97UOV0l1OECy_fo5rxf8QFKzDorsbkfuY50eG5x7PjW65Wak7DujW08kOGfwh6POBCxe_pAkwSNXpNf0g8ZHefOK2RAGzOzBmp5U2Ptg6a9pPrlIMa_eb7C-RVIHTRKM48HdcCNZN8XGq4WhEoAnZ2-ZGVQnzFgMCMusQgrMzdabAwfvHpjAdKNVR9Vq7iPSTouXiWHJfbRPNnp6LEQxlrOt8GZEVK5AFxnnDIgP26y81hfwIssNHuDNlveoWvKpyk0creKwPG5dDbrVS4c0lGAV7gimz7M40spH8CimNgowZRk6Q",
"session_state": {
"extraQueryParams": {
"authuser": "0"
}
},
"first_issued_at": 1564019043142,
"expires_at": 1564022643142,
"idpId": "google"
}

gauth.currentUser.get().getBasicProfile()

1
2
3
4
5
6
7
var profile = auth2.currentUser.get().getBasicProfile();
console.log('ID: ' + profile.getId());
console.log('Full Name: ' + profile.getName());
console.log('Given Name: ' + profile.getGivenName());
console.log('Family Name: ' + profile.getFamilyName());
console.log('Image URL: ' + profile.getImageUrl());
console.log('Email: ' + profile.getEmail());


간편로그인 및 간편회원가입시 활용 DATA

access_token은 sns의 추가 api기능을 활용할 때 이용하게 된다.

간편로그인 및 간편회원가입시 실제 필요한 DATA는 userID + profile 정보이다.

SNS 회원정보 연동 DB구성(스키마) 예시

참고

[해외 EMAIL] AWS SES vs SendGrid vs Mailgun

AWS SES vs SendGrid vs Mailgun

AWS
Amazon SES : Amazon SES ( Amazon Simple Email Service )는 신뢰할 수 있고 확장 가능한 인프라 구현으로 구축 된 비용 효율적인 전자 메일 마케팅 도구 중 하나입니다. Amazon.com에서 자체 고객 기반의 서버로 개발했습니다. Amazon SES는 거래 전자 메일, 마케팅 전자 메일 또는 기타 유형의 최고 품질의 콘텐츠를 구독자에게 보내도록 설계되었습니다. 그 외에도 아마존 SES는 사용자가 사용하는 것에 대해서만 비용을 지불함으로써 이익을 얻으므로 최소 의무를 요구하지 않습니다. Amazon ses 와의 통합을 확인하십시오 .

VS

sendgrid
SendGrid : 2009 년에 설립 된 SendGrid 는 거래 전자 메일 전송 분야의 전문가입니다. 클라우드 기반 전자 메일 서비스와 관련하여 혼란을 겪었던 기간에 개발 및 도입되었습니다. 따라서 SendGrid는 성장하는 회사가 전자 메일을 보내는 것이 고통스럽고 엉망이 된 시간에 구독자 목록에 전자 메일을 보내는 것을 도왔습니다. 오늘날이 회사는 전 세계 최고의 노치 회사 중 일부를 대신하여 대량 메일을 발송할 책임이 있습니다. SendGrid의 신뢰할 수있는 플랫폼, 도구 및 프로 서비스 팀은 개발자 확인 및 마케팅 담당자가 구매 확인,암호 재설정 지침 또는 캠페인 육성 여부에 상관없이 모든 전자 메일을 디자인, 분류, 테스트 및 성공적으로 전달할 수 있게합니다.

VS

mailgun
Mailgun은 Rackspace에서 제공하는 전자 메일 자동화 서비스입니다. 귀하의 웹 사이트 및 응용 프로그램을 통해 전송 된 전자 메일을 전송, 수신 및 추적하기위한 완벽한 클라우드 기반 전자 메일 서비스를 제공합니다. Mailgun 기능은 직관적 인 RESTful API를 통해 사용하거나 SMTP와 같은 기존 이메일 프로토콜을 사용하여 사용할 수 있습니다. Rackspace Cloud 고객은 Mailgun의 기본 계획을 통해 매달 50,000 개의 이메일을 무료로 보낼 수 있다. 2013 년 7 월부터 Rackspace는 관리 작업을 통해 클라우드 서버용 Windows 및 Linux 이미지를 미리 구성하여 SMTP를 사용하여 Mailgun을 통해 이메일을 전송합니다.


Features(특색 차이점)

Mailgun, SendGrid 및 SES는 모두 공통된 기능을 제공한다. 세 가지 서비스 모두를 사용하면 유효성 검사 및 DMARC 준수에 대한 모범 사례를 사용하여 트랜잭션 전자 메일을 보내도록 도메인을 설정할 수 있다. 그러나 각 서비스에는 다른 서비스와 차별화되는 몇 가지 사항이 있다.

Amazon SES
Amazon SES의 주요 이점 중 하나는 AWS 플랫폼의 다른 서비스와 통합된다는 것입니다. EC2에서 호스팅하는 사이트에서 원활하게 사용하고, SNS (Simple Notification Service)로 사용자 정의 알림을 구성하고, Amazon Cloudwatch로 사용자 정의보고를 설정할 수 있다. 또한 응용 프로그램 (또는 WordPress 사이트)을 테스트하여 메일을 올바르게 보내고 바운스 / 불만 알림 수신을 테스트하는 데 사용할 수 있는 편리한 사서함 시뮬레이터 가 있다.

SES가 부족한 영역 중 하나는 대시 보드입니다. Cloudwatch에서 사용자 정의 보고서를 구성하거나 WP Offload SES를 사용하여 보고서를 보거나 통계를 보내지 않는 한 정보 탐색이 다소 어려울 수 있다.

Mailgun
MailGun은 전자 메일을 보내는 것 외에도 전자 메일 유효성 검사 서비스도 제공한다. 이렇게 하면 메일을 보내고있는 이메일 주소가 실제로 존재하는지 확인하고 반송 및 허위 이메일을 줄일 수있다.

이 기능의 진정한 힘은 실시간 유효성 검사를 위해 연락 양식에 통합되었을 때 실현된다. 따라서 양식을 제출하는 사용자는 잘못된 전자 메일 주소를 입력했거나 간단히 오타를 만든 경우 신속하게 알린다.

SendGrid
SendGrid는 트랜잭션 전자 메일의 모든 일반적인 기능을 갖추고 있지만 전체 전자 메일 마케팅 서비스의 추가 이점도 있다.
즉, 거래 전자 메일 서비스를 관리하고 동일한 대시 보드에서 마케팅 캠페인을 보낼 수 있다.


Pricing(가격)

Amazon SES
Amazon은 전송 된 전자 메일 당 10 센트를 요하는 pay-as-you-go 방식을 사용한다. 고려해야 할 별도의 계층이 없기 때문에 이메일 볼륨을 기준으로 가격을 쉽게 예측할 수 있다.

한 달에 24.95 달러에 전용 IP 주소를 추가 할 수 있다. 이는이 비교에서 세 서비스 중 가장 저렴하다.

그리고 웹 사이트가 Amazon EC2에서 호스팅되는 경우 월간 처음 62,000 개의 이메일이 완전히 무료라는 점을 분명히 말할 가치가 있다.

따라서 호스팅 및 트랜잭션 전자 메일 서비스에 대해 하나의 로그인 만하는 것이 아니라 돈을 절약 할 수 있다.

비교를 위해 EC2를 사용하지 않을 경우 지불 할 것으로 기대할 수있는 몇 가지 예가 있다.

20,000 개의 이메일 - $ 2.00 / 월
200,000 개의 이메일 - $ 20.00 / 월
전용 IP - $ 24.95 / 월

mailgun
Mailgun에는 pay-as-you-go 계획과 계층 형 가격 책정이 있다. 지불 방식대로 요금제는 10,000 개의 이메일을 무료로 받고 1,000 개의 이메일 당 $ 0.50의 요금을 부과한다.

계층 형 가격 정책은 월 79 달러부터 시작하며 전용 IP 주소와 100,000 개의 전자 메일이 포함된다.

계층화 된 계획이 없다면 Mailgun의 전용 IP 주소는 Amazon SES보다 두 배 이상, 전용 IP 당 $ 59가 소요된다. 이 비교는 또한 귀하가 미국 지역을 사용하고 있다고 가정

유럽의 지역은 요금제 및 요금제에 따라 추가 요금을 부과 할 수 있다.

그리고이 기사의 앞부분에서 언급 한 이메일 검증 API는 추가 비용이 들지만,이 비교를 위해 이를 제외하고 있다.

20,000 개의 이메일 - 월 $ 5.00
200,000 개의 이메일 - 매월 $ 95 (당신이가는대로 지불)
200,000 개의 이메일 - 월 $ 139.00 (계층화 된 가격 + IP 주소 포함)
전용 IP - 월 $ 59.00

SendGrid
SendGrid는 처음 30 일 동안 40,000 개의 이메일을 제공하는 무료 계획부터 몇 가지 계획을 사용할 수 있다. 그 후 무료 플랜은 하루에 100 개의 이메일로 제한되어 있다.

하루에 100 개가 넘는 경우 유료 요금제 중 하나를 사용해야한다. 월간 14.95 달러에서 최대 4 만 개의 이메일을 사용할 수 있다.

한 달에 30 달러의 전용 IP 주소를 추가 할 수 있으며, 이메일 마케팅 도구를 사용하려는 경우 추가 요금이 부과.

20,000 개의 이메일 - $ 14.95 / 월
200,000 개의 이메일 - $ 104.95 / 월
전용 IP - $ 30.00 / 월


Final Opinion(결론)

Mailgun은 많은 이메일을 보내지 않는 소규모 사이트에 월간 10,000 편의 무료 이메일을 제공 할 수있는 최선의 선택 일 수 있다.

SES는 많은 이메일을 보내거나 이미 다른 AWS 서비스 (특히 Amazon EC2)를 사용하고있는 개발자 나 사이트 소유자에게 더 의미가 있다.

또한 가장 저렴하게 이메일 서비스를 이용 할 수 있다.

SendGrid는 가격이나 서비스면에서 전반적으로 우수하고 이메일 마케팅 소프트웨어를 사용하려는 경우 훌륭한 옵션이다.

[해외 SMS] twilio vs nexmo

Features and Services(기능 서비스)

Both platforms are very similar in the functions, features and services they provide users.

두 플랫폼 모두 사용자에게 제공하는 기능, 기능 및 서비스면에서 매우 유사합니다.

With Voice, SMS, and Authentication available from both Nexmo and Twilio, the key differences lie in not only the specific features included for each section, but also what functions if any the platforms include beyond these three.

Nexmo와 Twilio에서 음성, SMS 및 인증을 사용할 수있는 주요 차이점은 각 섹션에 포함 된 특정 기능뿐만 아니라이 세 가지를 넘어 플랫폼이 포함될 경우 어떤 기능이 있는지에 있습니다.

I rounded up the most relevant information provided by both Nexmo and Twilio to offer as close to a complete comparison as possible.

Nexmo와 Twilio가 제공 한 가장 관련성 높은ㅈ 정보를 가능한 한 완벽하게 비교할 수 있도록 제공했습니다.

Messaging

messaging

※ 넥스모의 Free Inbound SMS 정책은 현재 유료로 바뀐것으로 보인다.

Authentication

auth

Pricing(가격)

When it comes to the pricing of these platforms, the paradigm is different from what we have seen when comparing VoIP providers or even Team Collaboration apps. Generally, the cost of a platform is a reoccurring monthly fee based on the active users – however with Nexmo and Twilio, pricing is broken down between the phone numbers your account owns, and the incoming our out coming communications that occur. Pricing will of course differ between outbound and inbound messages, as well as between voice, SMS or authentication functions.

이러한 플랫폼의 가격 체계는 VoIP 공급자 또는 Team Collaboration 응용 프로그램을 비교할 때 보았던 것과 다릅니다. 일반적으로 플랫폼 비용은 활성 사용자를 기준으로 월별 요금이 다시 발생합니다. Nexmo 및 Twilio를 사용하면 계정에있는 전화 번호와 발생할 외부 통화에 대한 가격이 책정됩니다. 물론 발신, 수신 메시지는 물론 음성, SMS 또는 인증 기능간에 가격이 다릅니다.

pricing

Twilio Pricing : https://www.twilio.com/sms/pricing/us

Nexmo Pricing : https://www.nexmo.com/pricing

nexmo소수점은 유로 → 달러 환전에 따른 값으로 보이고 위의 보내는 메세지는 미국 기준이지만 다른 나라도 대체로 비슷한 수준이다.

Support(지원)

Of course for any Cloud platform, support is as crucial as the user experience – if something ever goes wrong, you want to ensure help is there and that it will arrive within a reasonable window. With both Twilio and Nexmo, every account will start with standard, free yet limited, support. For a bit of a premium, users can upgrade their support to varying levels.

물론 클라우드 플랫폼의 경우 사용자 경험만큼 지원이 중요하다. 문제가 발생할 경우 도움이 있어야 하며 적절한 시간 내에 도움이 제공되도록 해야 한다. Twilio와 Nexmo 둘 다와 함께 모든 계정은 무료지만 제한된 지원으로 시작할 것이다. 약간의 프리미엄을 위해, 사용자들은 그들의 지원을 다양한 수준으로 업그레이드할 수 있다.

Twilio(https://www.twilio.com/support-plans)

Free – Email only, no guaranteed response time
PRODUCTION– 4% of monthly spend (or $250 minimum), depending on Priority level - Answer in business hours(3h,6h,9h)
BUSINESS– 6% of monthly spend (or $1,500 minimum), depending on Priority level - Answer in business hours(1h(24/7),6h,9h), Email and phone support (24/7)
PERSONALIZED – 8% of monthly spend (or $5,000 minimum), depending on Priority level - Answer in business hours(1h(24/7),6h,9h), Email and phone support (24/7),Technical account manager,Support escalation line,Quarterly status review

Nexmo(https://www.nexmo.com/pricing)

Standard– Support via email and web
Priority Support– $1,500 a month for Support via chat, email, and web 24/7 escalation
Enterprise - contact
The Bottom Line(결론)
At the end of the day, both Twilio and Nexmo should satisfy the majority of users and developers. Both providers offer comparable features, functions, products and service. Both providers include detailed and rich docs for developers, as well as a well thought out design and a solid user experience. Both providers include comprehensive support, and allow users the option to upgrade support for 24×7 coverage and personal engineers.

두 회사 모두 유사한 기능, 기능, 제품 및 서비스를 제공합니다.

두 회사 모두 개발자를위한 상세하고 풍부한 문서뿐만 아니라 잘 설계된 디자인과 확실한 사용자 경험을 제공합니다.

두 회사 모두 포괄적 인 지원을 제공하며 사용자가 24x7 커버리지 및 개인 엔지니어 지원을 업그레이드 할 수있는 옵션을 제공합니다.

비슷한 가격에 twilio가 더 나은 기능과 서비스를 제공하는 것 같다.

관리(console)의 편의성이나 개발(api)의 편리함이 보인다.

또한 email서비스인 sendgrid도 twilio의 서비스이다.

참고사이트

https://getvoip.com/blog/2017/01/05/twilio-vs-nexmo/
https://www.twiilio.com/
https://www.nexmo.com

[SNS LOGIN] sns(kakao) login with javascript

간편로그인

카카오에서 간편로그인으로 ios,android,javascript,restapi를 제공한다.

restapi는 앱서버에서 OAuth2.0인증에 따라 인증코드로 SNS로 조회 후 로그인(세션/토큰) 처리까지 처리했다면
javascript SDK를 사용하면 클라이언트에서 바로 SNS로그인 결과를 받아서 처리를 할수있다.


javascript 로 kakao login

  1. https://developers.kakao.com 회원가입 & 로그인

  2. 앱만들기 & 플랫폼 사이트 추가
    사이트 추가

  3. 사용자관리 & 등록
    사용자관리

  4. 개인정보 동의
    사용자관리

  5. javascript 코드 with html

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    <!DOCTYPE html>
    <html>
    <head>
    <meta charset="utf-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, width=device-width" />
    <title>Login Demo - Kakao JavaScript SDK</title>
    <script src="//developers.kakao.com/sdk/js/kakao.min.js"></script>

    </head>
    <body>
    <a id="kakao-login-btn"></a>
    <a href="http://developers.kakao.com/logout"></a>
    <script type='text/javascript'>
    //<![CDATA[
    // 사용할 앱의 JavaScript 키를 설정해 주세요.
    Kakao.init('javascript key 입력');
    // 카카오 로그인 버튼을 생성합니다.
    Kakao.Auth.createLoginButton({
    container: '#kakao-login-btn',
    success: function (authObj) {
    alert(JSON.stringify(authObj));
    },
    fail: function (err) {
    alert(JSON.stringify(err));
    }
    });
    //]]>
    </script>
    </body>
    </html>
  6. node 환경은 생략

  7. node.js로 간편하게 실행하기(npm은 express,body-parser,cookie-parser,multer 설치)

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    var express = require('express');
    var app = express();

    app.get('/', function (req, res) {
    res.sendfile('./index.html');
    })

    var server = app.listen(8000, function () {
    var host = server.address().address
    var port = server.address().port

    console.log("Example app listening at http://%s:%s", host, port)
    })

server.js

  1. 실행 node server.js

  2. localhost:8000 접속
    사용자관리

  3. 로그인창
    로그인

  4. 결과내용
    결과내용

[WEBSERVER] sns login (oauth2)

SNS LOGIN

간편로그인
웹 또는 앱서비스에 간편로그인은 기본으로 장착되는 추세이다.

SNS 로그인을 이용하기전 기반 기술을 정리해본다.

OAuth2.0

OAuth는 3rd party(외부서비스) 인증 과 허가를 위한 표준 프로토콜이다.
IT기업에서 OPEN API를 제공할때 oauth를 사용하여 서비스한다.
대표적으로 페이스북,구글,네이버,다음카카오 등이 있겠다.
공통적으로 각 회사 개발자지원센터에서 가입 후 앱 혹은 웹을 만들어서 개발키를 부여받게되고
개발키를 사용하여 각 회사가 정의한 API사용법에 따라 인증 후 AccessToken을 발급받아 API 들을 사용 할 수있게된다.


권한 흐름
oauth2.0

  1. Resouce Owner(API제공업체) 인증코드 요청
  2. 요청성공시 인증코드(Authrization Grant) 전달
  3. 인증코드로 Authorization Server에 토큰요청(AccessToken)
  4. 유효한 인증코드일때 토큰전달
  5. 토큰으로 리소스 요청
  6. 토큰이 유효한 경우 리소스 전달

특징

  1. Oauth1.0에서는 앱에서의 사용이 어려웠다.
  2. 1.0의 복잡한 구현과 흐름을 간소화 하였다.
  3. 별도의 암호처리 없이 HTTPS를 이용한다.
  4. HMAC를 사용하지 않는다.
  5. AccessToken 유효시간을 지정할수있다.

SNS 로그인?

SNS로그인은 Oauth2.0의 흐름에 서버인증을 추가하면 된다.

로그인 Flow
sns login

  1. 사용자가 간편로그인을 요청
  2. 해당 sns 로그인 페이지 리다이렉트
  3. 등록된 url로 코드전달
  4. 전달된 권한코드 검증
  5. 검증성공시 토큰 및 프로파일 제공
  6. 해당 정보로 회원정보 인증처리
  7. 세션 또는 토큰기반으로 인증처리
  8. 로그인 성공

[WEBSERVER] JWT(JSON WEB TOKEN)?


JWT(JSON Web Token)?

JSON형식으로 웹에서 사용하는 토큰? JSON 객체로서 당사자간에 안전하게 정보를 전송할 수있는 작고
독립적 인 방법을 정의하는 공개 표준 ( RFC 7519 )이라고 한다.

사용?
토큰기반인증에 사용하거나 안전한 정보교환이 필요할때 유용하다고 한다.

구조?
.을 구분자로 3가지의 문자열로 되어있다. 헤더(header).내용(payload).서명(signature)

헤더:
{
“typ”: “JWT”, // 토큰타입
“alg”: “HS256” // 해싱 알고리즘정보
}

내용:
정보의 한 ‘조각’ 을 클레임이라고 한다.클레임은 사용자에 대한 프로퍼티나 속성을 넣는다.
registered, public, private claims으로 구분한다.

registered claim
미리 정의된 claim으로써, 토큰에 대한 정보이다.

public claim
공개적인 claim을 명시하는데, 충돌 방지를 위해 URI 형식으로 작성한다.

private claim
서버와 클라이언트가 협의한 claim을 명시한다.
이미 정해져 있는 이름을 가진 아래의 7개에 대한 정보를 담을 수 있다.

iss : Token 발행자(Issuer)
sub : Token의 제목 (Subject)
aud : Token 의 대상자 (Audience)
exp : Token의 유효한 날짜 정보(Expiration time)
nbf : Token 의 유효 시작 날짜 정보 (Not before)
iat : Token의 발행된 날짜 정보(Issued At)
jti : Token 의 고유 식별자(JWT ID)

Claim을 JSON 행태로 정의한다.

예시:
{
“userId”:”skarl”,
“exp”: “1485270000000”,
“role”:[“admin”]
}
사용시에는 BASE64 인코딩을 통해서 문자열로 변환한다.

서명:
서명은 헤더의 인코딩값과, 정보의 인코딩값을 합친후 주어진 비밀키로 해쉬를 하여 생성한다.

서명을 만드는 수도코드 구조

1
2
3
4
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
"kkkkmysecret")

해쉬 -> base64로 인코딩 후 사용

like this
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiJza2FybCIsImV4cCI6IjE0ODUyNzAwMDAwMDAiLCJyb2xlIjpbImFkbWluIl19.jAafdBOQCoZkV-xMcJx0BCTH45AqYtf9mcdKog4ewjc

example
https://jwt.io/ 공식 홈페이지에서 테스트 해볼 수 있다.

공홈 테스트


[WEBSERVER] session/cookie or token

인증방식

1. 서버기반
HTTP프로토콜을 기반으로하는 통신에서 client가 요청시 한번 response후에는 특별한 처리를 하지 않는이상
접속을 끊는다. 만약 최초 로그인을 했다고 하더라고 그후에 요청시 client의 정보는 없다는 것이다.
그래서 서버에서 세션을 만들어주고 쿠키를 사용하여 문제를 해결한다.

로그인 -> 서버에서 session-id 생성 전달 -> client sessionId 쿠키에 저장 후 사용

장단점
일반적인 웹서비스에서 많이 쓰이는 인증방식이다. 쿠키자체에 주요정보가 있지 않아 안전한편
서버에서 세션및쿠키를 관리하기때문에 사용자가 많아지면 확장이 필요하다.
확장을 위해 메모리DB등을 사용해야한다.


세션기반 흐름

시퀀스 다이어~


2. 토큰기반
서버에서 발행한 토큰을 이용해 인증처리를 한다.

요청시 헤더에 토큰값을 보내면 서버에서 토큰검증만 하면된다.

로그인 -> 서버에서 로긴처리후 token발급 -> client에서 요청시 헤더에 token

장단점
확장을 위한 메모리DB등을 사용할 필요없다.
쿠키로 인한 사이트간 요청위조를 방지 할수있다.
도메인 상관없이 토큰으로 인증
토큰 탈취시 보안에 취약 하지만 refresh_token과 access_token의 주기 설정으로 어느정도 방어가능


토큰기반 흐름

시퀀스 다이어~

[JENKINS] pipeline 작성


git lab 설정에서 webhook (push Event) 이후 작성 정의(pipeline)

pipeline script

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

pipeline {
agent any

tools {nodejs "node"}

stages {
stage('Cloning Git') {
steps {
git url: 'https://xxx.xxxxx.com/bittorage/WebServer.git',
credentialsId: 'gitlab-skarl-passwd',
branch: 'develop'
}
}

stage('Install dependencies') {
steps {
sh 'npm install'
}
}

stage('Test') {
steps {
sh 'npm test'
}
}
}
}

실행

실행

로그

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
Started by GitLab push by 
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on Jenkins in /var/lib/jenkins/workspace/pipe1
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Cloning Git)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] git
using credential gitlab-skarl-passwd
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url https://xxx.xxxxxxx.com/bittorage/WebServer.git # timeout=10
Fetching upstream changes from https://xxx.xxxxxxx.com/bittorage/WebServer.git
> git --version # timeout=10
using GIT_ASKPASS to set credentials gitlab-skarl-passwd
> git fetch --tags --progress https://xxx.xxxxxxx.com/bittorage/WebServer.git +refs/heads/*:refs/remotes/origin/*
skipping resolution of commit remotes/origin/develop, since it originates from another repository
> git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
Checking out Revision 449b52612009786e6e7ae37841f57b3602fc89ff (refs/remotes/origin/develop)
> git config core.sparsecheckout # timeout=10
> git checkout -f 449b52612009786e6e7ae37841f57b3602fc89ff
> git branch -a -v --no-abbrev # timeout=10
> git branch -D develop # timeout=10
> git checkout -b develop 449b52612009786e6e7ae37841f57b3602fc89ff
Commit message: "모카 테스트 예제 추가"
> git rev-list --no-walk a7271488613cc3aeb66bd06be08603e458a57c40 # timeout=10
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Install dependencies)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] sh
+ npm install
npm WARN webserver@0.1.0 No repository field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.6 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.6: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

audited 17564 packages in 18.837s
found 7 vulnerabilities (1 moderate, 6 high)
run `npm audit fix` to fix them, or `npm audit` for details
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Test)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] sh
+ npm test

> webserver@0.1.0 test /var/lib/jenkins/workspace/pipe1
> mocha ./test/Websocket.test.ts --exit



Sample route
Server is running in process 11973 listening on PORT 1344

Parsing session from request...
no passport
JHnljEKqdbSt48woI0AdXGC6IAZZnU91
open
undefined
{"trCode":42,"message": {} }
code= { trCode: 42, message: {} }
setStorageSock
2019-04-24 10:53:00,528 INFO [STORAGE:NOTICE:CONTROLLER] StorageNoticeController init
faq key= 42
msg Cannot read property 'publish' of undefined
key=== 42
{ networkType: 0,
trCode: 42,
result: 0,
message:
[ { createDate: null, lastModifiedDate: null }] }


✓ STORAGE Test (104ms)
after


1 passing (191ms)

[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Triggering a new build of ansible-project #2
Finished: SUCCESS