opens.kr

elasticsearch 데이터를 넣으면 데이터를 보고 알아서 필드 타입 대해서 정의 해주는데 

상황에 따라서 정수와 실수에 대한 정의 또는 int와 bigint에 대한 처리를 해줘야 될때가 있다 

그럴 경우 특정 필드에서 대해서 매핑 처리가 가능하다

아래 래퍼런스 사이트 참조

https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic-templates.html

샘플 데이터 : curl -XPUT localhost:9200/_template/stat --upload-file template.json

{  
   "order":0,
   "template":"stat-*",
   "settings":{  
      "index.refresh_interval":"5s"
   },
   "mappings":{  
      "_default_":{  
         "dynamic_templates":[  
            {  
               "long_fields":{  //long 필드타입로 지정
                  "match":"long_*",
                  "mapping":{  
                     "type":"long"
                  }
               }
            },
            {  
               "double_fields":{  //double 필드타입로 지정
                  "match":"double_*",
                  "unmatch":"*_text", //예외 처리 가능 레퍼런스보면 정규식형태도 있음
                  "mapping":{  
                     "type":"double"
                  }
               }
            },
            {  
               "string_fields":{ //string 필드에 대한 처리
                  "match_mapping_type":"string",
                  "match":"*",
                  "mapping":{  
                     "index":"analyzed",
                     "omit_norms":true,
                     "type":"string",
                     "fields":{  
                        "raw":{  
                           "index":"not_analyzed",
                           "ignore_above":256,
                           "type":"string"
                        }
                     }
                  }
               }
            }
         ],
         "_all":{  
            "enabled":true
         }
      }
   },
   "aliases":{}
}

auth_basic 의 경우 평문으로 패스워드가 전송되면서 해킹 위험있음

그 방안으로 SSL도 있지만 간단한 내부 웹사이트의 경우 http-auth-digest 로 활용하는 방안도 괜찮은 방법이다.

https://www.nginx.com/resources/wiki/modules/auth_digest/

nginx 다운로드

http://nginx.org/en/download.html

nginx-http-auth-digest 다운로드 ( 아래에서 받을것 그래야지 1.8이상에서 문제없다 )

https://github.com/atomx/nginx-http-auth-digest

$ tar xvfz nginx-1.8.0.tar.gz
$ unzip nginx-http-auth-digest-master.zip
$ cd nginx-1.8.0
$ ./configure --prefix=/data/nginx --conf-path=/etc/nginx/nginx.conf --user=www-data --group=www-data --with-http_ssl_module --add-module=../nginx-http-auth-digest-master 
$ make
$ make install

비번파일만들기

nginx-http-auth-digest 디렉토리보면 htdigest.py 파일이 존재함

$ python htdigest.py /etc/nginx/digest/www.digest admin admin_web

Conf 설정

auth_digest_user_file /etc/nginx/digest/www.digest;
auth_digest_shm_size 4m;
location / {
    auth_digest 'admin_web';
    auth_digest_timeout 60s;
    auth_digest_expires 10s;
    auth_digest_replays 20;
    proxy_pass http://localhost:8080/;
    proxy_redirect off;
}

kibana 에서 Unique Count 하는데 일상적으로 RDBMS에서 

SELECT DISTINCT(color) FROM cars

할때와 다르다

구글링 결과 아래 링크 참조 하면 이해가 될듯하다

https://www.elastic.co/guide/en/elasticsearch/guide/current/cardinality.html

The first approximate aggregation provided by Elasticsearch is the cardinality metric. This provides the cardinality of a field, also called a distinct or unique count. You may be familiar with the SQL version:

그래서 elasticsearch Distinct count 할 때 정밀도를 설정하는 부분이 있다

Practically speaking, a threshold of 100 maintains an error under 5% even when counting millions of unique values.

수치가 100의 경우 100만건 기준으로 5%로의 오차가 존재 할 수 있다고 한다.

참고하면 될듯함

http://nginx.org/en/docs/http/ngx_http_ssi_module.html

보통은 웹어플리케이션단에서 include 기능을 지원하기 때문에 별 의미가 없을 수 있지만

요즘 같이 api 서버 따로 만들고 웹UI 개발쪽에서 html / css 작업 개별로 할 경우에

굳이 ws에 추가 어플리케이션을 깔지 않고 nginx만으로도 아래와 같이 include가 구현이 가능하다.

 include

그 이외에도 다양한 Command 처리가 많으니까 참고하면 좋을 듯하다.

http://nginx.org/en/docs/http/ngx_http_sub_module.html

location / {
    sub_filter '<a href="http://127.0.0.1:8080/'  '<a href="https://$host/';
    sub_filter '<img src="http://127.0.0.1:8080/' '<img src="https://$host/';
    sub_filter_once on;
}

위와 같이 특정 url 주소를 라이브 환경과 개발환경등 서버 셋팅환경에 따라서 다르게 적용해야되는 경우 활용하기 좋다

특히 개발존에서 CDN URL 로 개발하고 실제 해당 url들은 내부개발망 자체 img 나 js url를 보도록 한다던지 하면 소스 업로드할 때 소스 수정부분을 덜 수 있는 방안중에 하나 이기도 하다.

물론 어플리케이션단에서 빌드시 자동화 해놓았다면 크게 신경 쓸 내용은 아니지만...

그리고 해당 모듈을 이용하기 위해서는 설치시 --with-http_sub_module 지정을 해줘야만 한다.  

http://nginx.org/en/docs/http/ngx_http_geo_module.html

nginx conf에서 아래 형태와 같이 각각의 아이피 별로 변수값을 지정 할 수 있다.

geo $geo {
    default        0;

    127.0.0.1      2;
    192.168.1.0/24 1;
    10.1.0.0/16    1;

    ::1            2;
    2001:0db8::/32 1;
}

그래서 해당 변수를 이용해서 아래와 같이 특정 아이피 경우 Rewrite 시킨다던지 location 처리를 다르게 등 여러 방안으로 이용 할 수 있다. 점검시에 내부 아이피만 처리하고 외부 아이피는 notice페이지로 리다이렉트 시키다던지등 상황에 따라서 잘 활용하면 좋을 듯하다.

if ( $request_uri ~ /test_page ){
    set $geo 1;
}

if ( $geo = 0 ){
   rewrite ^ /test_page?;
}

if ($geo = 2) {
    proxy_pass http://ttt;
    break;
}

https://github.com/felixge/node-mysql

Mysql 모듈 보면 CreatePool 후 Query 방식이 두가지가 있다.

Pooling connections

1번안

var mysql = require('mysql');
var pool  = mysql.createPool({
  connectionLimit : 10,
  host            : 'example.org',
  user            : 'bob',
  password        : 'secret'
});

pool.query('SELECT 1 + 1 AS solution', function(err, rows, fields) {
  if (err) throw err;

  console.log('The solution is: ', rows[0].solution);
});

2번안

var mysql = require('mysql');
var pool  = mysql.createPool(...);

pool.getConnection(function(err, connection) {
  // Use the connection
  connection.query( 'SELECT something FROM sometable', function(err, rows) {
    // And done with the connection.
    connection.release();

    // Don't use the connection here, it has been returned to the pool.
  });
});

차이점을 2번의 경우에는 커넥션을 하나 지정해서 해당 커넥션으로해서 쿼리를 처리하고 마지막에 해당 커넥션을 다사용했다고

반환해주는 방식이다.

단순히 일반 SELECT 쿼리 위주의 API 개발일 경우 1번안이 편할 수 있지만 트랜젹센처리나 INSERT 후 Last Insert Id 값을 가져오거나 Found_rows 같은 처리된 Row의 정보를 가져와야 할때는 2번안으로해서 같은 커넥션으로 처리 되어야지만 제대로 된 값을 가져 올 수 있다.

그리고 2번안의 경우 사용 후에 connection.release 해주지 않을 경우 반환하지 않아서 connection limit가 걸릴 수 있다. 

node.js v.0.5부터 json 파일 require()로 가져 올 수 있다.

그런데... 형식에 조금만 벗어나도 에러가 발생하는데.. 형식은... 잘 맞추면 되는데요..

문제는....주석을 넣어도 에러가 난다 orz 

( 당연히 다른 라이브러리나 file 읽어서 하는 방법도 있지만 기본 기능을 그대로 쓰고 싶음...)

$ vi test.js
var testJson = require('./test.json');
console.log(testJson);

$ vi test.json
{
    //comment test
    "key1":"test1",
    "key2":"test2",
}

$ node test.js
module.js:485
    throw err;
          ^
SyntaxError: /data/webroot/test.json: Unexpected token /
    at Object.parse (native)
    at Object.Module._extensions..json (module.js:482:27)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/data/webroot/test.js:1:78)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)

그래서 구글링 결과!!

http://stackoverflow.com/questions/244777/can-i-comment-a-json-file

{ //코멘트라는 키를 생성해버리면됨
   "_comment": "comment text goes here...",
   "glossary": {

{ //키명을 똑같이 해서 위에 설명을 넣어도될듯
  "api_host" : "The hostname of your API server. You may also specify the port.",
  "api_host" : "hodorhodor.com",

생각의 차이~!! 아래처럼 구분할 수있게 ㅎㅎ 어자피 해당 키는 안쓰면 되니까 ㅎㅎ

$ vi test.json
{
    "*****COMMENT*****" : "test comment",
    "key1":"test1",
    "*****COMMENT*****" : "test comment11",
    "key2":"test2",
    "*****COMMENT*****" : ""
}

$ node test.js
{ '*****COMMENT*****': '', key1: 'test1', key2: 'test2' }

 JSON Web Token (JWT) 

http://jwt.io/

- Restful API 설계과정에서 토큰 인증방식 고민하다가 보게된 JWT

구조는 아주 심플하고 간단함

1. 토큰 데이터의 구조

⇒ eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0MTIzMTIzNTQzNTM0NTY3ODkwIiwibmFtZSI6IkpvaDM0NTM0NTM0NW4gRG9lIiwiYWRtaW4iOnRydWV9.gUpPTlD6M3F264lbRyXa6lat7t1tqoP3MHOwFX1qies

1) 첫번째 인자 서명키 생성 방식에 대한 정보 (header) 

⇒ base64인코딩한 { "alg": "HS256",  "typ": "JWT" }

 : eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

2) 두번째 인자 실제 데이터 정보 (payload)

⇒ base64인코딩한 {  "sub": "1234123123543534567890", "name": "Joh345345345n Doe", "admin": true }

: eyJzdWIiOiIxMjM0MTIzMTIzNTQzNTM0NTY3ODkwIiwibmFtZSI6IkpvaDM0NTM0NTM0NW4gRG9lIiwiYWRtaW4iOnRydWV9

3) 세번째 인자 데이터에 대한 무결성 / 변조 방지를 위한 HMAC 

⇒ HMACSHA256(base64UrlEncode(header) + "." +base64UrlEncode(payload),ServerkeyData)

: gUpPTlD6M3F264lbRyXa6lat7t1tqoP3MHOwFX1qies

2. node.js 구현

- https://github.com/auth0/node-jsonwebtoken

※ 기타 언어 라이브러리 참고 http://jwt.io/#libraries

1) npm 설치

$ npm install jsonwebtoken
jsonwebtoken@5.0.2 node_modules/jsonwebtoken
└── jws@3.0.0 (jwa@1.0.0, base64url@1.0.4)

var jwt      = require('jsonwebtoken');
var tokenKey = "TEST_KEY11"; //토큰키 서버에서 보관 중요
var payLoad  = {'uid':14554};
var token = jwt.sign(payLoad,tokenKey,{
    algorithm : 'HS256', //"HS256", "HS384", "HS512", "RS256", "RS384", "RS512" default SHA256
    expiresInMinutes : 1440 //expires in 24 hours
});
console.log("token : ", token);

$ node jwt_test.js 
token :  eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1aWQiOjE0NTU0LCJpYXQiOjE0MzUxMzA4NzMsImV4cCI6MTQzNTIxNzI3M30.EWNUjnktCWxlqAAZW2bb0KCj5ftVjpDBocgv2OiypqM

2) jwt 토큰 디코딩

var jwt      = require('jsonwebtoken');
var tokenKey = "TEST_KEY11"; //토큰키 서버에서 보관 중요
var token = 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1aWQiOjE0NTU0LCJpYXQiOjE0MzUxMzA4NzMsImV4cCI6MTQzNTIxNzI3M30.EWNUjnktCWxlqAAZW2bb0KCj5ftVjpDBocgv2OiypqM';

//비동기처리
jwt.verify(token,tokenKey,function(err,decoded){
    console.log("sync : ", decoded);
});

//동기처리
try {
    var decoded = jwt.verify(token,tokenKey);
    console.log("async : ", decoded);
} catch(err){
    console.log(err);
}

$ node jwt_test_decoded.js
async :  { uid: 14554, iat: 1435130873, exp: 1435217273 }
sync :  { uid: 14554, iat: 1435130873, exp: 1435217273 } 
//실행은 sync가 먼저 되었지만 비동기 방식이므로 더 뒤에 출력됨

참고사이트

https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

http://bcho.tistory.com/999

http://bcho.tistory.com/1000

프로시져 내부에 SELECT 구문이 여러개 있어서 output row을 여러개 받아야 할 경우 예시

1. 프로시져 ( MSSQL 기준 작성함...)

CREATE PROCEDURE [dbo].[spTest]
AS
BEGIN
SELECT TOP 2 log_id FROM testLog ;
SELECT TOP 2 log_id FROM testLog ;
END

2. PHP 코드

<?php
  $stmt = $conn->prepare("exec spTest");
  $stmt->execute();
  $results = array();
  do {
    $results[] = $stmt->fetchAll();
  }while ($stmt->nextRowset());
  print_r($results);
?>

3. 결과셋

Array
(
    [0] => Array
        (
            [0] => Array
                (
                    [log_id] => 1
                    [0] => 1
                )
           [1] => Array
                (
                    [log_id] => 2
                    [0] => 2
                )
        )
    [1] => Array
        (
            [0] => Array
                (
                    [log_id] => 1
                    [0] => 1
                )
            [1] => Array
                (
                    [log_id] => 2
                    [0] => 2
                )
        )
)

※ 위에 예시는 거의 사용할 일이 크게 없었으며....

   아래 참고사이트에 보면 나오듯이... 게시물에 total값 별도로 output 이나 리턴 받고.. 

   요청하는 범위에 게시물의 row 수를 받을때 사용하는 일이 더 많은 듯하다....

참고사이트 

http://trentrichardson.com/2011/08/10/making-sense-of-stored-procedures-with-php-pdo-and-sqlsrv/

http://www.joeyrivera.com/2009/using-mysql-stored-procedure-inout-and-recordset-w-php/