[화면설계] 항목

1. 메인페이지
- 검색메뉴
- 즐겨찾기 항목
- 로그인버튼
등등

2. 로그인 창
- ID/PW
- 로그인버튼
- 회원가입
- ID/PW 찾기
등등

3. 메뉴바
- 설정창
- 회원정보
- 알림
- 즐겨찾기

3. 설정창
- 회원정보 메뉴
- 알림메뉴("구독" 등 알림메뉴.. 가능할까...?)

4. 회원정보 창
- 정보 출력창 (수정창으로 통합? or "수정하기"버튼?)
- 정보 수정창

5. 알림창
- 즐겨찾기나 구독으로 추가한 동영상에 대한 업로드 알림 설정
 (예. 팝업알림, 소리알림, 등등..)

6. 즐겨찾기 창
- 그룹 추가/수정/삭제
- 즐겨찾기 한 동영상 리스트

7. 검색결과 창
- 검색메뉴
- 상세검색바(결과내 검색)
- 동영상 리스트

[DB] DB 스키마

*사용 DB : MySQL
*DB 명 : db_pocket_tube

[정책]
1. 사용자가 탈퇴해도 해당 사용자에 대한 정보는 바로 지워지지 않고 tbl_member의is_joinout필드의 값을 1(true)로 수정한다.
2. 사용자가 비밀번호를 찾을때는 id, birth_date

[테이블 상세]
1. tbl_member
: 사용자 정보 테이블
필드명
타입
제약조건
설명
index
Int(32)
P.K.
Auto_increment
Not NULL
해당 테이블의 인덱스필드
id
Varchar(32)
Not NULL
사용자 id
(email 형식)
passwd
Varchar(32)
Not NULL
사용자 비밀번호
birth_date
DateTime
Not NULL
사용자의 생년월일
reg_date
DateTime
Not NULL
사용자가 서비스에 가입한 날짜
is_joinout
Int(1)
Default : 0
Not NULL
탈퇴여부

2. tbl_member_info
: 사용자의 추가 정보 테이블(가령 설정내용 등등)
필드명
타입
제약조건
설명
index
Int(32)
P.K.
Not NULL
tbl_member의 index값과 동일한 값
(auto_increament 속성을 사용하지 않음)
is_push
Int(1)
Not NULL
서비스의 push(알림)서비스

3. tbl_favorite
: 동영상 즐겨찾기 관련 테이블
필드명
타입
제약조건
설명
index
Int(32)
P.K.
Not NULL
auto_increament
tbl_member의 index값과 동일한 값
(auto_increament 속성을 사용하지 않음)
member_index
Int(32)
F.K.
Not NULL
Tbl_member의 사용자정보와 매필될index
url
varchar(128)
Not NULL
url 정보
reg_date
date_time
Not NULL
즐겨찾기를 등록한 날짜
group_num
Int(8)
Default : 0
Not NULL
즐겨찾기 항목에대하여 폴더구조를 가질시에 해당 필드로 구분
(아직 큰 의미는 없음)


저작자표시 비영리 변경금지

'Development > Web' 카테고리의 다른 글

[웹서비스] 기초 2 - 웹 서비스 기반기술  (0) 2015.04.28
[웹서비스] 기초 1 - 웹 서비스 개요  (0) 2015.04.28
[java study] 4차 스터디 정리 20150131  (0) 2015.04.21
[YouTube API] playlist, playlistitem, search result, subscription  (0) 2015.04.21
[AOuth2.0] Youtube API 관련  (0) 2015.04.21

playlist

단일 YouTube 재생목록을 표시합니다. 재생목록은 순서대로 감상하거나 다른 사용자와 공유할 수 있는 동영상의 모음입니다.

  https://developers.google.com/youtube/v3/docs/playlists


- 최대 목록 갯수 : 200개
- 메소드 :
  1. list : API 요청 매개변수와 일치하는 재생목록의 모음을 반환합니다. 예를 들어 인증된 사용자가 보유한 전체 재생목록을 검색하거나, 고유 ID를 통해 하나 또는 여러 개의 재생목록을 검색할 수 있습니다. 
    https://developers.google.com/youtube/v3/docs/playlists/list#try-it
  2. insert : 재생목록을 만듭니다. 
    https://developers.google.com/youtube/v3/docs/playlists/insert#try-it
  3. update : 재생목록을 수정합니다. 예를 들어 재생목록의 제목, 설명, 개인정보 보호 상태를 변경할 수 있습니다.
    https://developers.google.com/youtube/v3/docs/playlists/update#try-it
  4. delete : 재생목록을 삭제합니다. 
    https://developers.google.com/youtube/v3/docs/playlists/delete#try-it

playlistItem

재생목록에 포함된 동영상과 같은 리소스를 식별합니다. 
playlistItem 리소스에는 포함된 리소스가 재생목록에서 사용되는 방식을 설명하는 세부정보도 포함되어 있습니다.

- 메소드 
  1. list : API 요청 매개변수와 일치하는 재생목록 항목의 모음을 반환합니다. 지정된 재생목록의 모든 항목을 검색하거나 고유 ID를 통해 하나 또는 여러 개의 재생목록 항목을 검색할 수 있습니다.
    https://developers.google.com/youtube/v3/docs/playlistItems/list#try-it
  2. insert : 재생목록에 리소스를 추가합니다. 
    https://developers.google.com/youtube/v3/docs/playlistItems/insert#try-it
  3. update : 재생목록의 항목을 수정합니다. 예를 들어 재생목록에서 항목의 위치를 업데이트할 수 있습니다.
    https://developers.google.com/youtube/v3/docs/playlistItems/update#try-it
  4. delete : 재생목록의 항목을 삭제합니다. 
    https://developers.google.com/youtube/v3/docs/playlistItems/delete#try-it

search result

API 요청에 지정된 검색 매개변수와 일치하는 YouTube 동영상, 채널 또는 재생목록의 정보를 포함합니다. 검색 결과는 동영상과 같이 고유하게 식별할 수 있는 리소스를 보여주지만, 자체적으로는 영구적인 데이터를 가지지 않습니다.

- 메소드
  1. list : 기본적으로 검색결과의 집합은 쿼리 매개변수와 일치하는 video, channel, playlist 리소스를 식별하지만, 특정 유형의 리소스만 검색하도록 쿼리를 구성할 수도 있습니다
    https://developers.google.com/youtube/v3/docs/search/list

subscription

YouTube 사용자의 구독 정보를 포함합니다. 구독정보는 채널에 새 동영상이 추가되거나 다른 사용자가 YouTube에서 동영상 업로드, 동영상 평가 또는 동영상 추천 등의 작업 중 하나를 수행할 때 이를 알려줍니다.

- 메소드 
  1. list : API 요청 기준과 일치하는 구독정보 리소스를 반환합니다.
    https://developers.google.com/youtube/v3/docs/subscriptions/list#try-it
  2. insert : 인증된 사용자 채널에 대한 구독정보를 추가합니다.
    https://developers.google.com/youtube/v3/docs/subscriptions/insert#try-it
  3. delete : 구독정보를 삭제합니다. 
    https://developers.google.com/youtube/v3/docs/subscriptions/delete#try-it


저작자표시 비영리 변경금지

'Development > Web' 카테고리의 다른 글

[웹서비스] 기초 2 - 웹 서비스 기반기술  (0) 2015.04.28
[웹서비스] 기초 1 - 웹 서비스 개요  (0) 2015.04.28
[java study] 4차 스터디 정리 20150131  (0) 2015.04.21
[pocket tube] 화면설계 항목 및 DB 설계  (0) 2015.04.21
[AOuth2.0] Youtube API 관련  (0) 2015.04.21

<OAuth 2.0>

[개요]
- 모바일, 플랫폼의 시대가 도래하면서(Open API) 데이터는 REST&JSON 포맷을 기반으로하여 API를 제공
- 인증방식은 OAuth2.0을 사용

[OAuth 1.0a]
- OAuth 1.0 : 트위터를 비롯한 웹 개발자들이 API인증 및 로그인한 사용자에 대한 권한부여를 동시에 제공하도록 하는 인증 프로토콜
- 2007년 10월 OAuth1.0 출시(보안결함)
- 2009년 OAuth 1.0a 발표 (정식 "The OAuth 1.0 Protcol")

- 장점
  a. API 인증 시 써드파티 어플리케이션에게 사용자의 비밀번호를 노출하지 않고 인증가능
  b. 인증과 API권한부여를 동시에 할 수 있음

- 동작방식
 : user / consumer / service provider

                                   <OAuth 1.0a 트라이앵글>

  : 3-legged OAuth라고도 함
  a. user : 트위터사용자
  b. consumer : 트위터 단말 어플리캐이션
  c. service provider : 트위터 API 서비스


  #가설 ?
    새로운 어플을 다운받았으나, 신뢰할 수 없다. (어떤짓을 할지 몰라~)
    이때 인증토큰을 사용하여 인증을 하게됨

[인증토큰]
- 인증이 완료되면 컨슈머(예, PocketTube)는 인증 토큰을 받게된다.
- 특징
   a. 컨슈머가 사용자의 id/pw를 가지지않고 API를 사용할 수 있음
   b. 필요한 API에만 제한적으로 접근할 수 있도록 권한제어가 가능
   c. 사용자가 서비스 프로바이더(예, YouTube)의 관리페이지에서 권한 취소가 가능
   d. 패스워드 변경 시에도 인증 토큰은 계속 유효함

   (※ c번의 유용한 점? 사용자가 핸드폰을 잃어버렸을때, 서비스프로바이더의 관리페이지에서 어플리케이션 인증을 취소할수 있다.)


[OAuth 2.0]
* OAuth 1.0a와 호환이 않되고 사용되는 언어부터 시작해 많은 것들이 다름

- 거의 초기부터 IETF 표준 프로세스 안에서 만들어지고 있음.
- 2010년 4월부터 등록됨
- 모바일에서의 OAuth1.0a의 불편함, signature 생성의 복잡함, 과한 CPU 소비, 기능과 규모의 확장성을 지원하기 위해 만들어짐
- 정식명칭 "OAuth 인증 프레임워크" ("The OAuth 2.0 Authorization Framework")

- 개선사항
  a. 사용함에 있어서 간단해짐
  b. 더 많은 인증방법을 지원(웹브라우저, 모바일 등 다양한 시나리오에 대응이 가능)
  c. 대형 서비스로의 확장성 지원

- 용어
  a. Resource Owner : 사용자
  b. Resource Server : API 서버
  c. Authorization Server : 인증서버(API와 같을 수도 있음)
  d. Client : 써드파티 어플리케이션

[대표적 서비스 프로바이더]


[OAuth 2.0 인증방식]
- 3-legged를 비롯하여 2-legged등 다양한 인증 방식 지원
- but, 기본은 3-legged

  a. Authorization Code Grant
   - 웹 서버에서 API를 호출하는 등의 시나리오에서 Confidential Client가 사용하는 방식
   - 로그인시 페이지 url에 response_type=code라고 넘김

  b. Implicit Grant
   - 브라우저 기반의 어플리케이션이나 모바일 어플리케이션에서 사용하는 방식
   - Client 증명서를 사용할 필요가없고, 실제로 가장 많이 사용하는 방식
   - 로그인시 페이지 url에 response_type=token이라고 넘김

  c. Password Credentials Grant
   - 2-legged방식
   - Client에 id/pw를 저장해놓고 id/pw로 직접 access token을 받아오는 방식
   - client를 믿을 수 없을때에는 사용하기에 위험이 있음
   - 로그인시 API에 POST로 grant_type=password라고 넘김

  d. Client Credentials Grant
   - 어플리케이션이 Confidential client일때 id와 secret을 가지고 인증하는 방식
   - 로그인시 API에 POST로 grant_type=client_credentials라고 넘김

  e. Extension
   - 추가적인 인증방식을 적용할 수 있도록 함

[다양한 토큰 지원]
  - 기본적으로는 Bearer토큰, 즉 암호화하지 않은 그냥 토큰(HTTPS를 사용하여 HTTPS의 암호화에 의존)
  - 다른 토큰 방식도 지원하지만 거의 안씀

  - "Refresh Token"
   : 같은 access token을 오래 사용시, 노출 위험이 있으므로 refresh token개념을 도입
   : 만료기간을 짧게하고 refresh token으로 access token을 갱신


저작자표시 비영리 변경금지

'Development > Web' 카테고리의 다른 글

[웹서비스] 기초 2 - 웹 서비스 기반기술  (0) 2015.04.28
[웹서비스] 기초 1 - 웹 서비스 개요  (0) 2015.04.28
[java study] 4차 스터디 정리 20150131  (0) 2015.04.21
[pocket tube] 화면설계 항목 및 DB 설계  (0) 2015.04.21
[YouTube API] playlist, playlistitem, search result, subscription  (0) 2015.04.21

+ Recent posts

티스토리툴바