outpost on azure
아이폰으로 50연 하다가 안 나오길래 플롯폼을 바꿔서 PC판, 안드로이드판(Nox) 로 해봤는데…
PC판은 그냥 형편없는 결과가 나왔고, Nox 가 대박을 침.
ㅋㅇ 이것으로 이번 콜라보도 컴플리트했다. 저번 주문토끼도 한 80연 했던 것 같으니 비슷하게 든 듯. 처음에 4성이긴 하지만 원하지는 않았던 멤버(주문토끼 때는 츠무기, 이번에는 아이리)가 나왔던 것도 비슷하고… 지난번 때에는 3성인데도 거의 끝나기 직전에 겨우 먹었던 것을 생각하면 이번에는 4성이라 혹시 못 먹는 것이 아닌가 걱정을 많이 했었는데 정말 다행이다.
얼마 전엔 Adblock Plus 를 대신에 uBlock Origin 을 설치한 이야기를 썼었었다. 그런데 이번에는 NoScript(이하 NS) 도 제거했다. NS는 여러가지 불편한 점이 많았지만 그래도 원하지 않는 스크립트 및 플러그인을 차단하고 이를 선택적으로 허용할 수 있다는 점에서 오랫동안 사용해왔었다.
그런데 며칠 전부터 이 NS가 오작동했다. 문제는 아이콘의 오동작인데, 스크립트가 차단되어 있음에도 모두 허용된 것으로 표시되거나 혹은 그 반대인 현상이 발생한 것이다. 최근에 문제가 발생한 점에서 uBlock 과 관련이 있지 않을까 싶어서 이를 비활성화 해보니 NS의 문제가 해결되는 것이 확인되었다. 설치한 당시에는 이런 문제가 없었던 것 같은데 아무튼 현재는 uBlock 과 NS 를 모두 활성화하면 NS 에 이러한 문제가 생긴다.
그래서 uBlock 을 끄든가 NS를 끄던가 골라야 했는데, 이번에는 NS를 끄기로 했다. 얼마 전의 discovery pane 문제라던가, Pocket 문제라던가, 기본적인 파이어폭스 기능과도 많이 충돌했기 때문에 이번에는 uBlock 으로 NS로 대체하는 것을 시도해보기로 했다.
UI 설명은 좀 부실하지만 설명서가 잘 되어있어 NS가 하던 일을 uBlock 으로 흉낸내는데 성공했다. XSS, ABE, 기타 플러그인(플래시 등)
까지 쓰다가, uMatrix 라는 같은 개발자가 만든 다른 플러그인을 알게 되어 이것을 설치해 보기로 했다.
uBlock 에 비해 더 자세한 설정이 가능하다. 또한 NS가 제공하던 ABE나 XSS 도 실질적으로 지원하는데, 이렇게 하려면 기본적으로 모든 리소스에 대한 기본 정책을 block 으로 두고 필요한 자원만을 선택적으로 허용하게 하면 된다.
예를 들면 이러한 식이다. 위키피디아의 CSRF 설명을 참조하여 localhost 서버에 대한 이미지를 요청하는 예제 페이지를 만들었는데, 아래를 보면 웹 사이트에서 localhost 에 대한 요청이 차단된 것을 확인할 수 있다. 자기 자신을 제외한 모든 서버에 대한 요청에 대한 기본값이 차단이므로 ABE 나 XSS 의 효과를 얻게 된다.
현재는 사이트 허용에 대한 기본값도 css, image 만 허용하게 해뒀는데 쿠키를 추가해야 하나 고민중이다. 쿠키도 명시적 제어가 필요할 것 같아서인데, 음… 유튜브 히스토리 문제를 해결한다고 잠시 씨름해봤더니 쿠키까지 관리하려고 하면 너무 손이 많이 가는 거 같기도 하고…
실은 츠무기가 2번째이지만 그건 안 찍었다…
요즘 유행이랑 다르다고는 하지만 그래도 먹인 게 아까워서 마저 먹이기로
40층까지 C만 받으면서 겨우겨우 한층씩 깼던게 얼마 전인데 이번엔 37층에서도 SSS를 받는구나. 기념으로 한장.
는 벌써 3달이나 됐구나.
그건 그렇고 43층까지 확장되면서 40층이 최대일 때에 비해서 40층 이하의 난이도는 낮아진 게 아닌가 싶은 느낌도 든다. 41층 너머가 옛날 40층 느낌인듯.
기존에 썼던 글의 업데이트이지만 PC판 및 토끼팀, 레오타드 의상 추가로 고해상도로 모두 재촬영하여 다시 작성하였다. 이전에 썼던 코멘트는 인용으로 표기되어 있다.
전체적으로 레오타드는 흰색이어서 그런지 바니걸에 비해 의상이라는 느낌보다 속옷이라는 느낌이 강해서 배덕감이 더 강하게 느껴진다. 그래서 요즘은 다시 모두 바니로 돌려놓음.
모두가 행복한 타와와 라인
1. 시온
B91 W60 H88
누구도 부정할 수 없는 원탑. 시온 짱! 최고다!
바니 때는 참 좋았는데 레오타드 의상은 배덕감이 너무 심하게 들어서 입히질 못하겠다.
2. 슈크림
B88 W64 H89
모두가 좋아하는 슈크림… 이라고 하기엔 사실 개인적으로는 별로. 목소리가 좀 취향이 아니라서…
목소리는 최근 익숙해진 편인데 요즘엔 다른 4성이 많아져서 잘 쓰지 않는 편. 아마 확대 비율은 똑같을 텐데 위치 때문인지 레오타드를 입혔을 때 더 가슴이 커 보인다.
3. 히나
B87 W56 H82
토끼팀 추가와 함께 혜성같이 등장한 신인. 스리사이즈가 공개되기 전엔 시온의 자리를 위협하는 것이 아니냐는 기대도 있었지만 업데이트 결과 슈크림에 약간 모자라는 B87 인걸로 밝혀졌다.
사실 히나는 첫 등장의 교복에서의 임팩트가 더 대단하기 때문에 바니걸보다도 교복 쪽이 더 가슴이 강조되어 보이는 것 같다. 처음엔 시온보다도 큰 줄 알았다… 나중에 나란히 놓고 비교해 보니 시온 쪽이 더 크긴 크더라. 가슴 크기는 크게 차이가 안 나는데 키 차이는 크게 나서 그런 듯.
분쟁이 끊이지 않는 프론트라인.
4. 레이
B85 W57 H83
가드가 튼튼해서 정확한 측정이 어렵다. 슈크림의 뒤를 잇는 3위인데… 어깨가 얇아서인지 겉보기에는 작아보인다. 다른 사이즈는 유이나 미야카와 비슷함에도 B85 이면 큰 것임에는 분명하지만 그래도 아쉬움이 남는다.
히나의 등장으로 인해 4위로 추락한 레이. 이전에는 키 때문인지 확신을 갖지 못했는데 이젠 확신을 갖고 말할 수 있다. 레이의 가슴 수치는 거짓임에 틀림없다…! 비슷하게 키가 작은 히나의 자기주장이 격렬한 것을 생각할 때 레이 또한 경쟁자들에 비해 우월해야 하는데 그렇지 않은 걸 보니 이 수치는 가짜다.
근데 순위 교정하려면 골치아프므로 그냥 냅두기로. (…)
5(공동). 실비아
B84 W57 H88
레이 이상으로 가드가 튼튼해서 이 시점에서밖에 각이 안 나온다. 수치상으로는 4위이지만 모델링만 봤을 땐 이 쪽이 3위 아닌가 싶다.
기본 자세 때문에 체형이 드러나는 자세를 취할 때까지 클릭해야 하는데 PC판의 문제인지 갈아입기에선 잘 반응을 안해서 측정하기가 굉장히 힘들었다. 그래서 레오타드 찍을 땐 좀 대충 찍음.
심지어 이 글 쓰는데 섬네일에서도 구분이 잘 안되서 한참 찾음. 측정에 있어선 완전 골칫덩어리.
5(공동). 마치
B84 W59 H87
실비아와 수치가 똑같고 모델링으로도 비슷한 것으로 보이지만…
무기 타입이 겹치는 관계로 거의 항상 실비아의 하위호환(…) 정도의 취급이어서인지 가슴 사이즈에서도 하위호환인 듯한 느낌이… (……)
요즘 어딘가에서 마노코 소리를 듣긴 하지만(…) 측정에 있어서만큼은 실비아와 비교불가. 압도적으로 친절한 마치씨.
5(공동). 렌
B84 W59 H85
히나와 함께 등장한 렌. 히나만큼은 아니지만 역시 부족하지 않은 몸매를 자랑한다. 덕분에 안 그래도 2명이나 있었던 84라인이 이제 3명이 됐다…
레오타드보다는 바니 쪽이 좀 더 커 보인다.
8. 나카○시=상
B83 W58 H85
의외로 6위를 차지해 선전한 노노. 역시 나카○시 파워인가…
아무것도 안 했는데 졸지에 6위에서 8위로 추락한 노노. 그래도 하위 2명이 추가되서 전체 순위는 유지하게 됐다.
9. 아이리
B82 W57 H86
의외로 순위가 낮은 아이리. 갸루의 자존심은 어디로
근데 어깨 때문인지 실비아와 마찬가지로 수치에 비해 더 커 보인다.
마치와 더불어 포즈 잘 취해주는 오르타나 중 1명.
마지노 선. 女の子의 존엄이 달린 최후의 보루이다.
10. 홋케
B81 W57 H82
좋은 의미로도 나쁜 의미로도 무난한 미야카. 특별히 뛰어난 건 없지만 크게 뒤떨어지는 부분도 없달까…
11(공동). 유이
B80 W56 H81
아슬아슬하게 80 라인에 턱걸이. 큿 라인에 들어갈 줄 알았더니 의외였다.
실비아만큼이나 측정하기 어려운 오르타나 중 하나. 실비아와는 달리 빈약하기에 아-주 대충 찍음.
11(공동). 치호
B80 W56 H80
토끼팀에 추가된 SM 자매 중 동생. 언니와는 다르게 간신히 턱걸이로 “큿” 만은 면했다.
개인적으로는 이런 S 캐릭터는 별로 마음에 들지 않는다. 애정이 드러나지 않는 일방적 가학행위는 내 가치관과 맞지 않는다.
큿……….
13. 사쿠라코
B77 W55 H80
아이돌 가능할까 이젠 오직 큐트계 아이돌 뿐이야
아무것도 안 했는데 3위나 추락한 4쿠라코. 아니, 아무것도 안 했기 때문인가…
14. 미유키
B75 W53 H79
이번에 추가된 SM 자매 중 언니. M을 담당한다.
CV는 달콤한 목소리가 참 마음에 들었는데… 다만 너무 빈약한 몸인게 아쉽다. 그리고 가슴 터치 등을 할 때의 반응이 너무 과장된 것 같다. 구체적으로 말하자면 너무 모션이 길어서 작위적인 느낌이 난다.
머리가 길어서 측정에 애로사항이 필… 줄 알았는데 의외로 왼쪽에서 찍으니 어려움이 없었다.
15. 나오미
B73 W56 H74
… 나오미 성우는 아메바에 항의해도 되지 않을까. 너무 버림패의 느낌이 강하게 드는데…
츠무기와 더불어 가장 낮은 곳에서 히토미 학원을 지…킨…다…. 여전히 뒤에서 2등을 지킨 나오미.
16. 츠무기
B70 W54 H69
역시 예상대로 최후는 츠무기. 이건 여동생 캐릭터의 숙명같은 게 아닐까…
가장 빈약한 몸의 츠무기지만 배덕감보다는 귀여움이 더 강조되는 불가사의. 역시 고양이 효과인가…
오늘 azure 포탈에서 사용량 조회를 해 봤더니 이렇게 나왔다.
근데 이미지가 좀 있다곤 하지만 벌써 600메가 가까이 쓰고 있지는 않을 것 같아서 콘솔에서 웹 사이트가 얼마나 용량을 사용하고 있는지 조회해 보았다.
조회한 결과 약 400메가 정도 된다.
wwwroot 에 포함되지 않은 것은 git 의 레포지토리 용량이나 로그 파일 등인데 특별히 큰 파일도 찾을 수 없는데 200메가 가까이 차지한다는 건 이상하다. 아직이야 사용량 제한에 근접하지 않아서 대충 살만하지만 음… 모자라게 되면 수동 설치를 해서 사용량을 체크해보고 셀프 호스팅 서버로 옮기던지 아니면 지역을 옮기던지 해야겠다.
azure 관리에 필요한 부분까지 사용량에 포함시키는 게 말이 되나…
원인을 알아냈다. in-app MySQL 의 스토리지가 나머지 200MB 가까이를 쓰고 있었다. export 로 추출하면 1.6MB 밖에 되지 않지만 스토리지 상에서 점유하는 공간은 230MB 정도인 것으로 보인다.
너무 낭비가 많은데 mysql 은 sqlite 나 SQL Server CE 같은 게 없나…
URL rewrite 가 인코딩된 주소를 받고, 이를 재작성(또는 리디렉션) 된 주소에 다시 활용하는 경우 잘못 인코딩된(=입력과 동일하지 않은) 주소를 반환하는 문제.
워드프레스에서 제목을 한글로 쓰면 퍼머링크도 기본적으로 한글로 작성되기 때문에 이것을 수정하지 않고 저장하면 페이지 보기가 안되고 404 가 뜨는 문제가 있었다.
이것이 OS의 레거시 인코딩 문제(윈도우즈에서 유니코드가 아닌 ANSI 문자열을 사용하는 레거시 API를 호출하는 프로그램이 겪는 문제) 라고 생각했었는데… 아주 틀린 건 아니지만 내가 생각한 종류의 것은 아니었다.
알고보니 한글로 작성을 하더라도 클라이언트에서는 이 퍼머링크를 인코딩하여 보내므로 저장까지는 인코딩 문제가 발생하지 않고 잘 된다. 그러나 페이지 보기를 누르면 워드프레스의 설정의 사이트 주소가 http 를 기준으로 설정되어 있으므로 퍼머링크도 http 링크로 생성되어1 클라이언트가 http 주소로 접속을 시도한다. 그러면 서버는 이 요청을 https 리다이렉트 룰에 의하여 https 주소로 리다이렉트하는데, 이 과정에서 URL rewrite 가 프로토콜만 변경하고 나머지 값은 그대로 유지하여야 하지만 실제로는 그렇게 동작하지 않아서(path 값이 입력 그대로가 아닌 잘못 인코딩된 값으로 반환된다) 결국 404 에러가 발생하게 된다.
이것을 해결하기 위해서는,
중에 하나를 수행하여야 하는데, 현재는 2개 모두 적용했다.
1. 의 경우에는 wp_config.php 파일의 WP_HOME 및 WP_SITEURL 변수를 수정해주면 되고, 2. 의 경우에는 아래에 서술한다.
원래는 이런 식의 https 리다이렉트 룰을 썼었다.
<rule name="https redirect" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTPS}" pattern="OFF" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{R:0}" redirectType="Permanent" />
</rule>
이것을 보면, 룰에 의하여 캡처된 주소를 그대로 리턴하므로 문제가 없을 것 같지만 실제로는 잘못된 주소를 리턴한다.
이를 해결하기 위해 현재는 다음의 룰을 사용한다.
<rule name="https redirect" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTPS}" pattern="OFF" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{UNENCODED_URL}" redirectType="Permanent" />
</rule>
캡처 과정에서 문제가 발생하는 것 같아 {R:0} 대신 {UNENCODED_URL} 를 사용하여 클라이언트가 요청한 값을 그대로 돌려주도록 했다.
한편, URL Rewrite Module Configuration Reference2 에 의하면 또한 {HTTP_X_ORIGINAL_URL} 도 제시되고 있는데, 로그를 보면 X-ORIGINAL-URL 서버 변수는 기록되고 있는 것으로 보이지만 URL Rewrite 에서 저 변수를 쓰면 그냥 공백이 리턴된다. 전에도 다른 건으로 검색해보았지만 납득할만한 설명이 없었던 것으로 보아 이것 또한 버그로 보인다.
Continue reading “URL Rewrite 에서 인코딩된 주소를 재작성시 제대로 처리하지 못하는 문제”
乳袋와 横胸, ネクパイ, 咥えゴム, 포니테일, 그리고 노출된 골반 등 온갖 페티쉬를 한 장에 담아낸 명작이어서 선정했다.
한눈에 봤을땐 그리 선정적이지 않지만 자세히 보면 볼수록 에로함이 돋보이는 것도 참으로 훌륭하다.
in short:
whitelist “https://discovery.addons.mozilla.org/” in XSS filter.
for detail, refer to my post on noscript forum.
https://forums.informaction.com/viewtopic.php?f=7&t=22625&p=87009#p86996
AdBlock Plus(이하 ABP)는 오랫동안 내 파이어폭스 브라우저와 함께해온 플러그인이었다. 쓰고 있을 땐 체감이 잘 안되지만 사파리나 IE등 광고차단이 없는 다른 브라우저를 쓰면 확실히 광고가 많이 노출되는 것을 느끼곤 했다.
아무튼 그렇게 오랫동안 쓰고 있었는데, 오늘 ABP 대신에 uBlock Origin(이하 uBlock)을 설치해보았다. 계기는 요즘 들어 방문하게된 디시인사이드에서 오늘부터(사실 날짜가 지났으니 어제지만) 광고차단기를 사용시 이를 꺼달라는 팝업을 띄우기 시작했기 때문이었다. 조금 살펴본 결과 이를 차단하려면 페이지의 inline script 를 차단하여야 한다는 결론에 이르렀는데, 문제는 ABP의 경우 이를 지원하지 않는 것이었다.
해결책을 찾기 위해 검색하다 보니 ublock 개발자가 자신의 부가기능의 장점으로 ABP는 지원하지 않는 인라인 스크립트 차단과 적은 리소스 사용 등을 어필하기에 한번 깔아보았다. 결론부터 말하자면 크게 만족했다. 인라인 스크립트 차단이 잘 작동할 뿐 아니라 차단 요소 지정 역시 더 편리했다. 다만 애시당초 ABP가 리소스를 많이 먹는지는 체감이 되지 않았으므로 리소스 절약 부분은 잘 체감이 안됐다. 음… 노트북으로 열어보면 차이가 나려나?
2017-04-15 update: Gmail 등에서 파일 다운로드에 문제가 생기기에 uBlock 문제인 줄 알았는데, 로그를 검토한 결과 구독중이던 JPN: ABP Japanese filters (日本用フィルタ) 가 원인인 것으로 드러났다. 어쩐지 수상하게 많더라니…
이런 문제해결(TroubleShooting) 측면에서도 ABP 보다 낫군. 매우 만족스럽다.