• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Twitter API, oAuth, STOMP Protocol
 

Twitter API, oAuth, STOMP Protocol

on

  • 5,030 views

Blogcocktail Dev Team Aug. 2009 Worksthop

Blogcocktail Dev Team Aug. 2009 Worksthop
By Seira

Statistics

Views

Total Views
5,030
Views on SlideShare
4,768
Embed Views
262

Actions

Likes
1
Downloads
64
Comments
0

5 Embeds 262

http://blog.blogcocktail.com 168
http://blogcocktail.com 73
http://www.slideshare.net 14
http://www.hanrss.com 6
https://www.facebook.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Twitter API, oAuth, STOMP Protocol Twitter API, oAuth, STOMP Protocol Presentation Transcript

    • Twitter API / oAuth Seira, templar@blogcocktail
    • Twitter API
    • Things Every Developer Should Know... ● Two APIs – REST API / Search API ● Call Limit ● 1000 total Updates/Day ● 250 total DM/Day ● 150 API request/Hour ● HTTP-based, Restful ● Special Parameters ● callback ● suppress_response_codes
    • Things Every Developer Should Know... ● Pagination limits ● REST API : 3200 status ● Search API : 1500 status ● Encoding ● HTML entities
    • 인증방식 ● Basic Authentication ● HTTP 기본적인 인증방식 ● 어플리케이션이 비밀번호를 저장하거나 읽어야 함 . ● Base64 인코딩을 하나 , 네트워크에 패스워드가 노 출 ● 공식블로그의 blogcocktail@twitter 에서 이 방식 사용 ● oAuth ● 매시업 어플리케이션을 위한 좀 더 강화된 인증방식 ● 이 부분에 대해서는 뒤에서 더 자세하게 다룸
    • 보안 이슈 ● 패스워드 저장 ● 저장하지 말고 oAuth 를 쓰라고 강력히 권고 ● Basic Authentication 은 곧 폐지 (deprecated) 될 것임 ● SSL ● 트위터는 모든 REST API 에 SSL 을 지원 ● 민감한 API 호출시 SSL 연결을 지원할 것을 권고 ● 데스크탑 Apps ● 패스워드 저장시 암호화 서비스 사용 권고 (keyChain, keyring)
    • 앞으로의 트위터 API ● Retweet API 의 지원 ● statuses/home_timeline ● statuses/retweeted_by_me ● statuses/retweeted_to_me ● statuses/retweets_of_me ● statuses/retweet ● Streaming API ● 아직 알파테스트중 ● Geolocation API
    • oAuth
    • oAuth 란 ? ● 매시업 어플리케이션이 다른 서비스의 API 를 호출 하기 위해서는 사용자의 권한을 가지고 있어야 함 . ● 이를 위해서 App Key 나 심지어 ID/PW 를 매시업 어플리케이션이 저장해야 하는 것이 문제 ● 이를 해결하기 위한 새로운 인증 방식 ● 공개 표준 ● Google AuthSub, Yahoo! BBAuth 등과 비교 ● 이들 서비스의 베스트 프랙티스를 모아 만들었 음
    • oAuth 를 발렛 키에 비유 ● oAuth 는 당신이 사용하는 모든 웹서비스에 대한 발렛 키다 . ● 발렛 키는 당신의 차를 주차할 수 있을 정도의 권한만 제공하지 , 트렁크를 열거나 2 마일 이 상 운전하거나 RPM 의 빨간 선까지 속도를 내 는 권한은 없다 . ● 마찬가지로 , OAuth 키는 웹 에이전트가 당신 의 웹 메일을 체크하는 기능만 제공하며 , 당 신인 것처럼 해서 주소록에 있는 모든 사람에 게 메일을 보내는 일은 하지 못하게 한다 .
    • oAuth 인증에 관여하는 객체 ● Service Provider(SP) ● 인증이 필요한 서비스를 제공하는 사이트 ● User ● SP 에 인증을 할 수 있는 자격이 있는 사용자 ● Consumer ● User 가 SP 의 데이터를 공유하길 원하는 사이 트 , Apps ● 사전에 SP 와 Consumer 는 신뢰 관계를 맺고 있어야 함
    • Oauth 인증에 관여하는 객체 ● Protected Resources ● Consumer 가 인증을 통해 SP 로부터 제공받 고자 하는 데이터 ● Tokens ● 비밀번호 (credentials) 대신 인증을 위한 키 ● 임의의 문자열로 보통 구성되어 있음
    • oAuth 인증 프로세스 ● Consumer 가 인증되지 않은 상태에서 SP 에 게 인증이 필요한 하는 자원을 요청 ● SP 는 401 NotAuthorized 로 응답 ● 응답시 헤더에 oAuth 인증이 필요함을 명시 WWW-Authenticate: Oauth realm="http://sp.example.com/" ● 이제 Consumer 는 oAuth 로 인증하기 위해 사전에 SP 로부터 받은 Consumer key 를 가 지고 요청 ● SP 는 이 요청에 대해 Request Token 과 Request Secret 을 응답
    • oAuth 인증 프로세스 ● Consumer 는 인증을 획득하기 위해 SP 의 인증 URL 로 사용자를 유도 ● 이 때 request token 를 함께 보냄 ● 또한 callback URL 을 보낼 수 있음 ● 사용자는 SP 에 ID/PW 로 인증 ● 인증 과정은 Consumer 는 전혀 관여하지 않음 ● SP 는 request key 를 획득한 consumer 의 접근을 허락할 것인지를 사용자에게 물어보고 , 이를 승인 하면 해당 request key 를 승인 . ● callback URL 이 있다면 사용자를 유도
    • oAuth 인증 프로세스 ● Consumer 는 이제 인증된 자원에 접근하기 위해 Request Token 을 Access Token 으로 바꾸어 줄 것을 요청함 ● SP 는 요청을 분석하고 Access Token 및 Access Token Secret 을 응답함 ● Access Token 을 받은 Consumer 는 이제 인 증된 자원에 접근할 수 있음
    • oAuth 인증시 보안 ● 앞에 설명한 oAuth 인증 프로세스에서는 Token 및 secret 키의 무결성과 부인방지를 위한 방법이 생략 되었음 ● 이를 위해 , 보안 연결 (HTTPS) 을 사용할 수 있음 ● 하지만 HTTPS 는 설치 및 유지보수에 진입장벽이 높음 ● 기본적으로 oAuth 는 비보안 연결을 위해 디자인되 었다고 언급하고 있음 ● 비보안 연결을 위해 signing requests 를 할 것 을 명시하고 있음
    • oAuth 의 Signing request ● oAuth 는 Customer 의 모든 요청에 oauth_signature_method 파라미터를 명시한 signing request 를 사용할 것을 명시 ● 보안 연결일 경우에는 signature_method 를 PLAINTEXT 로 사용 가능 ● oAuth 스펙에서는 세 가지 signature_method 를 정의 ● HMAC-SHA1, RSA-SHA1, PLAINTEXT ● Signing request 를 위해 요청시 oauth_signature 파라미터를 함께 보내도록
    • oAuth 의 Signing request ● oauth_signature ● Signature Base String 을 명시한 signature_mehtod 로 암호화 / 인코딩한 값 ● Signature Base String ● signature_mehtod 가 PLAINTEXT 인 경우 , parameter_encode([consumer_secret]&[token_secret]) ● 그 외 HMAC, RSA 를 사용할 경우 parameter_encode(hmac_or_rsa([all_parameters]))
    • oAuth 의 Signing request ● All Parameters ● oauth_consumer_key ● oauth_token ● oauth_signature_method ● oauth_signature ● oauth_timestamp ● oauth_nonce (to prevent 'reply attack') ● oauth_version (optional, default '1.0') ● addtional parameters
    • oAuth 인증요청 응답 에러 ● HTTP 400 Bad Request ● Unsupported parameter ● Unsupported signature method ● Missing required parameter ● Duplicated OAuth Protocol Parameter ● HTTP 401 Unauthorized ● Invalid Consumer Key ● Invalid / expired Token ● Invalid signature
    • Bonus : STOMP protocol
    • Streaming Text Orientated Messaging Protocol ● 스트리밍 메시지를 효과적으로 전송하기 위 한 프로토콜 ● Client / Message Broker ● TCP 를 기반으로 동작함 (SSL 포함 ) ● HTTP 와 유사한 방식 (coming from the HTTP school of design), 매우 간단한 프로토콜 ● http://stomp.codehaus.org/ 에서 오픈소스 프로젝트로 진행중 ● ActiveMQ 와 같은 잘 알려진 메시지 브로커에 서 지원
    • STOMP Connect Command - client request - - server response - CONNECT CONNECTED login: <username> session: <session-id> passcode:<passcode> ^@ ^@
    • STOMP Client Command ● SEND : 메시지 전송 ● SUBSCRIBE : 메시지 큐 구독 ● UNSUBSCRIBE : 메시지 큐 구독 해지 ● BEGIN : 트랜잭션 시작 ● COMMIT : 트랜잭션 커밋 ● ABORT : 트랜잭션 롤백 ● ACK : 큐에서 온 메시지에 응답 (acknowledge) ● DISCONNECT : 연결 종료
    • SEND/SUBSCRIBE SEND SUBSCRIBE destination:/queue/a destination: /queue/foo ack: client hello queue a ^@ ^@
    • UNSUBSCRIBE/BEGIN UNSUBSCRIBE BEGIN destination: /queue/a transaction: <transaction- identifier> ^@ ^@
    • COMMIT/ABOUT COMMIT ABORT transaction: <transaction- transaction: <transaction- identifier> identifier> ^@ ^@
    • ACK/DISCONNECT ACK DISCONNECT message-id: <message- identifier> ^@ transaction: <transaction- identifier> ^@
    • Rececipt header ● 클라이언트가 보내는 특정 명령에 서버가 어 떤 응답을 남기길 원하는 경우에 사용하는 헤 더 SEND destination:/queue/a receipt:message-12345 Hello a!^@
    • Sever Frame ● MESSAGE : 메시지를 담은 프레임 ● RECEIPT : receipt 헤더가 있는 프레임을 받았 을 경우에 응답해주는 프레임 ● ERROR : 에러 내용을 담은 프레임
    • MESSAGE/RECEIPT ACK RECEIPT MESSAGE receipt-id:message-12345 destination:/queue/a message-id: <message- ^@ identifier> hello queue a^@
    • ERROR ERROR message: malformed packet received The message: ----- MESSAGE destined:/queue/a Hello queue a! ----- Did not contain a destination header, which is required for message propagation. ^@