Skip to content

Commit 1afeaef

Browse files
author
Owen Barnes
committed
Merge branch 'master' of github.com:socketstream/socketstream
2 parents 970614a + d2017fc commit 1afeaef

10 files changed

+1199
-0
lines changed

‎doc/guide/ko/authentication.md

+159
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,159 @@
1+
<!---# Authentication-->
2+
# 인증
3+
4+
<!--Users can be authenticated in two ways: over the websocket or over HTTP.-->
5+
인증은 웹소켓이나 HTTP으로 할수 있습니다.
6+
7+
<!--The first option is useful if you're authenticating against a backend database or other resource you control, the second if you're using a third-party service such as Facebook Connect.-->
8+
첫번째 방법은 직접 관리하시는 데이터베이스나 리소스에 인증하고 있을때 유용하고, 두번째 방법은 페이스북같은 외부 인증을 사용할때 유용합니다.
9+
10+
<!--Either way, the goal is the same: to update `req.session.userId` with the user's unique ID.-->
11+
어떤 방법이든 '`req.session.userId`에 사용자 고유의 ID를 넣고 싶다.'라는 목표는 같습니다.
12+
13+
<!---### Authenticating over websockets-->
14+
### 웹소켓을 통한 인증
15+
16+
<!--This is the best choice if you're authenticating against an internal database or LDAP server, etc.-->
17+
내부의 데이터베이스 또는 LDAP서버 등 에 인증하고 있다면 이것이(웹소켓이) 최고의 선택일 거에요.
18+
19+
```javascript
20+
// server/rpc/app.js
21+
exports.actions = function(req, res, ss){
22+
23+
// SocketStream에게 session 데이터를 로드하도록 명령
24+
req.use('session');
25+
26+
return {
27+
authenticate: function(username, password){
28+
29+
// BD, LDAP, 등에서 사용자 확인
30+
31+
if (user) {
32+
req.session.setUserId(user.id);
33+
res(true);
34+
} else {
35+
res('Access denied!');
36+
}
37+
38+
}
39+
}
40+
}
41+
42+
```
43+
<!--
44+
// tell SocketStream to load session data
45+
// lookup user in DB, LDAP, etc
46+
-->
47+
<!--Note: You could just set`req.session.userId` manually, but calling the `req.session.setUserId()` function saves the session and notifies SocketStream to immediately start sending events for this user (sent using `ss.publish.user()`) over the current websocket connection.-->
48+
주의: 당신이 `req.session.userId`을 그냥 수동으로 바꿀 수도 있지만, 그렇게 하기보단 `req.session.setUserId()`를 호출해 세션을 저장하고 현재의 웹소켓 연결을 사용하여 SocketStream에게 이 유저의(`ss.publish.user()`를 사용하여 전송) 이벤트 전송이 시작됬음을 알리는게 좋습니다.
49+
50+
<!---### Authenticating using HTTP-->
51+
### HTTP이용한 인증
52+
53+
<!--Since the same session object is also available over HTTP you may easily authenticate a user by updating `req.session.userId` whilst processing a HTTP request.-->
54+
같은 세션 객체는 HTTP를 통하여도 가능하기 때문에 HTTP Request를 처리하는 동안 `req.session.userId`을 변경하여 인증할 수 있습니다.
55+
56+
<!--Let's look at a very simple example by adding the following 'route' to `app.js`:-->
57+
다음에 나오는 'route'를 `app.js`에 추가한 매우 쉬운 예제를 봅시다:
58+
59+
```javascript
60+
// app.js
61+
ss.http.router.on('/authenticateMe', function(req, res) {
62+
req.session.userId = '나솔';
63+
req.session.save(function(err){
64+
res.serve('main');
65+
});
66+
});
67+
```
68+
69+
<!--Next, add an RPC action which sends the contents of `req.session.userId` over the websocket:-->
70+
다음으로 웹소켓을 통해 `req.session.userId`의 컨텐츠들를 전송하는 RPC를 추가합니다.
71+
72+
```javascript
73+
// server/rpc/app.js
74+
exports.actions = function(req, res, ss){
75+
76+
// SocketStream에게 session 데이터를 로드하게 명령
77+
req.use('session');
78+
79+
return {
80+
81+
getCurrentUser: function(){
82+
res('현재 사용자는 ' + req.session.userId + '님 입니다.');
83+
}
84+
85+
}
86+
};
87+
```
88+
<!---// tell SocketStream to load session data-->
89+
90+
<!--Now visit `http://localhost:3000/authenticateMe` then enter the following command in the browser's console:-->
91+
이제 `http://localhost:3000/authenticateMe` 가서 브라우저 콘솔에 다음 명령을 실행해보세요:
92+
93+
ss.rpc('app.getCurrentUser')
94+
95+
<!--And you'll see the following output:-->
96+
그러면 다음 결과가 출력 됩니다:
97+
98+
현재 사용자는 나솔님 입니다.
99+
100+
<!---### Using Everyauth for Facebook Connect, Twitter, Github etc-->
101+
### Facebook Connect, Twitter, Github 등의 위한 Everyauth 사용
102+
103+
<!--SocketStream integrates well with popular authentication libraries such as [Everyauth](https://github.com/bnoguchi/everyauth).-->
104+
SocketStream은 [Everyauth](https://github.com/bnoguchi/everyauth)같은 널리쓰이는 인증 라이브러리들과 잘 통합됩니다.
105+
106+
<!--Tip: Don't be tempted to follow the docs on the Everyauth website too closely - they are mainly geared at multi-page apps and/or specific to Express.-->
107+
팁: Everyauth 웹사이트의 문서를 너무 자세히 따르지 마세요 - 그것들은 주로 여러페이지를 가진 어플리케이션에 적합한 내용이거나 Express를 위한 겁니다.
108+
109+
<!--Here's an example of a full app which authenticates against Twitter's OAuth service.-->
110+
트위터의 oAuth서비스에 대한 인증을 하는 전체 app의 예제입니다.
111+
112+
<!--To get started, register your new app at https://dev.twitter.com/apps/new-->
113+
시작하기전에 https://dev.twitter.com/apps/new 에서 당신의 새 앱을 등록하세요.
114+
115+
<!--When testing your app supply `http://127.0.0.1:3000` as the Callback URL. Change this to the real URL when your app goes into production.-->
116+
당신의 앱을 테스트 할때 콜백 URL로 `http://127.0.0.1:3000`이 제공됩니다. 당신을 앱을 제품으로 만들때 할때 이것을 실제 URL로 변경해야 합니다.
117+
118+
```javascript
119+
// app.js
120+
var http = require('http')
121+
, ss = require('socketstream')
122+
, everyauth = require('everyauth');
123+
124+
ss.client.define('main', {
125+
view: 'app.jade',
126+
css: ['libs', 'app.styl'],
127+
code: ['libs', 'modules', 'main']
128+
});
129+
130+
ss.http.router.on('/', function(req, res) {
131+
res.serve('main');
132+
});
133+
134+
everyauth.twitter
135+
.consumerKey('여기에 CONSUMER ID 를 입력')
136+
.consumerSecret('여기에 CONSUMER SECRET 를 입력')
137+
.findOrCreateUser( function (session, accessToken, accessTokenSecret, twitterUserMetadata) {
138+
var userName = twitterUserMetadata.screen_name;
139+
console.log('트위터 유저이름: ', userName);
140+
session.userId = userName;
141+
session.save();
142+
return true;
143+
})
144+
.redirectPath('/');
145+
146+
ss.http.middleware.prepend(ss.http.connect.bodyParser());
147+
ss.http.middleware.append(everyauth.middleware());
148+
149+
var server = http.Server(ss.http.middleware);
150+
server.listen(3000);
151+
152+
ss.start(server);
153+
154+
// http://local.host:3000/auth/twitter 에서 인증해볼수 있습니다.
155+
```
156+
<!--// To authenticate visit http://local.host:3000/auth/twitter-->
157+
158+
<!--Many more details on this and other examples coming soon.-->
159+
인증에 대한 더 상세한 설명과 예제들이 곧 나올꺼에요.

‎doc/guide/ko/client_side_code.md

+97
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,97 @@
1+
# 클라이언트측 코드
2+
<!---# Client-Side Code-->
3+
4+
소켓스트림은 구조화된 클라이언트 측 자바스크립트를 서버 측 코드와 완벽히 동일한 방법으로 작성할수 있게 합니다. 양쪽의 모듈 공유도 쉽게 하구요.
5+
<!--SocketStream allows you to write and structure client-side Javascript in exactly the same way as server-side code, allowing you to easily share modules between both.-->
6+
7+
### 모듈사용하기
8+
<!---### How to use Modules-->
9+
10+
`libs`(아래 참조)디렉토리에 있지 않은 모든 파일은 모듈로 취급됩니다. 모듈은 서버쪽의 노드와 같은 감각으로 사용할 수 있습니다. 다른 모듈을 `require()`하는것도 모듈안에서 값을 케싱하는 것도요.
11+
<!--All files which aren't `libs` (see below) are treated as modules. You have exactly the same ability to export functions, `require()` other modules, and cache values within modules as you do when writing server-side code in Node.js.-->
12+
13+
클라이언트 측 코드는 `/client/code`에 있습니다. 원하는 만큼 서브디렉토리를 만드셔도 됩니다. 모듈 참조는 상대패스로 할수도 있고(예를들면`require('../../image/processor')`) 절대패스로도(`require('/path/to/my/module.js')`) 할 수 있습니다. 전부 원하시는대로 움직일 겁니다. 단지 요청(`require()`)하지않은 모듈은 실행하지 않는것만 기억해두세요.
14+
<!--Client-side code lives in `/client/code`. Create as many subdirectories as you wish. Reference your modules relatively, e.g. `require('../../image/processor')`, or absolutely `require('/path/to/my/module.js')`. It all work as you would expect, just bear in mind a module will never be executed unless it is explicitly `require()`'d.-->
15+
16+
팁: 브라우저 콘솔에서 `require.modules`을 쳐보면 `require()`가능한 모든 모듈의 목록을 보실수 있습니다.
17+
<!--Top tip: Type `require.modules` in the browser console to see a list of all modules you can `require()` in your app-->
18+
19+
20+
### 특별한 예외
21+
<!---### Special Exceptions-->
22+
23+
브라우져와 서버를 퇴대한 비슷하게 하려고 노력하고 있지만, 아직 몇가지 특별한 경우가 있습니다:
24+
<!--While we try to keep the experience between browser and server as similar as possible, there are a few special cases to be aware of:-->
25+
26+
27+
#### 'libs' - 오래된 (커먼js가 아닌) 라이브러리들
28+
<!---#### 'libs' - Legacy (non Common JS) Libraries-->
29+
30+
'libs'안에 있는 어떤 파일도 모듈로 취급되지 **않습니다.** 대신에 있는 어떤 수정도 없이 그대로 전송됩니다. 일반적으로 `window`오브젝트를 사용하는 제이쿼리나 다른 라이브러리는 `/client/code`안의 'libs'디렉토리에 둡니다.
31+
<!--Any file which lives in a directory called 'libs' will NOT be served as a module. Instead these files will be sent as-is without any modification. Typically you'll want to ensure jQuery and other libraries which use the `window` variable are always placed in a `/client/code` directory called 'libs'.-->
32+
33+
Common JS라이브러리가 아닌 파일은 로드 순서가 매우 중요하므로 다음 둘 중에 하나는 하셔야 합니다. `libs`아래의 파일을 알파벳 순서로 정렬 해두던가(역주: 숫자도 좋음 `1_xxxx.js`, `2_xxxx.js`) `ss.client.define()`명령으로 명시적으로 각파일의 로딩순서를 적으세요.
34+
<!--As load order is critically important for non Common JS libraries **either** name your files alphanumerically within the `libs` directory **or** list each file explicitly in your `ss.client.define()` command - your choice.-->
35+
36+
37+
#### 'system' - 시스템 모듈
38+
<!---#### 'system' - System Modules-->
39+
40+
시스템 모듈은 일반 모듈과 비슷하지만 한가지 중요한 차이점이 있습니다: 그건 / 없이 접근 할수있다는건데요. 노드js의 `require('url')` 나 `require('querystring')`를 생각하시면 이해하기 편하실꺼에요.
41+
<!--System modules are similar to regular modules but with one important difference: they are accessed without a leading slash - just like you would `require('url')` or `require('querystring')` in Node.js.-->
42+
43+
근데 왜 이런 구별이 필요할까요? 왜냐하면 Backbone.js같은 라이브러리('libs' 디렉토리에 넣기보단 모듈로써 사용하고 싶을때)는 시스템 모듈에 의존하기 때문입니다. 이런 경우 백본은 `require('underscore')`를 내부적으로 요청합니다. 따라서 `backbone.js`랑 `underscore.js`는 `system`디렉토리에 있어야 하죠.
44+
<!--So why do we need this distinction? Because some libraries such as Backbone.js (when used as a module, rather than in a 'libs' directory) depend upon other system modules. In this case Backbone calls `require('underscore')` internally, therefore both `backbone.js` and `underscore.js` must live in a `system` directory.-->
45+
46+
소켓스트림은 [Browserify](https://github.com/substack/node-browserify)의 코드를 사용하기 때문에, 'system'디랙토리도 노드의 inbuilt 모듈을 브라우저에서 사용할 수 있습니다. https://github.com/substack/node-browserify/tree/master/builtins 로 가셔서 라이브러리를 복사해서 `system`을 부르는 `/client/code` 아무데나 붙여 넣으세요.
47+
<!--As SocketStream uses code from [Browserify](https://github.com/substack/node-browserify), the 'system' directory also allows you to use one of Node's inbuilt modules in the browser. Just head over to https://github.com/substack/node-browserify/tree/master/builtins and copy the libraries you need into any directory within `/client/code` called `system`.-->
48+
49+
50+
#### '/entry.js' - 항목 관리자
51+
<!---#### '/entry.js' - A single point of entry-->
52+
53+
`/entry` 모듈은 특별한 차이점이 있는 일반 모듈입니다: 이 모듈은 모든 파일이 브라우저에 전송된 시점에서 자동으로 요청되는 단 하나의 모듈입니다.
54+
<!--The `/entry` module is a regular module with a special distinction: it is the only module to be required automatically once all files have been sent to the browser.-->
55+
56+
`entry.js` (아니면 `entry.coffee`) 파일은 프로젝트를 만들때 자동적으로 생성됩니다. 이 파일엔 아주 조금의 셈플 코드가 들어있어, 아마도 이걸 수정해웹소켓 연결이 끊어지거나, 재연결 되거나, 다음 웹소켓 연결이 이루어지면 `require()`할 모듈을 설정하거나 할수있습니다.
57+
<!--The `entry.js` (or `entry.coffee`) file is created for you by default when you make a new project. It contains a small amount of boiler-plate code which you may modify to handle the websocket connection going down, reconnecting, and (critically), what module to `require()` next once the websocket connection is established.-->
58+
59+
60+
### 라이브러리가 'libs' 에 들어갈지 'system'에 들어갈지는 어떻게 구별해야 할까요?
61+
<!---### Should I put library X in 'libs' or 'system'?-->
62+
63+
그건 `window`값에 접근하는가에 달려있습니다. 예를들어, Backbone.js는 Backbone.history를 사용해`window`객체를 접근하지 않는 이상 `system`에서 잘 작동합니다.
64+
<!--It depends if it needs access to the `window` variable. For example, Backbone.js works great as a `system` module unless you're using Backbone.history as this requires access to `window`.-->
65+
66+
67+
### 없는 모듈을 요청하면 어떤 일이 생기나요?
68+
<!---### What happens if I try to require a module which doesn't exist?-->
69+
70+
브라우저 콘솔에서 에러를 보실수 있습니다. 앞으로는 소켓스트림에서 그런 일이 발생하기 전에 잡을수 있게 할 생각입니다.
71+
<!--You'll see an error in the browser's console. In the future SocketStream will be able to catch these problems before they arise.-->
72+
73+
74+
### 맞춤형 모듈 로딩
75+
<!---### Loading modules on demand-->
76+
77+
모든 모듈을 한번에 브라우저에 보낼 필요는 없습니다. [필요할 때 로딩](https://github.com/socketstream/socketstream/blob/master/doc/guide/en/loading_assets_on_demand.md)하게 할 수도 있어요.
78+
<!--You don't necessarily have to send all modules to the browser at once, you can also [load them on demand](https://github.com/socketstream/socketstream/blob/master/doc/guide/en/loading_assets_on_demand.md).-->
79+
80+
81+
### 배경 정보
82+
<!---### Background info-->
83+
84+
클라이언트 코드를 바로잡자는 것은 소켓스트림 프로젝트를 시작했을 때 소켓스트림의 중요한 목표중 하나였습니다.
85+
<!--Getting client-code right was a major goal for SocketStream from the beginning.-->
86+
87+
웹 개발자들은 너무나 오랫동안 네임스페이스와 의존성을 관리할 방법이 없는 체로 구조화되지 않은 자바스크립트 파일 더미와 씨름해야만 했습니다.
88+
<!--For too long web developers have had to wade through a mess of unstructured JavaScript files without anyway to manage namespacing or dependencies.-->
89+
90+
이런 혼돈스러운 상태에서, [Require.js](http://requirejs.org)같은 해결책과 다른 AMD 접근법은 어느정도 질서를 가져올 수 있었습니다만, 개발자들에게 의존성을 수동으로 목록을 만들고 추적해야하는 책임이 생겨 버렸습니다. 더 문제인 점은, 클라이언트와 서버에서 파일을 `require()`하고 싶을때 각각 다른 문법으로 하고 있었다는 점입니다. - 이것 때문에 클라이언트 와 서버의 파일공유하려는 시도는 꿈도 꿀 수 없었죠.
91+
<!--Solutions such as [Require.js](http://requirejs.org) and other AMD approaches have successfully brought order to chaos, but put the onus on the developer to manually track and list dependencies. What's more, they use a different syntax to `require()` files - instantly killing all hopes of sharing the same file between the client and server.-->
92+
93+
소켓스트림에서는 좀 더 잘하고 싶었습니다. 결국, 소켓스트림은 클라이언트와 서버 스택을 모두 관리하는 독특한 프레임워크가 되어 버렸습니다. 이 솔루션은 [Browserify](https://github.com/substack/node-browserify) 덕분입니다. - 멋지고, 가볍고, 모든 문제를 한방에 해결해주는 라이브러리 였지요.
94+
<!--We wanted to do much better with SocketStream. After all, we are in the unique position of managing both the client and server stack. The solution came in the form of [Browserify](https://github.com/substack/node-browserify) - an awesome, lightweight, library which solves all these problems once and for all.-->
95+
96+
소켓스트림은 Browserify 를 `package.json`에 추가하고 그 위에 구현을 추가하는 방식으로 개발하지는 않았습니다. 왜냐하면 거기에 우리가 필요없는 코드가 들어있었거든요, 하지만 우리는 거기에서 핵심 컴포넌트를 가져왔습니다.(`require()`라는 마법을 가능하게 해주는 핵심 코드를 포함해서요.) 이 까다로운 문제에 대한 깔끔한 해결책을 주신 Substack에게 감사합니다.
97+
<!--SocketStream doesn't depend upon the Browserify module (as it contains code we don't need), but we use major components from it (including the critical code which performs all the `require()` magic). Our thanks go to Substack for coming up with a clean solution to a very tricky problem.-->

0 commit comments

Comments
 (0)