행복만땅 개발자

독일 법원이 아이폰용으로 개발된 인터넷전화(VoIP) 어플리케이션의 사용을 금지하는 판결을 내려서 화제가 되고 있다. 이번에 금지된 VoIP 어플리케이션은 본 블로그를 통해서 소개해 드렸던 에스아이피게이트(sipgate)이다. 독일의 함부르크 법원은 아이폰에서 sipgate 어플리케이션을 금지시켜 달라는 독일의 이동통신 사업자인 T-Mobile의 요청을 받아 들였다고 한다.

미국의 경우 아이폰이 출시되고 이동통신사의 3G 데이터망을 이용한 인터넷전화는 허용하지 않았지만, 와이파이망에서 인터넷전화를 이용하는 것에 대해서는 막지 않고 있는 것을 감안하면 아주 이례적인 결정이다.

그렇다면 법원이 아이폰에서 인터넷전화를 금지시킨 이유가 무엇인지 궁금하지 않을 수 없다. T-Mobile이 법원에 고소한 내용은 Sipgate 같은 프로그램이 아이폰의 해킹(Jailbreaking)을 조장하고 있다는 것이다. 이것 참 어이가 없는 일이 아닐 수 없다..ㅋㅋ

T-Mobile은 영국에서 또다른 모바일 인터넷전화(Mobile VoIP) 사업자인 트루폰(Truphone)으로 연결되는 호를 막아서 영국 법원으로부터 개선 명령을 받았던 전력(?)이 있는데.. 자신이 힘 깨나 쓰는 유럽에서 모바일 인터넷전화를 막기 위해서 최선(!)을 다하고 있는 듯 하다.

구글 안드로이드 플랫폼을 채택한  HTC Dream이 다음 주인 9월 23일에 미국 T-Mobile을 통해 출시된다는 소식을 전해 드렸는데.. 안드로이드 마켓에 인터넷전화 관련 어플리케이션이 올라가면 어떻게 대응할지 기대된다.

한 가지 웃긴 사실은 독일 법원이 독일 내에서 진행하고 있는 T-Mobile의 아이폰 광고 또한 금지시키는 결정을 내렸다는 사실이다. 광고 내용 중에 '무제한 인터넷 접속(free internet access with unlimited usage)" 문구가 과장 광고라는 지적에 따라 광고 자체가 금지되었다고 하니.. 집안 단속부터 해야 할 판이다.

이번에 Sipgate 금지 결정은 1심 판결이라.. 상급심 판결이 남아 있다고 하는데, 어떤 판결이 나올지 벌써부터 기대된다. 설마 2심에서도 금지하는 판결을 하지는 않겠죠?

국내에도 아이폰을 비롯한 외산 스마트폰이 올 하반기에 대거 출시될 계획으로 알고 있는데.. 국내 이통사도 이런 치사한 방법으로 모바일 인터넷전화 확산을 막지 말 것을 젊잖게 충고드린다.

출처 : VoIP on Web2.0

ㅋ. 몇년만에 휴가도 다녀오고 기분좋게 출근했더니 그동안 잘 나오던 jfreechart로 만든 페이지에서 차트가 나오질 않아

로그를 확인해보았더니

java.lang.NoClassDefFoundError: Could not initialize class org.jfree.chart.JFreeChart..어쩌구저ㅉ구

라는 에러문구를 확인할 수 있었다.

당연히 클래스파일을 찾지 못하는 거라 해당 클래스파일을 누군가 지웠나 하면서 확인해보았는데

이잉? jar 파일은 그대로 lib폴더에 있는게 아닌가..

다른 서버 설정이 바뀌었나 싶어 다른 직원들에게 물어봐도 손댄것은 없댄다.

당연 저문구로는 클래스파일을 못찾아서 나오는 거니 아무리 구글 검색을 해봐도 답변은 lib 밑에 관련jar파일을 넣으라는 말뿐..

웹서버까지도 다시 깔아보았지만 마찬가지...미친다...

최후의 수단 각 라인단위로 로그를 찍어보는 막가파 디버깅..

그러던차에 ChartFactory에서 차트를 생성하기 전단계에서 Could not initialize class sun.awt.X11GraphicsEnvironment

라는 문구를 찾아내었다.

X11이란건 리눅스에서 그래픽환경을 지원하는 것이라고 알고 있었는데 이게 왜 나온걸일까..

결국 환경설정문제였던 거같다.

역시 잘 운영되고 바꾼사람 없는 시스템에서 아무도 몰래 시스템 혼자서 설정이 변경되는 미스테리한 일을 또한번 경험하고 말았다.

여하튼 에러는 X11이 없는 리눅스 콘솔에서 발생하는 문제이기 때문에 간단히 java 실행시 headless 모드로 구동하면 끝.

아니면 라이브러리를 지정해도 된다. 환경설정파일에 CLASSPATH로 지정해도 상관없다.

방법 : java -Djava.awt.headless=true 

일단 간단하게 웹서버 구동시 -Djava.awt.headless=true 라는 옵션을 추가한후 재구동하는 것으로 해결..

(전에 어떤 분이 어느파일을 손보면 되는지 물어보신 분이 계셔서 톰캣인 경우 톰캣설치폴더 밑에 있는 bin 디렉토리의

catalina.sh 파일을 보면 옵션 설정하는 부분이 나오는데 그곳에 추가하면 된다.)

위 옵션은 java 1.4 이상에서고 그 외에는

tomcat을 5.5 버젼 이상으로 개발하다 보니 이상한 로그가 서버 실행 및 종료때 찍히는게 아닌가?

시작할 때 Dec 5, 2006 6:54:28 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent
INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: .... 어쩌구 저쩌구

종료할 때 Dec 29, 2006 1:15:53 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent
INFO: Failed shutdown of Apache Portable Runtime .. 어쩌구 저쩌구

5.0을 쓰다 5.5로 바꾸었더니 갑자기 서버 구동중에 떨어진 메시지에 놀라 tomcat만 재설치해보기도 하구 6.0을 깔아보기도 했건만

이 요상한 메시지는 계속 뜨는게 아닌가?

헌데 그렇다고 문제 있는것두 아니고 프로그램 구동엔 이상이 없다는 사실...

그래두 일단 찜찜...

에러문구 그대로는 보면 Tomcat Native library를 찾을수 없다 인데 멀 따로 설정해야 하나?

알고 보니 http://tomcat.heanet.ie/native/ 에서 파일을 다운받아 설정값을 변경해줘야 한댄다

윈도우인경우엔 tcnative-1.dll , 리눅스, UNIX 인 경우에는 tcnative-1.so

이라는 파일을 구동시에 찾는 PATH안에 넣어주고 (전 기냥 기존 PATH안에 잡혀있는 디렉토리에 넣었는데 따로폴더를 만들고 추가하셔두 ...)

윈도우즈는 현재 1.1.12  리눅스/unix는 1.1.6 까지 있다.

윈도우즈의 경우 1.1.6 으로 설치하는 경우

최신버젼의 tomcat 6.0라면 An incompatible version 1.1.6 of the Apache Tomcat Native library is installed, while Tomcat requires version 1.1.8 라는 문구가 뜨는걸 확인할수 있다.

한마디로 설치된 tomcat native library 버젼을 업그레이드 하란 말..

내가 테스트로 쓰고 있는 윈도우즈용 tomcat 6.0.14 인 경우 1.1.10 이상을 설치하라는 문구가 나오니

기냥 맘편히 최신 버젼으로 설치하심이 속편할 듯...

그 다음으로는 tomcat 구동 스크립트에 LD_LIBRARY_PATH 를 추가하고 복사한 위치를 적어주면 된다.

예를 들면

export LD_LIBRARY_PATH="%DEV_LIB%/lib"

이제 tomcat을 재구동하면 끝..

netstat -an 명령어는 현재 운영하고 있는 서버에 대한 외부의 네트워크 요청을 확인할 수 있는

유용한 명령어 입니다. 유닉스 뿐 아니라 윈도우에도 있네요...

Local Address는 자신의 아이피 입니다.

Foreign Address는 상대방의 아이피 입니다.

State는 접속방법입니다.

State의 대한 설명은 다음과 같습니다.

LISTEN : 현재열려있는 포트로써 누군가의 접속을 항상 기다리고 있는 포트입니다.

             즉 항상 열려있다는 뜻으로 허용한 포트 외의 포트가 Listening에 있다면

             그 원인을 잘 살펴봐야 합니다.

ESTABLISHED : 현재 정상적으로 연결이 된 포트로써 사용하고 있다는 의미입니다.

                       80번 포트에 이런 메시지가 있으면 웹브라우저를 통하고 홈폐이지

                       를 보고 있다는 뜻입니다. < 80번 포트는 인터넷 포트입니다. >

TIME_WAIT : 접속 후 사용이 종료되었으나 지정된 시간만큼 다른 명령이나 신호를

                   기다리고 있다는 의미입니다. 80번 포트는 웹브라우저의 요청에 대하여

                   홈폐이지 보여주기가 완전히 끝난뒤에도 다른 요청에 빨리 동작하기

                   위하여 15초정도 대기상태에 있습니다.

FIN_WAIT 1 : 포트가 닫혔으며 연결이 종료되기를 기다리는 상태입니다.

FIN_WAIT 2 : 연결이 완전히 닫힌 상태입니다.

SYN_SENT : 원격지에서 포트를 열려고 시도하는 중을 나타냅니다. 허용된 포트외의

                  다른포트에서 이런 메시지가 나오면 유심이 확인해 봐야 합니다.

UNKNOWN : 현재 포트의 상태를 알수 없다는 뜻 입니다.

간단하지만 이렇게 접속자정보와 state로 불법사용자여부를 확인하거나

웹서버의 경우 tcp 세션 현황을 모니터링 할 수 있습니다.

TCP session 상태가 "FIN_WAIT , TIME_WAIT" 와 같은 session의 정보가 장시간  다수 발생하는 경우

해당 tcp 세션을 clear 하기도 합니다.

예) ndd -set /dendd -set /dev/tcp tcp_discon 0x0001 (solaris나 hpux 의 경우 )

    rmsock  PCB/ADDR tcpcb (AIX의 경우)

하지만 정상적으로 "ESTABLISH" 상태인 session을 clear 하면
데이터 손실이나 시스템다운 등의 예상치 못한 결과가 생길 수 도 있다고 한다.

1. execCommand('SaveAs') 의 차단

IE6에서는 javascript로 문서를 저장시 execCommand('SaveAs')를 사용할수 있었다.
html, text뿐만 아니라 execCommand("SaveAs","false","test.xls")이런 방법으로 Table을 엑셀파일로도 저장할 수 있었던 것.
하지만 IE7부터는 execCommand등의 몇몇 메소드에 대하여 제한을 두고 있기 때문에 더이상 이런방법으로

엑셀형태로 다운로드 할 수 없게 되었다.(html,text 파일로는 저장이 된다고 하네요...)

2. context-type 설정을 통한 파일 다운로드의 제한

다른 방법으로 엑셀파일로 다운로드 하고자 할때 다음과 같은 헤더를 사용한다.

header("Content-type: application/vnd.ms-excel");
header("Content-Disposition: attachment; filename=test.xls");
header("Content-Description: PHP4 Generated Data");

그렇게 되면 헤더를 먼저 뿌려주고, 데이터를 출력해서 엑셀형태로 다운받게 된다.

그런데, 위와 같은 동일한 코드에서 IE6 에서는 정상적으로 다운로드 받지만,
IE7 에서는 다운받지 못하는 현상이 있다.

##########0*

위와 같이 다운로드를 시도하는데, 끝내 다운받지 못한다.

흐음 이부분은 해결방법이 상당히 묘하다. 그말은 딱히 정확한 원인을 알수 없다는 것이다.

정책상의 변화로 인한 파일 다운로드문제인지 다른 문제인지..

왜냐하면 내 경우에는 모달창에서 검색된 로그나 상태값을 엑셀로 저장하고자 할때 위와 같은

문제가 발생했지만 다른  pc에서는 이상없이 다운로드 되었기 때문이다.

모달창이 아닌 메인창에서 호출하거나 새창으로 연 경우에는 동일코드로 이상없이 작동되었다.

모달창의 경우엔 그외에도 새창으로 열기에서는 발생하지 않았던 ocx등의 오동작등이 보이는걸보면

모달창에 대한 정책변경이 있었던 듯 싶지만. 관련된 정보는 확인할 수 없었다.

한글명의 경우 XP의 IE7은 고급택스트서비스와의 충돌로 인하여 위와 같은 현상이 발생할 수도 있다고한다.

(아니면 나와 같이 3벌식을 쓰는 경우이거나..이땐 대책없다.ㅋㅋ)

즉 vista의 IE7인 경우 정상적 작동

이에 대한 해결방법은  [제어판] - [국가 및 언어] - [언어] 자세히 -

 [텍스트 서비스 및 입력언어창] - [고급] 선택 - [고급텍스트 서비스 사용안함] 선택

을 통해서 해결할 수 있다

3. 해결?

일단 앞서 말한바와 같이 모든 경우에 동일한 결과가 나타나지 않을 뿐더러 원인에 따라 해결방법이 있기도 없기도 하다는

점이 문제다. 2.번의 경우 jsp가 아닌 서블릿으로 처리하는 경우 대부분 이상없이 다운로드 받을 수 있었다.

아니면 jxl을 통해 파일을 생성후 다운로드 받도록 하는 방법도 생각해 볼만하다.

앞서 말한바 있지만 IE7에서는 새창으로 열거나 모달창으로 여는경우 주소창이 항상 보이게 된다.

여러가지 이유로 모달창을 사용해야만 했던 경우에 보여지는 주소줄땜시 대략 난감한 경우가 많았는데.

개발자 단위로 이를 해결할 수 없다는 사실이 가슴아프다.

여하튼 브라우저상에서의 해결방법은 다음과 같이 보안설정부분을 변경해주면 된다.

IE7.0 에따른 이슈사항들

작년부터 알고는 있었고 나름 대처를 하긴 했지만 가끔씩 나타나는 문제들 때문에 골치가 아프다...

일단 정리부터.... 

1. window.status

window.status 코드가 인터넷 영역에서 실행되지 않는다.

function test() {

    window.status = 'Hi!';

}

단 로컬에서는 된다. 즉 로컬에 저장된 html을 실행하면 window.status가 적용되지만

인터넷에 있는 window.status는 반영되지 않는다.

2. <base>태그

HTML3.2 스펙에 따라 <base>태그는 반드시 <head></head>에 위치해야 한다.

그렇지 않으면 인식하지 않는다네요

얼마전에도 이것땜시 모달창에서 문제가 있었는데..그때 기억이 새록새록...-_- 

3. window.close()

window.close()시 나타나는 프롬프트를 회피하기 위해 window.opener 를 사용했었는데

더이상 아래 코드는 먹지 않고 창을 닫겠냐는 프롬프트가 뜨게 됩니다

window.opener=top;

window.close();

or

self.opener = self;
window.close();

4. _search

_search를 통해 검색창을 더이상 열지 못한다.

5. window.prompt()

디폴트로 block 된다.

6. 제한되는 메쏘드들

클립보드 저장, 및 클립보드 데이터 가져오기 등의 메쏘드들이 제한된다. (보안경고창)

MS에서는 clipboardData 객체 사용을 권고하지 않습니다

7. Modal 및 Modeless Dialog 크기가 변경!

덕분에 브라우저마다 보여지는 모달창의 여백이 T_T

사이즈를 지정시 기존의 경우 창크기를 의미했으나 IE7에서는 content 크기만을 의미합니다

모달창이 커졌네..첨엔 멋모르고 사이즈 조정했다가 다른 브라우저에서는 밑에가 짤렸다는...

브라우저 체크해서 사이즈를 조절하면 되겠지만 귀차니즘땜시...기냥 늘려서 사용중...

8. 새창으로 뜰때 주소줄 보임

더이상 새창을 window.open 의 property 특성으로 조절할 수 없다

무조건 주소창이 나타나게 된다.

이 문제는 개인 사용자별 [도구] - [인터넷옵션] - [보안] - [인터넷]영역 - [사용자지정수준]
[보안설정-인터넷영역] - [기타] - [웹사이트에서 주소 또는 상태표시줄 없이 창을 열도록 허용] - [사용]

을 통해서 해결할수 있고 레지스트리를 수정해서도 가능하다고 들었는데 아직 잘 모르겠다.

여하튼 이문제는 클라이언트에게 그 문제를 해결할 것을 요청하게 되는것이라

7번의 문제와 더불어 고민을 안겨준다..

9. window.resizeTo()

window.resiztTo 함수는 에러가 발생하거나 차단된다.

 하지만 이건 IE6에서도 가끔 안되던 문제라서...잘...

10. HTTP, HTTPS 혼합된 인터넷 영역에서 보안 경고가 발생합니다

11. SELECT가 windowed element로 개선

이전까지는 SELECT Element가 Windowsed Element였기 때문에

다른 element와 달리 별도의 MSHTML pane에서 rendering되었다.

즉 SELECT가 그림과 같이 layer들을 가리게 되었는데, IE7부터는 그러지 않는다는 이야기

것땜시 사이즈 및 화면디자인부분에 신경을 많이 썼었는데 편해진듯...싶지만

12. 스크립트 차단

IE6까지는 아래 코드가 실행되어 보안에 매우 취약했지만 IE7 부터는 아예 실해이 안된다고 한다. (XSS)

13. CSS

100%는 아니지만 CSS2.1 표준 구현 강화가 되었습니다

또한 <a> 태그에서만 가능했던 :hover나 background-attachment: 가 모든 태그에서 사용가능해 졌다

이밖에도 알려진 버그로는 "신뢰할수 있는 사이트"에 추가를 했는데도, 보안창이 뜬다든가,

flash에서 _blank로 새창을 열면 자기 자신창에서 열린다든가 하는 버그가 있다고 한다.

이렇게 주저리주저리 쭈욱 나열했지만

문제는 같은 IE7이라 하더라도 xp와 vista에서의 보안정책이 달라서인지 각기 다른 버그들이 생겨난다는 것이다.

탭기능 등이 추가된 것은 좋지만.

vista에서는 보안성강화라는 측면을 무시할순 없지만 사용자편의성은 무시하고 있는게 하는 생각을 들게 만든다.

흐음 익스플로어 7을 새로 깔았더니 모달다이얼로그창에서 submit 을 한 경우 그 결과 페이지가 새로운창에서 뜨고 있다는 걸 발견했다.

이상하네.. 왜 그러지...

target 만 _self로 주면 되는게 아니었나?

이제껏 잘 돌아가던거였구 소스상에서도 <base target="_self"> 구문이 있다는 사실을 알았는데

유독 그 페이지만 그런 문제가 발생하다니...이상한 일...

고민 또 고민.. 헌데...

익스플로어7에서는 <base target="_self"> 구문이..

반드시 head안에 들어가 있어야 한다는 사실을 알게 되었다.

즉 body 태그 아래 적어두었던 <base target="_self">구문은 적용이 되지 않았던 셈...

다른 페이지의 경우 ajax등을 사용해서리 어차피 데이타 처리는 그 페이지 안에서 처리가 되기 때문에

다른페이지는 이상이 없었지만 ajax로는 구현이 안되는(내가 알기로는...) 첨부파일 전송페이지였기 때문에..

그런 일이 발생한 거였다...

하지만 중요한것은  body 태그 안에 그 구문을 넣어야 한다고만 알고 있었던 내 자신이었다.

이제껏 당연히 되어왔기에 당연히 그게 옳은 것이라고 생각했던 그래서 당연한 것인양 사용해왔기에 더더욱 쓰리다...

기초(?)의 소중함을 다시금 깨달을수 있었던 오늘의 헤프닝~~~