1 Secure Remote Access Server 구성 요소

• 1 장, Portal Server Secure Remote Access Server 소개

• 2 장, 게이트웨이 작업

• 3 장, Proxylet 작업

• 4 장, Rewriter 작업

• 5 장, NetFile 작업

• 6 장, Netlet 작업

1장 Portal Server Secure Remote Access Server 소개

이 장에서는 Sun Java^TM System Portal Server Secure Remote Access에 대한 설명과 더불어 Sun Java System Portal Server와 Sun Java System Portal Server Secure Remote Access 구성 요소 간의 관계를 설명합니다.

이 장에서는 다음 주제를 다룹니다.

• Secure Remote Access 소개

• Secure Remote Access 서비스

• 지원되는 응용 프로그램

Secure Remote Access 소개

Secure Remote Access를 사용하면 원격 사용자가 인터넷을 통해 조직의 네트워크와 서비스에 안전하게 액세스할 수 있습니다. 그 외에도 조직에 안전한 인터넷 포털을 갖추어 직원, 비즈니스 파트너 또는 일반 대중이 컨텐트, 응용 프로그램 및 데이터에 액세스할 수 있게 해줍니다.

Secure Remote Access를 사용하면 어떤 원격 장치에서도 브라우저를 통해 포털 컨텐트와 서비스에 원격으로 안전하게 액세스할 수 있습니다. Secure Remote Access는 안전한 액세스 솔루션으로서 Java™ 기술이 지원되는 브라우저가 있는 어떤 장치에서도 사용자가 액세스할 수 있어 클라이언트 소프트웨어의 필요성을 없애줍니다. Portal Server와의 통합으로 사용자는 액세스 권한을 가지고 있는 컨텐트와 서비스에 암호화된 방법으로 안전하게 액세스할 수 있게 되었습니다.

Secure Remote Access 소프트웨어는 안전한 원격 액세스 포털을 구축하고자 하는 기업에 이상적입니다. 이러한 포털은 보안, 안전 및 인트라넷 리소스의 기밀 유지에 중점을 둡니다. Secure Remote Access 아키텍처는 이러한 포털 유형에 적합합니다. Secure Remote Access 소프트웨어를 사용하면 이러한 자원을 인터넷에 노출시키지 않고 사용자가 인터넷을 통해 인트라넷 자원에 안전하게 액세스할 수 있습니다.

Portal Server는 다음 절에서 설명하는 대로 열린 모드와 보안 모드에서 작동됩니다.

열린 모드

열린 모드에서는 Portal Server가 Secure Remote Access 없이 설치됩니다. 이 모드에서 HTTPS 통신이 가능하지만 안전한 원격 액세스는 불가능합니다. 따라서 사용자는 원격 파일 시스템과 응용 프로그램에 안전하게 액세스할 수 없습니다.

열린 포털과 보안 포털 사이의 주된 차이점은 열린 포털로 제공되는 서비스가 일반적으로 안전한 인트라넷 내부가 아닌 완충 지대(DMZ)에 위치한다는 것입니다. DMZ는 공용 인터넷과 사설 인트라넷 사이의 작은 보호 네트워크로서 일반적으로 양쪽에서 방화벽으로 경계를 이룹니다.

공용 정보를 배포하고 무료 응용 프로그램에 액세스하는 등의 중요한 정보가 포털에 들어 있지 않아서, 이 모드를 사용하면 많은 수의 사용자가 보낸 액세스 요청에 대해 보안 모드를 사용할 때보다 빠르게 응답할 수 있습니다.

열린 모드에서 Portal Server는 방화벽 뒤의 단일 서버에 설치됩니다. 여러 클라이언트가 단일 방화벽을 통해 인터넷에서 Portal Server에 액세스합니다.

그림 1–1 Secure Remote Access가 있는 열린 모드의 Portal Server

보안 모드

보안 모드에서 사용자는 필요한 인트라넷 파일 시스템과 응용 프로그램에 안전하게 원격으로 액세스할 수 있습니다.

게이트웨이는 완충 지대(DMZ)에 상주합니다. 게이트웨이는 모든 인트라넷 URL과 응용 프로그램에 단일한 보안 액세스 포인트를 제공하여 방화벽에서 열린 포트의 수를 줄입니다. 세션, 인증 및 표준 포털 데스크탑과 같은 기타 모든 Portal Server 서비스는 DMZ 뒤의 안전한 인트라넷에 상주합니다. 클라이언트 브라우저와 게이트웨이 간의 통신은 SSL(Secure Sockets Layer) 상에서 HTTP를 사용하여 암호화됩니다. 게이트웨이와 서버 및 인트라넷 리소스 간의 통신에는 HTTP 또는 HTTPS를 이용할 수 있습니다.

보안 모드에서 SSL은 인터넷을 통한 클라이언트와 게이트웨이 간 연결을 암호화하는 데 사용됩니다. SSL은 게이트웨이와 서버 사이의 연결을 암호화할 때에도 사용됩니다. 인트라넷과 인터넷 사이에 게이트웨이가 있어 클라이언트와 Portal Server 간의 보안 경로가 확장됩니다.

그림 1–2 Secure Remote Access가 있는 보안 모드의 Portal Server

사이트 확장을 위해 부가적인 서버와 게이트웨이를 추가할 수 있습니다. 이 경우 비즈니스 요구 사항에 따라 다양한 방법으로 Secure Remote Access 소프트웨어를 구성할 수 있습니다. 비즈니스 요구 사항에 따른 구성 방법에 대한 자세한 내용은 Sun Java System Portal Server 7.2 Deployment Planning Guide를 참조하십시오.

Secure Remote Access 서비스

Secure Remote Access 소프트웨어에는 5가지 주요 구성 요소가 있습니다.

• 게이트웨이

  SRA 게이트웨이는 인터넷을 통해 들어오는 원격 사용자 세션과 회사 인트라넷 사이에서 인터페이스와 보안 장벽을 제공합니다. 게이트웨이는 원격 사용자에 대한 단일 인터페이스를 통해 내부 웹 서버와 응용프로그램 서버에서 안전하게 컨텐트를 제공합니다.

  웹 서버는 HTML, JavaScript 및 XML과 같은 웹 기반 자원을 사용하여 클라이언트와 게이트웨이 사이에서 통신합니다. Rewriter는 웹 컨텐트를 이용할 수 있도록 만드는 데 사용되는 게이트웨이 구성 요소입니다.

  응용 프로그램 서버는 Telnet 및 FTP와 같은 이진 프로토콜을 사용하여 클라이언트와 게이트웨이 사이에서 통신합니다. 게이트웨이에 상주하는 Netlet이 이 목적으로 사용됩니다. 자세한 내용은 2 장, 게이트웨이 작업을 참조하십시오.

• Rewriter

  Rewriter는 최종 사용자가 인트라넷을 둘러보고 이 페이지의 링크와 기타 URL 참조가 제대로 작동하도록 합니다. Rewriter는 웹 브라우저의 위치 필드에 게이트웨이 URL을 붙여 컨텐트 요청을 게이트웨이를 통해 리디렉션합니다. 자세한 내용은 4 장, Rewriter 작업을 참조하십시오.

• Netfile

  NetFile은 사용자가 원격 파일 시스템과 디렉토리에 원격으로 액세스하여 작업할 수 있도록 해주는 파일 관리자 응용 프로그램입니다. NetFile에는 Java 기반의 사용자 인터페이스가 포함되어 있습니다. 자세한 내용은 5 장, NetFile 작업을 참조하십시오.

• Netlet

  Netlet은 원격 데스크탑에서 일반 또는 회사별 응용 프로그램을 안전하게 실행하도록 지원합니다. 해당 사이트에 Netlet을 구현하면 사용자가 Telnet 및 SMTP와 같은 일반적 TCP/IP 서비스와 pcANYWHERE 또는 Lotus Notes같은 HTTP 기반 응용 프로그램을 안전하게 실행할 수 있습니다. 자세한 내용은 6 장, Netlet 작업을 참조하십시오.

• Proxylet

  Proxylet은 클라이언트 컴퓨터에서 실행되는 동적 프록시 서버입니다. Proxylet은 클라이언트 시스템에 있는 브라우저의 프록시 설정을 읽고 로컬 프록시 서버 또는 Proxylet을 가리키도록 수정하여 URL을 게이트웨이로 리디렉션합니다.

Secure Remote Access 속성 구성

다음 서비스를 사용하여 Portal Server 관리 콘솔에서 Secure Remote Access 속성을 구성할 수 있습니다.

• 액세스 제어

  이 서비스를 통해 특정 URL에 대한 액세스를 허용 또는 제한하고 단일 사인온 기능을 관리할 수 있습니다. 자세한 내용은 7 장, Secure Remote Access Server 액세스 제어 구성을 참조하십시오.

• 게이트웨이

  프로필(게이트웨이 인스턴스). 이 서비스를 사용하면 구성 요소 활성화, 쿠키 관리, 프록시 관리, 보안 설정, 성능 조정, Rewriter 매핑 관리 등의 모든 게이트웨이 관련 속성을 구성할 수 있습니다. 자세한 내용은 8 장, Secure Remote Access Gateway 구성을 참조하십시오.

• NetFile

  이 서비스를 사용하여 공통 호스트, MIME 유형 및 여러 호스트 유형에 대한 액세스 등 모든 NetFile 관련 속성을 구성할 수 있습니다. 자세한 내용은 14 장, NetFile 구성을 참조하십시오.

• Netlet

  이 서비스를 사용하여 Netlet 규칙, 필요한 규칙에 대한 액세스, 조직 및 호스트 그리고 기본 알고리즘과 같은 모든 Netlet 관련 속성을 구성할 수 있습니다. 자세한 내용은 11 장, Netlet 구성을 참조하십시오.

• Rewriter

  이 서비스를 사용하면 모든 Rewriter 규칙 집합을 다운로드, 업로드 및 삭제할 수 있습니다.

• Proxylet

  이 서비스를 사용하면 Proxylet 애플릿 바인딩 IP 주소 및 포트 번호와 같은 Proxylet 관련 속성을 구성할 수 있습니다. 자세한 내용은 13 장, Proxylet 구성을 참조하십시오.

게이트웨이는 게이트웨이가 실행되는 동안 이루어지는 속성 변경에 대해 알림을 받지 않습니다. 업데이트된 프로필 속성(게이트웨이 또는 기타 서비스에 속함)을 적용하려면 게이트웨이를 다시 시작합니다. 자세한 내용은 명령줄 옵션을 사용한 게이트웨이 속성 구성을 참조하십시오.

충돌 해결 설정

충돌 해결 수준을 설정하려면

1. Sun Java System Portal Server 7.2 관리 설명서의 관리 콘솔에 로그인하려면에 나와 있는 대로 수행합니다.

2. [Secure Remote Access] 탭을 선택하고[Netlet], [Netfile] 또는 [Proxylet] 중에서 필요한 서비스 탭을 누릅니다.

3. [DN 선택] 드롭다운 메뉴에서 [조직] 또는 [역할]을 선택합니다.

4. [COS 우선 순위] 드롭다운 상자에서 필요한 충돌 해결 수준을 선택합니다.

5. [저장]을 눌러 완료합니다.

지원되는 응용 프로그램

SRA는 다음 응용 프로그램을 지원합니다.

• Sun Java System Calendar Server Release 5.1.1 이상

• Sun Java System Messenger Express 6 2005Q1 - Sun Java System Messaging Server 5.2 이상

• Sun Java System Communications Express 6 2005Q1

시작하기 전에

포털에서 SRA를 활성화하려면

1. PortalServer_base/psadmin switch-sra-status -u amadmin -f <passwordfile> on 명령을 사용하여 SRA 상태를 전환합니다.

2. PortalServer_base/psadmin provision-sra -u amadmin -f <passwordfile> -p <portal-id> --gateway-profile <profile-name> --enable 명령을 사용하여 SRA 상태를 지정합니다.

2장 게이트웨이 작업

이 장에서는 게이트웨이 관련 개념을 설명합니다. 게이트웨이 관리에 대한 자세한 내용은 16 장, 게이트웨이 관리을 참조하십시오게이트웨이 구성에 대한 자세한 내용은 8 장, Secure Remote Access Gateway 구성을 참조하십시오.

이 장에서는 다음 주제를 다룹니다.

• 게이트웨이 소개

• platform.conf 파일 이해

• 웹 프록시 사용

• 자동 프록시 구성 사용

• Netlet 프록시 사용

• Rewriter 프록시 사용

• 게이트웨이에서 역방향 프록시 사용

• 클라이언트 정보 가져오기

• 인증 체이닝 사용

• 와일드카드 인증 사용

• 브라우저 캐싱 사용 불가능

• 게이트웨이 서비스 사용자 인터페이스 사용자 정의

게이트웨이 소개

게이트웨이는 인터넷을 통해 들어오는 원격 사용자 세션과 회사 인트라넷 사이에서 인터페이스와 보안 장벽을 제공합니다. 게이트웨이는 원격 사용자에 대한 단일 인터페이스를 통해 내부 웹 서버와 응용프로그램 서버에서 안전하게 컨텐트를 제공합니다.

각 게이트웨이 인스턴스에 대해 다음 작업을 완료해야 합니다.

• 게이트웨이 프로필 만들기

• 게이트웨이의 여러 인스턴스 만들기

• 8 장, Secure Remote Access Gateway 구성

기타 게이트웨이 관련 항목은 다음과 같습니다.

• 게이트웨이 다시 시작

• 게이트웨이 워치독 구성

• 가상 호스트 지정

• Access Manage에 접속할 프록시 지정

게이트웨이 프로필 만들기

게이트웨이 프로필은 게이트웨이가 수신하는 포트, SSL 옵션 및 프록시 옵션과 같은 게이트웨이 구성과 관련된 모든 정보를 포함합니다. 게이트웨이를 설치하는 경우 기본값을 선택하면 "default"라는 기본 게이트웨이 프로필이 만들어집니다. 기본 프로필에 해당하는 구성 파일은 다음 위치에 있습니다. /etc/opt/SUNWportal/platform.conf.default.

여기서 /etc/opt/SUNWportal은 모든 platform.conf.* 파일의 기본 위치입니다. platform.conf 파일에 대한 자세한 내용은 platform.conf 파일 이해를 참조하십시오.

프로필과 관련하여 다음과 같은 작업을 수행할 수 있습니다.

• 여러 프로필을 만들어 각 프로필에 대한 속성을 정의한 다음 이 프로필을 필요에 따라 서로 다른 게이트웨이에 할당할 수 있습니다.

• 서로 다른 컴퓨터에 있는 게이트웨이 설치에 단일 프로필을 할당할 수 있습니다.

• 같은 컴퓨터에서 실행되는 단일 게이트웨이 인스턴스에 서로 다른 프로필을 할당할 수 있습니다.

같은 컴퓨터에서 실행되는 게이트웨이의 서로 다른 인스턴스에 같은 프로필을 할당하지 마십시오. 이렇게 설정하면 포트 번호가 같게 되므로 충돌이 발생합니다.

같은 게이트웨이에 만들어진 서로 다른 프로필에서 같은 포트 번호를 지정하지 마십시오. 동일한 게이트웨이의 포트 번호가 같은 다중 인스턴스를 실행하면 충돌이 발생합니다.

게이트웨이의 여러 인스턴스 만들기

여러 게이트웨이 인스턴스를 만들려면 Sun Java System Portal Server 7.2 Installation and Configuration Guide의 4 장, Installing and Configuring a Gateway With Portal Server을 참조하십시오.

다중 홈 게이트웨이 인스턴스 만들기

다중 홈 게이트웨이 인스턴스는 하나의 Portal Server에 여러 개의 게이트웨이가 있는 것입니다. 이러한 인스턴스를 만들려면 platform.conf 파일을 다음과 같이 수정합니다.

gatewaybindipaddress = 0.0.0.0

같은 LDAP를 사용하여 게이트웨이 인스턴스 만들기

같은 LDAP를 사용하는 게이트웨이 인스턴스 여러 개를 만드는 경우에는 첫 게이트웨이를 만든 후에 그 뒤의 모든 게이트웨이에서 다음을 수행합니다.

/etc/opt/SUNWam/config/에서 AMConfig-instance-name.properties의 다음 영역을 처음 설치한 게이트웨이 인스턴스와 일치하도록 수정합니다.

같은 LDAP를 사용하여 게이트웨이 인스턴스를 만들려면을 참조하십시오.

게이트웨이 다시 시작

일반적으로 게이트웨이를 다시 시작할 필요가 없습니다. 다음 이벤트가 발생한 경우에만 다시 시작합니다.

• 새 프로필을 만들고 이를 게이트웨이에 할당해야 하는 경우

• 기존 프로필의 일부 속성을 수정하고 변경 사항을 적용해야 하는 경우

• 메모리 부족(OutOfMemory)과 같은 오류 때문에 게이트웨이가 충돌하는 경우

• 게이트웨이가 응답을 중지하고 요청에 대한 서비스를 제공하지 않는 경우

게이트웨이 워치독 구성

워치독이 게이트웨이의 상태를 모니터링하게 될 시간 간격을 설정할 수 있습니다. 워치독을 시작 또는 중지하려면 ./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off 명령을 실행합니다. 시간 간격은 기본적으로 60초로 설정됩니다. 이 값을 변경하려면 crontab 유틸리티에서 다음 행을 편집합니다.

0-59 * * * * gateway-install-root/SUNWportal/bin/
/var/opt/SUNWportal/.gw. 5 > /dev/null 2>&1

crontab 항목을 구성하려면 crontab man 페이지를 참조하십시오.

가상 호스트 지정

가상 호스트는 같은 시스템 IP와 호스트 이름을 가리키는 추가 호스트 이름입니다. 예를 들어 호스트 이름 abc가 호스트 IP 주소 192.155.205.133을 가리키는 경우, 같은 IP 주소를 가리키는 다른 호스트 이름 cde를 추가할 수 있습니다.

Access Manage에 접속할 프록시 지정

게이트웨이에서 프록시 호스트를 사용하여 Portal Server에 배포되는 SRA 코어(RemoteConfigServlet)에 접속하도록 지정할 수 있습니다. 이 프록시는 게이트웨이가 Portal Server와 Access Manager에 접속하기 위해 사용됩니다. 프록시를 지정하려면을 참조하십시오.

platform.conf 파일 이해

platform.conf 파일은 기본적으로 다음 위치에 있습니다. /etc/opt/SUNWportal.

platform.conf 파일에는 게이트웨이에 필요한 상세 정보가 들어 있습니다. 이 절에는 예제 platform.conf 파일이 나와 있으며 모든 항목에 대해 설명합니다.

모든 컴퓨터별 상세 정보를 구성 파일에 포함시키면 공통 프로필을 여러 컴퓨터에서 실행되는 게이트웨이에서 공유할 수 있다는 장점이 있습니다.

다음은 platform.conf 파일의 샘플입니다.

Tue May 30 11:51:23 IST 2006
debug.com.sun.portal.rewriter.original.level=INFO
gateway.favicon=
gateway.bindipaddress=10.12.154.236
debug.com.sun.portal.sra.rproxy.toFromServer.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/Gateway.toFromServer.%u.%g.log
gateway.port=443
rewriterproxy.jvm.flags=-ms64m -mx128m
portal.server.instance=default
debug.com.sun.portal.handler.java.util.logging.FileHandler.filter=
gateway.jdk.dir=/usr/jdk/entsys-j2se
gateway.ignoreURIList=/MSOffice/cltreq.asp,/_vti_bin/owssvr.dll
debug.com.sun.portal.rewriter.rest.level=INFO
gateway.trust_all_server_certs=true
debug.com.sun.portal.handler.java.util.logging.FileHandler.append=true
gateway.cdm.cacheCleanupTime=300000
gateway.httpurl=
debug.com.sun.portal.handler.java.util.logging.FileHandler.count=1
gateway.jvm.classpath=
debug.com.sun.portal.setserverlogs=false
gateway.protocol=https
debug.com.sun.portal.sra.rproxy.toFromServer=java.util.logging.FileHandler
rewriterproxy.jvm.classpath=
gateway.enable.customurl=false
debug.com.sun.portal.sra.rproxy.toFromBrowser=java.util.logging.FileHandler
debug.com.sun.portal.handler.java.util.logging.FileHandler.formatter=com.sun.portal.
log.common.PortalLogFormatter
debug.com.sun.portal.sra.rproxy.toFromBrowser.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/Gateway.toFromBrowser.%u.%g.log
debug.com.sun.portal.level=INFO
debug.com.sun.portal.rewriter.unaffected.separatefile=true
gateway.enable.accelerator=false
debug.com.sun.portal.rewriter.original.separatefile=true
gateway.virtualhost=nicp236.india.sun.com 10.12.154.236
debug.com.sun.portal.stacktrace=true 
gateway.host=nicp236.india.sun.com
debug.com.sun.portal.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/%logger.%sraComponentType.%u.%g.log
gateway.certdir=/etc/opt/SUNWportal/cert/default
gateway.sockretries=3
gateway.allow.client.caching=true
debug.com.sun.portal.rewriter.unaffected.level=INFO
debug.com.sun.portal.rewriter.uriinfo.separatefile=true
log.config.check.period=2000
debug.com.sun.portal.rewriter.rewritten.level=INFO
gateway.userProfile.cacheSize=1024
debug.com.sun.portal.rewriter.rulesetinfo.level=INFO
netletproxy.jvm.classpath=
gateway.userProfile.cacheSleepTime=60000
debug.com.sun.portal.rewriter.uriinfo.level=INFO
debug.com.sun.portal.rewriter.rest.separatefile=true
gateway.notification.url=notification
debug.com.sun.portal.rewriter.rulesetinfo.separatefile=true
gateway.logdelimiter=&&
gateway.ignoreServerList=false
gateway.jvm.flags=-ms64m -mx128m
debug.com.sun.portal.handler.java.util.logging.FileHandler.limit=5000000
gateway.dsame.agent=http\://sunone216.india.sun.com\:8080/portal/RemoteConfigServlet
gateway.httpsurl=
gateway.retries=6
gateway.userProfile.cacheCleanupTime=300000
gateway.logging.password=X03MO1qnZdYdgyfeuILPmQ\=\= UX9x0jIua3hx1YOVRG/TLg\=\=
netletproxy.jvm.flags=-ms64m -mx128m
debug.com.sun.portal.rewriter.rewritten.separatefile=true
gateway.user=noaccess
gateway.external.ip=10.12.154.236
debug.com.sun.portal.handler=java.util.logging.FileHandler
gateway.cdm.cacheSleepTime=60000
rewriterproxy.accept.from.gateways=
rewriterproxy.checkacl=false

다음 표에는 platform.conf 파일의 모든 필드와 해당 설명이 정리되어 있습니다.

웹 프록시 사용

타사 웹 프록시를 사용하여 HTTP 자원에 연결하도록 게이트웨이를 구성할 수 있습니다. 웹 프록시는 클라이언트와 인터넷 사이에 상주합니다.

웹 프록시 구성

여러 도메인 및 부속 도메인에 서로 다른 프록시가 사용될 수 있습니다. 이 항목은 특정 도메인에서 특정 부속 도메인에 연결할 때 어떤 프록시를 사용할지 게이트웨이에 알려 줍니다. 게이트웨이에 지정된 프록시 구성은 다음과 같이 작동합니다.

• 게이트웨이 서비스의 [도메인 및 부속 도메인의 프록시] 필드에 필요한 프록시와 함께 도메인 및 부속 도메인 목록을 만듭니다.

• 프록시 사용 옵션을 사용하는 경우,

  • [도메인 및 부속 도메인의 프록시] 필드에 지정된 프록시가 지정된 호스트에 사용됩니다.

  • 도메인 및 부속 도메인의 프록시 목록에 지정된 도메인 및 부속 도메인에서 특정 URL에 직접 연결하려면 [웹 프록시 URL 사용 안함] 필드에서 해당 URL을 지정합니다.

  프록시 사용 옵션이 사용 불가능 상태인 경우,

  • 프록시가 도메인 및 부속 도메인의 프록시 필드에 지정된 도메인과 부속 도메인에서 특정 URL에 사용되도록 하려면 [웹 프록시 URL 사용] 목록에서 해당 URL을 지정합니다.

    프록시 사용 옵션이 사용 불가능 상태이더라도 [웹 프록시 사용]에 나열된 URL에 프록시를 사용하여 연결할 수 있습니다. 이 URL의 프록시는 [도메인 및 부속 도메인의 프록시] 목록에서 가져온 것입니다.

    다음 그림에서는 게이트웨이 서비스의 프록시 구성에 기반하여 웹 프록시 정보가 어떻게 결정되는지 보여줍니다.

    

    웹 프록시 구성에서 프록시 사용이 활성화되어 있고, 요청된 URL이 [웹 프록시 URL 사용 안함] 목록에 나열되는 경우 게이트웨이가 대상 호스트에 직접 연결됩니다.

    프록시 사용이 활성화되어 있고, 요청된 URL이 [웹 프록시 URL 사용 안함] 목록에 나열되지 않은 경우 게이트웨이는 지정된 프록시를 통해 대상 호스트에 연결됩니다. 프록시가 지정되어 있는 경우에는 [도메인 및 부속 도메인의 프록시] 목록에서 찾으면 됩니다.

    프록시 사용이 비활성화되어 있고, 요청된 URL이 [웹 프록시 URL 사용] 목록에 나열되면 게이트웨이는 [도메인 및 부속 도메인의 프록시] 목록에 있는 프록시 정보를 사용하여 대상 호스트에 연결됩니다.

    프록시 사용이 비활성화되어 있고, 요청된 URL이 [웹 프록시 URL 사용] 목록에 나열되지 않으면 게이트웨이가 대상 호스트에 직접 연결됩니다.

    위에 설명된 조건 중 어느 것에도 해당하지 않아서 직접 연결이 불가능하면 연결할 수 없다는 게이트웨이 오류 메시지를 표시합니다.

표준 포털 데스크탑의 책갈피 채널을 통해 URL에 액세스하는 중에 위에 설명된 조건 중 어느 것도 충족되지 않으면 게이트웨이는 브라우저로 리디렉션합니다. 그러면 브라우저는 자체 프록시 설정을 통해 URL에 액세스합니다.

구문

domainname [web_proxy1:port1]|subdomain1 [web_proxy2:port2]|

예

sesta.com wp1:8080|red wp2:8080|yellow|* wp3:8080

*는 모든 항목과 일치하는 와일드카드입니다.

여기서,

sesta.com은 도메인 이름이고 wp1은 포트 8080에 연결할 프록시입니다.

red는 하위 도메인이고 wp2는 포트 8080에 연결할 프록시입니다.

yellow는 하위 도메인입니다. 프록시가 지정되어 있지 않고 포트 8080에 도메인에 지정된 프록시 즉, wp1이 사용됩니다.

*는 모든 다른 하위 도메인에서 포트 8080에 wp3을 사용해야 함을 나타냅니다.

포트를 지정하지 않은 경우 기본적으로 포트 8080이 사용됩니다.

웹 프록시 정보처리

클라이언트가 특정 URL에 액세스하려고 하면 해당 URL의 호스트 이름이 [도메인 및 하위 도메인의 프록시] 목록의 항목과 일치됩니다. 요청된 호스트 이름의 가장 긴 접미어에 일치하는 항목이 선택됩니다. 예를 들어, 요청된 호스트 이름이 host1.sesta.com이라고 가정해 보겠습니다. 다음 검색 작업은 일치하는 항목을 찾을 때까지 수행됩니다.

• [도메인 및 하위 도메인의 프록시]에 host1.sesta.com이 있는지 검색합니다. 일치하는 항목이 있으면 이 항목에 지정된 프록시를 통해 그 호스트에 연결됩니다.

• 그렇지 않으면 목록에 *.sesta.com이 있는지 검색합니다. 항목을 찾으면 해당 프록시가 사용됩니다.

• 그렇지 않으면 목록에 sesta.com이 있는지 검색합니다. 항목을 찾으면 해당 프록시가 사용됩니다.

• 그렇지 않으면 목록에 *.com이 있는지 검색합니다. 항목을 찾으면 해당 프록시가 사용됩니다.

• 그렇지 않으면 목록에 com이 있는지 검색합니다. 항목을 찾으면 해당 프록시가 사용됩니다.

• 그렇지 않으면 목록에서 *에 대한 검색을 수행합니다. 항목을 찾으면 해당 프록시가 사용됩니다.

• 일치하는 항목이 없으면 직접 연결을 시도합니다.

[도메인 및 부속 도메인의 프록시] 목록에서 다음 항목을 고려합니다.

com p1| host1 p2 | host2 | * p3
sesta.com p4 | host5 p5 | * p6
florizon.com | host6
abc.sesta.com p8 | host7 p7 | host8 p8 | * p9
host6.florizon.com p10
host9.sesta.com p11
siroe.com | host12 p12 | host13 p13 | host14 | * p14
siroe.com | host15 p15 | host16 | * p16
* p17

게이트웨이에서는 내부적으로 이러한 항목을 다음 표에 나와 있는 것처럼 테이블로 매핑합니다.

[도메인 및 부속 도메인의 프록시] 목록에서 프록시 항목을 | 기호로 분리하는 대신 목록에서 개별 항목을 별도의 행으로 지정할 수 있습니다. 예를 들어, 다음과 같은 항목 대신에

sesta.com p1 | red p2 | * p3

이 정보를 다음과 같이 지정할 수 있습니다.

sesta.com p1
red.sesta.com p2
*.sesta.com p3

이 목록 형식을 사용하면 반복되는 항목이나 기타 모호한 부분을 쉽게 파악할 수 있습니다.

도메인 및 부속 도메인의 프록시 목록에 기반하여 다시 쓰기

[도메인 및 부속 도메인의 프록시] 목록의 항목도 Rewriter에서 사용됩니다. Rewriter는 도메인이 [도메인 및 부속 도메인의 프록시] 목록에 나열된 도메인과 일치하는 모든 URL을 다시 씁니다.

[도메인 및 하위 도메인의 프록시] 목록의 * 항목은 다시 쓰기에 고려되지 않습니다. 예를 들어 24번 항목은 고려 대상이 되지 않습니다.

Rewriter에 대한 자세한 정보는 4 장, Rewriter 작업을 참조하십시오.

기본 도메인 및 부속 도메인

URL의 대상 호스트가 정규 호스트 이름이 아닐 경우, 정규 이름에 도달하도록 기본 도메인 및 부속 도메인을 사용합니다.

관리 콘솔의 [기본 도메인] 필드 항목이 다음과 같다고 가정해 보겠습니다.

red.sesta.com

[도메인 및 부속 도메인의 프록시] 목록에 해당하는 항목이 있어야 합니다.

위의 예에서는 sesta.com이 기본 도메인이고 기본 하위 도메인은 red입니다.

요청된 URL이 host1인 경우, 이 항목은 기본 도메인 및 하위 도메인을 통해 host1.red.sesta.com으로 결정됩니다. 그런 다음 [도메인 및 하위 도메인의 프록시] 목록에 host1.red.sesta.com이 있는지 확인합니다.

자동 프록시 구성 사용

[도메인 및 부속 도메인의 프록시] 목록에 있는 정보를 무시하려면 자동 프록시 구성(PAC) 기능을 활성화합니다.

자동 프록시 구성(PAC) 파일을 사용하는 경우

• Portal Server, Gateway, Netlet 및 Proxylet은 Rhino 소프트웨어를 사용하여 PAC 파일을 구문 분석합니다. SUNWrhino 패키지는 Java Enterprise System Accessory CD에서 설치할 수 있습니다.

  이 패키지에는 /usr/share/lib 디렉토리에 반드시 있어야 하는 js.jar 파일이 포함되어 있습니다. 이 디렉토리를 게이트웨이 및 Portal Server 시스템의 webserver/appserver 클래스 경로에 추가합니다. 그렇지 않으면 Portal Server, Gateway, Netlet 및 Proxylet에서 PAC 파일을 구문 분석할 수 없습니다.

• js.jar은 게이트웨이 컴퓨터의 $JRE_HOME/lib/ext 디렉토리에 있어야 합니다. 그렇지 않으면 게이트웨이에서 PAC 파일의 구문을 분석할 수 없습니다.

• 게이트웨이는 부팅 시에 게이트웨이 프로필 [자동 프록시 구성 파일] 위치 필드에 지정된 위치로부터 PAC 파일을 불러옵니다.

• 게이트웨이는 URLConnection API를 사용하여 이 위치에 도달합니다. 프록시가 게이트웨이에 도달하도록 구성해야 하는 경우에는 프록시를 다음과 같이 구성해야 합니다.

  1. 명령줄에서 다음 파일을 편집합니다.

     /etc/opt/SUNWportal/platform.conf.gateway-profile-name

  2. 다음 항목을 추가합니다.

     http.proxyHost= web-proxy-hostname

     http.proxyPort= web-proxy-port

     http.proxySet=true

  3. 게이트웨이를 다시 시작하여 지정된 프록시를 사용합니다.

     ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

• PAC 파일 초기화가 실패하면 게이트웨이는 [도메인 및 부속 도메인의 프록시] 목록에 있는 정보를 사용합니다.

• PAC 파일로부터 "" (빈 문자열) 이나 "null"이 반환되면 게이트웨이에서는 호스트가 인트라넷에 속하지 않는 것으로 가정합니다. 이는 호스트가 [도메인 및 부속 도메인의 프록시] 목록에 있지 경우와 비슷합니다.

  게이트웨이에서 호스트에 직접 연결되도록 하려면 "DIRECT"를 반환합니다. DIRECT 또는 NULL이 반환되는 예제를 참조하십시오.

• 여러 프록시가 지정되어 있으면 게이트웨이는 첫 번째 반환된 프록시만 사용합니다. 호스트에 지정된 여러 프록시에서 페일오버나 로드 균형 조정을 시도하지 않습니다.

• 게이트웨이는 SOCKS 프록시를 무시하고 직접 연결을 시도하면서 호스트가 인트라넷의 일부라 가정합니다.

• 인트라넷의 일부가 아닌 호스트에 도달하는 데 프록시를 사용하도록 지정하려면 프록시 유형 STARPROXY를 사용합니다. 이 프록시 유형은 PAC 파일 형식의 확장이며 게이트웨이 프로필에 있는 [도메인 및 하위 도메인의 프록시] 부분의 * proxyHost:port 항목과 유사합니다. STARPROXY가 반환되는 예제를 참조하십시오.

예제 PAC 파일 사용

다음 예제는 [도메인 및 부속 도메인의 프록시] 목록과 해당하는 PAC 파일에 나열된 URL을 보여줍니다.

DIRECT 또는 NULL이 반환되는 예제

도메인 및 하위 도메인에 사용되는 프록시:

*intranet1.com proxy.intranet.com:8080

intranet2.com proxy.intranet1.com:8080

해당하는 PAC 파일:

// Start of the PAC File
function FindProxyForURL(url, host) {
         if (dnsDomainIs(host, ".intranet1.com")) {
             return "DIRECT";
         }
          if (dnsDomainIs(host, ".intranet2.com")) {
              return "PROXY proxy.intranet1.com:8080";
          }
          return "NULL";
}
//End of the PAC File

STARPROXY가 반환되는 예제

도메인 및 하위 도메인에 사용되는 프록시:

intranet1.com

intranet2.com.proxy.intranet1.com:8080

internetproxy.intranet1.com:80

해당하는 PAC 파일:

// Start of the PAC File
function FindProxyForURL(url, host) {
          if (dnsDomainIs(host, ".intranet1.com")) {
              return "DIRECT";
          }
          if (dnsDomainIs(host, ".intranet2.com")) {
              return "PROXY proxy.intranet1.com:8080;" +
                  "PROXY proxy1.intranet1.com:8080";
          }
          return "STARPROXY internetproxy.intranet1.com:80";
}
//End of the PAC File

이 경우 요청이 .intranet2.com 도메인에 있는 호스트에 대한 것이면 게이트웨이는 proxy.intranet1.com:8080에 접속합니다. proxy.intranet1.com:8080이 다운되면 요청이 실패합니다. 게이트웨이는 페일오버하지 않고 proxy1.intranet1.com:8080에 접속합니다.

PAC 파일 위치 지정

PAC 파일의 위치를 지정하는 형식은 다음과 같이 해당 위치에 따라 다릅니다.

• PAC 파일이 웹 서버에 상주하는 경우 다음과 같이 PAC URL을 입력합니다.

  http://hostname/pacfile_name .pac

• PAC 파일이 로컬 파일(예: c:\\pacfile\\sample.pac)인 경우 java 1.4.1_x에 대해 다음과 같이 PAC URL을 입력합니다.

  file://c:/pacfile/sample.pac

• PAC 파일이 로컬 파일(예: c:\\pacfile\\sample.pac)인 경우 java 1.4.2_x에 대해 다음과 같이 PAC URL을 입력합니다.

  file:///c:/pacfile/sample.pac

별도 세션에서 서비스 추가

Portal Server 서비스를 별도 세션에서 추가할 경우

• Portal Server가 Portal Server 관리 콘솔의 [게이트웨이] > [핵심] 아래에 나열됩니다.

• Portal Server URL은 [게이트웨이] > [보안] 아래의 비인증 URL에 나열됩니다.

Netlet 프록시 사용

Netlet 패킷은 게이트웨이에서 비밀번호가 해독되어 대상 서버로 보내집니다. 그러나 게이트웨이는 비무장 지대(DMZ)와 인트라넷 사이의 방화벽을 통해 모든 Netlet 대상 호스트에 액세스해야 합니다. 따라서 이렇게 설정하면 방화벽에서 많은 포트를 열어야 합니다. Netlet 프록시는 방화벽에서 열린 포트의 수를 줄이는 데 사용할 수 있습니다.

Netlet 프록시는 클라이언트로부터 게이트웨이를 거쳐 인트라넷에 상주하는 Netlet 프록시에 이르기까지 보안 터널을 확장하여 게이트웨이와 인트라넷 사이의 보안을 강화합니다. 프록시가 있으면 Netlet 패킷은 프록시에서 해독된 후 대상으로 보내집니다.

Netlet 프록시를 사용하면 다음과 같은 장점이 있습니다.

• 보안 계층을 추가할 수 있습니다.

• 상당한 규모의 배치 환경에서 내부 방화벽을 통해 추가 IP 주소와 게이트웨이의 포트 사용을 최대한 줄일 수 있습니다.

• 게이트웨이와 Portal Server 간 개방 포트 수를 1로 제한할 수 있습니다. 이 포트 수는 설치 시 구성 가능합니다.

• 클라이언트와 게이트웨이 사이의 보안 채널을 Netlet 프록시 사용의 "Netlet 프록시가 구성되어 있는 경우" 부분에 나와 있듯이 Portal Server까지 확장할 수 있습니다. Netlet 프록시는 데이터 암호화를 통해 보안을 강화한다는 이점이 있지만 시스템 자원을 더 많이 사용할 수 있습니다. Netlet 프록시 설치에 대한 자세한 내용은 Sun Java System 설치 설명서를 참조하십시오.

다음과 같은 작업을 수행할 수 있습니다.

• Portal Server 노드나 별도 노드에 Netlet 프록시를 설치할 수 있습니다.

• 다중 Netlet 프록시를 설치하고 관리 콘솔을 사용하여 단일 게이트웨이에 구성할 수 있습니다. 로드 균형 조절에 유용합니다.

• 단일 시스템에 Netlet 프록시의 다중 인스턴스를 구성할 수 있습니다.

• 게이트웨이의 다중 인스턴스를 Netlet 프록시의 단일 설치에 지정할 수 있습니다.

• 웹 프록시를 통해 Netlet을 통과할 수 있습니다.

Netlet 프록시가 설치된 경우와 설치되지 않은 경우, 게이트웨이와 Portal Server를 구현하는 3가지 구현 샘플이 나와 있습니다. 구성 요소에는 클라이언트, 방화벽 2개, 두 방화벽 사이에 상주하는 게이트웨이, Portal Server 및 Netlet 대상 서버가 포함됩니다.

첫 번째 시나리오는 Netlet 프록시가 설치되지 않은 경우의 게이트웨이와 Portal Server를 보여줍니다. 데이터 암호화는 클라이언트에서 게이트웨이까지만 적용됩니다. 각 Netlet 연결 요청을 위해 두 번째 방화벽에서 포트가 1개 개방되어 있습니다.

두 번째 시나리오는 Netlet 프록시가 Portal Server에 설치된 경우의 게이트웨이와 Portal Server를 보여줍니다. 데이터 암호화는 클라이언트에서 Portal Server까지 전체적으로 적용됩니다. 모든 Netlet 연결이 Netlet 프록시를 통해 라우팅되기 때문에 두 번째 방화벽에서 Netlet 요청에 사용되는 포트는 하나만 열려 있으면 됩니다.

세 번째 시나리오는 Netlet 프록시가 별도 노드에 설치된 경우의 게이트웨이와 Portal Server를 보여줍니다. Netlet 프록시를 별도 노드에 설치하면 Portal Server 노드의 로드가 줄어듭니다. 여기서는 두 번째 방화벽에서 2개의 포트만 개방되어 있으면 됩니다. 한 포트는 Portal Server에 대한 요청을 처리하고 다른 포트는 Netlet 프록시 서버에 대한 Netlet 요청을 라우팅합니다.

그림 2–1 Netlet 프록시 구현

Netlet 프록시 활성화

Portal Server 관리 콘솔을 사용하여 게이트웨이 서비스를 통해 Netlet 프록시를 사용할 수 있습니다.

Netlet 프록시 다시 시작

프록시가 예기치 않게 중지될 때마다 다시 시작하도록 Netlet 프록시를 구성할 수 있습니다. Netlet 프록시를 모니터링하고 다운된 경우 다시 시작하도록 워치독 프로세스를 예약할 수 있습니다.

Netlet 프록시를 수동으로 다시 시작할 수도 있습니다. 자세한 단계는 Netlet 프록시를 다시 시작하려면을 참조하십시오.

Netlet 프록시 워치독을 구성하려면

워치독이 Netlet 프록시의 상태를 모니터하는 시간 간격을 구성할 수 있습니다. 시간 간격은 기본적으로 60초로 설정됩니다. 이 간격을 변경하려면 다음 행을 crontab 파일에 추가합니다.

0-59 * * * * netlet-install-dir/bin/checkgw /var/opt/SUNWportal/.gw 5 > /dev/null 2>&1

워치독을 시작 또는 중지하려면 ./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off 명령을 실행합니다.

Rewriter 프록시 사용

Rewriter 프록시는 인트라넷에 설치됩니다. 게이트웨이는 컨텐트를 직접 검색하는 대신, 컨텐트를 가져와 게이트웨이로 반환하는 Rewriter 프록시로 모든 요청을 전달합니다.

Rewriter 프록시를 사용하면 다음과 같은 장점이 있습니다.

• 게이트웨이와 서버 사이에 방화벽이 있는 경우 방화벽에서는 포트를 2개만 열면 됩니다. 하나는 게이트웨이와 Rewriter 프록시 사이의 포트이고 다른 하나는 게이트웨이와 Portal Server 사이의 포트입니다.

• 대상 서버가 HTTP 프로토콜만 지원하고 HTTPS는 지원하지 않아도 게이트웨이와 인트라넷 사이의 HTTP 트래픽이 안정적으로 됩니다.

Rewriter 프록시를 지정하지 않으면 사용자가 인트라넷 컴퓨터에 액세스하려고 할 때 게이트웨이 구성 요소에서 인트라넷 컴퓨터에 직접 연결합니다.

Rewriter 프록시를 로드 조정기로 사용하는 경우에는 Rewriter의 platform.conf.instance_name이 로드 조정기 URL을 가리키는지 확인해야 합니다. 또한 [Portal Servers] 목록에서 로드 밸런서 호스트를 지정하십시오.

각 게이트웨이 인스턴스에 대해 여러 Rewriter 프록시 인스턴스가 있는 경우(포털 노드에서는 필요하지 않음) platform.conf 파일에서 Rewriter 프록시의 단일 포트 항목이 아니라 host-name:port 형식으로 각 Rewriter 프록시의 세부 사항을 입력합니다.

Rewriter 프록시의 인스턴스 만들기

rwpmultiinstance 스크립트를 사용하여 Portal Server 노드에 Rewriter 프록시의 새 인스턴스를 만듭니다. 게이트웨이 프로필을 만든 후에 이 스크립트를 실행하십시오.

Rewriter 프록시 인스턴스를 만들려면을 참조하십시오.

Rewriter 프록시 활성화

Access Manager 관리 콘솔의 SRA 구성에서 게이트웨이 서비스를 통해 Rewriter 프록시를 활성화합니다.

Rewriter 프록시 다시 시작

프록시가 예기치 않게 중지될 때마다 다시 시작하도록 Rewriter 프록시를 구성할 수 있습니다. 이런 문제가 발생하는지 모니터링하고 문제가 발생하면 다시 시작하도록 워치독 프로세스를 예약할 수 있습니다.

Rewriter 프록시를 수동으로 다시 시작할 수도 있습니다.

Rewriter 프록시를 다시 시작하려면을 참조하십시오.

Rewriter 프록시 워치독 구성

워치독이 Rewriter 프록시 상태를 모니터링하는 시간 간격을 구성할 수 있습니다. 시간 간격은 기본적으로 60초로 설정됩니다. 시간 간격을 변경하려면 crontab 파일에 다음 행을 추가하십시오.

0-59 * * * * rewriter-proxy-install-root /bin/checkgw /var/opt/SUNWportal/.gw 5 > /dev/null 2>&1

워치독을 시작 또는 중지하려면 ./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off 명령을 실행합니다.

게이트웨이에서 역방향 프록시 사용

프록시 서버는 인트라넷에 인터넷 컨텐트를 서비스하고 역 프록시는 인터넷에 인트라넷 컨텐트를 서비스합니다. 로드 균형 조절 및 캐싱을 수행하도록 역방향 프록시의 배포를 구성할 수 있습니다.

이 배포에서 게이트웨이 전방에 타사의 역 프록시가 사용된다면 게이트웨이의 URL 대신 역 프록시의 URL로 응답을 다시 써야 합니다. 이를 위해 다음 구성이 필요합니다.

역 프록시를 활성화하려면을 참조하십시오.

클라이언트 정보 가져오기

게이트웨이가 클라이언트 요청을 내부 서버로 전달하면 HTTP 헤더가 HTTP 요청에 추가됩니다. 이 헤더를 사용하여 추가 클라이언트 정보를 가져오고 게이트웨이가 있는지 감지할 수 있습니다.

HTTP 요청 헤더를 보려면 platform.conf 파일에서 해당 항목을 gateway.error=message로 설정합니다. 그런 다음 서블릿 API에서 request.getHeader()를 사용하십시오. 다음 표에는 HTTP 헤더에 있는 정보가 나열되어 있습니다.

인증 체이닝 사용

인증 체이닝은 인증의 일반 메커니즘보다 높은 수준으로 보안을 강화합니다. 사용자가 2개 이상 인증 메커니즘에 대해 인증 받도록 설정할 수 있습니다.

여기에 설명된 절차는 게이트웨이에서 개인 디지털 인증서(PDC) 인증과 함께 인증 체이닝을 사용하는 경우에만 적용됩니다. 게이트웨이에 PDC 인증이 없는 인증 체이닝에 대한 자세한 내용은 Access Manager 관리 설명서를 참조하십시오.

예를 들어, PDC 및 Radius 인증 모듈을 체이닝한 경우에는 사용자가 표준 포털 데스크탑에 액세스하려면 이 3개 모듈에 대한 인증을 모두 거쳐야 합니다.

자세한 단계는 기존 PDC 인스턴스에 인증 모듈을 추가하려면 을 참조하십시오.

활성화된 경우 PDC는 사용자에게 항상 가정 먼저 제시되는 인증 모듈입니다.

와일드카드 인증 사용

와일드카드 인증에서는 정규 DNS 호스트 이름에 와일드카드 문자가 있는 단일 인증을 수락합니다.

인증서가 있으면 동일한 도메인 내의 여러 호스트가 보호됩니다. 예를 들어, *.domain.com에 대한 인증을 abc.domain.com 및 abc1.domain.com에 사용할 수 있습니다. 이 인증은 domain.com 도메인에 있는 모든 호스트에 유효합니다.

브라우저 캐싱 사용 불가능

게이트웨이 구성 요소는 웹 브라우저를 사용하여 어느 위치에서나 백엔드 기업 데이터에 안전하게 액세스하므로 클라이언트가 정보를 로컬로 캐싱할 필요가 없습니다.

특정 게이트웨이의 platform.conf 파일에 있는 속성을 수정하여 게이트웨이를 통해 리디렉션된 페이지의 캐싱을 비활성화할 수 있습니다.

이 옵션을 비활성화하면 게이트웨이 성능에 영향을 줄 수 있습니다. 표준 포털 데스크탑을 새로 고칠 때마다 게이트웨이는 브라우저에서 이전에 캐싱한 이미지와 같이 페이지에서 참조되는 모든 항목을 검색해야 합니다. 그러나 이 기능을 사용하면 원격으로 액세스한 보안 컨텐트를 캐싱한 자취가 클라이언트 사이트에 남지 않습니다. 인터넷 카페 또는 기업 IT 제어를 받지 않는 유사한 원격 장소로부터 기업 네트워크에 액세스하는 경우 이 기능은 비중이 있을 수 있습니다.

브라우저 캐싱을 비활성화하려면을 참조하십시오.

게이트웨이 서비스 사용자 인터페이스 사용자 정의

이 절에서는 편집할 수 있는 여러 게이트웨이 등록 정보 파일에 대해 설명합니다.

srapGateway.properties 파일 수정

다음과 같은 목적으로 이 파일을 편집할 수 있습니다.

• 게이트웨이 실행 중에 나타날 수 있는 오류 메시지를 사용자 정의할 때

  • HTML-CharSets=ISO-8859-1은 이 파일을 만드는 데 사용되는 문자 집합을 지정합니다.

  • 중괄호 안의 숫자(예: {0})는 값이 런타임으로 표시된다는 것을 뜻합니다. 필요에 따라 이 숫자와 연관된 레이블을 변경하거나 레이블을 재배열할 수 있습니다. 레이블 숫자와 오류는 연관되어 있기 때문에 레이블에 해당하는 표시될 메시지가 있어야 합니다.

  로그 정보를 사용자 정의할 때.

  기본적으로 srapGateway.properties 파일은 portal-server-install-root /SUNWportal/locale 디렉토리에 있습니다. 게이트웨이 컴퓨터에 표시되는 모든 메시지는 해당 메시지의 언어와 상관 없이 이 파일에 있습니다.

  클라이언트 표준 포털 데스크탑에 나타나는 메시지의 언어를 변경하려면 이 파일을 각 로켈 디렉토리로 복사합니다(예: portal-server-install-root /SUNWportal/locale_en_US).

srapgwadminmsg.properties 파일 수정

다음과 같은 이유로 이 파일을 편집할 수 있습니다.

• 관리 콘솔의 게이트웨이 서비스에 대한 버튼에 나타나는 레이블을 사용자 정의할 때

• 게이트웨이를 구성하는 중에 나타나는 상태 메시지 및 오류 메시지를 사용자 정의할 때

LDAP 디렉토리 공유

Portal Server 및 Access Manager 서버의 두 인스턴스가 같은 LDAP 디렉토리를 공유하는 경우 모든 후속 Portal Server, Access Manager 및 게이트웨이 인스턴스에서 같은 LDAP 디렉토리를 공유합니다. LDAP 디렉토리를 공유하려면을 참조하십시오.

3장 Proxylet 작업

이 장에서는 사용자가 웹 페이지를 구문 분석하지 않고도 게이트웨이를 통해 인트라넷 웹 페이지에 액세스할 수 있게 해주는 Proxylet에 대해 설명합니다.

Proxylet 작업

Proxylet 개요

Proxylet은 클라이언트 시스템에서 자체를 프록시 서버로 설정하는 Java 애플릿입니다. Proxylet은 클라이언트 시스템에 있는 프록시 자동 구성(PAC) 파일의 프록시 설정을 읽고 프록시 설정이 로컬 프록시 서버 또는 Proxylet을 가리키도록 수정합니다.

Proxylet은 게이트웨이에서 전송 모드를 상속합니다. 게이트웨이가 SSL에서 실행되도록 구성되어 있으면 Proxylet은 클라이언트 시스템과 게이트웨이 또는 대상 서버 사이에 보안 채널을 구성합니다. 암호화를 위해, 클라이언트 JVM이 1.4 이상이거나 필요한 jar 파일이 클라이언트 시스템에 상주하는 경우에는 Proxylet에서 JSSE API를 사용합니다. 그렇지 않으면 KSSL API를 사용합니다. 해독 작업은 클라이언트 컴퓨터에서 수행됩니다.

게이트웨이로 리디렉션되는 URL의 도메인 및 부속 도메인은 게이트웨이 프로필에서 지정됩니다. URL이 게이트웨이가 처리하는 도메인에 속하지 않으면 요청은 인터넷으로 지정됩니다. 게이트웨이 프로필에 특정 URL 도메인이 나열되어 있으면 Proxylet은 게이트웨이를 가리키도록 클라이언트 프록시 설정을 재설정합니다.

Proxylet은 PDC(Personal Digital Certificate)가 게이트웨이에서 활성화된 경우 클라이언트용 인증을 지원합니다. PDC 사용 여부를 확인하려면 클라이언트 정보 가져오기를 참조하십시오.

Proxylet은 클라이언트 IP 주소 또는 프록시 호스트 이름과 포트를 지정한 Portal Server 관리 콘솔에서 활성화됩니다. Proxylet을 활성화하면 클라이언트 시스템에서 다음 정보가 확인됩니다.

• 적절한 브라우저 권한

• 브라우저가 IE 6.0 sp2, IE 7 및 Firefox 2.0인지 여부

• 시스템 또는 장치에서 서버 응용 프로그램을 실행할 수 있는지 여부

모든 요구 사항이 만족되면 애플릿이 클라이언트 시스템으로 다운로드되어 실행됩니다. 클라이언트에 JRE 1.4.2 이상이 설치되어 있지 않은 경우 인터넷에 연결되어 있고 관리자 권한이 있으면 Proxylet과 함께 JRE가 자동으로 다운로드됩니다.

Proxylet이 사용되는 경우 Proxylet은 PAC(Proxy Auto Configuration) 또는 프록시 구성 목록에서 프록시 설정을 검색합니다.

Proxylet 애플릿을 사용하는 경우 브라우저의 팝업 차단 기능을 비활성화해야 합니다.

HTTPS 지원

Proxylet은 HTTPS를 지원하며 다음 결과가 나타납니다.

• 해독 기능은 클라이언트 서버에서 수행됩니다.

• 대상 서버는 SSL 모드에서 실행하는 경우 액세스할 수 있습니다.

• 클라이언트 인증서는 대상 서버에 직접 제공됩니다.

• 기본 인증 단일 사인온(SSO)은 게이트웨이에서 지원되지 않습니다. (게이트웨이에서 HTTP 헤더에 SSO 정보를 삽입할 수 없습니다.)

• URL 기반 액세스 제어는 지원되지 않으며 호스트 기반 액세스 제어만 지원됩니다.

• 게이트웨이 앞의 외부 가속기와 외부 역 프록시는 현재 지원되지 않습니다.

  ---

  주 –

  이 지원은 Portal Server가 HTTPS를 사용하는 경우 Proxylet을 지원하기 위한 것이 아닙니다.

  ---

Proxylet 사용의 이점

Rewriter와 달리 Proxylet은 설치 후에 조금만 변경하거나 변경하지 않아도 됩니다. Microsoft Exchange Server 등의 타사 소프트웨어와 쉽게 통합할 수 있습니다. 또한 Proxylet에서 웹 컨텐트에 대한 작업을 수행하지 않으므로 게이트웨이의 성능이 향상됩니다. Proxylet에서 컨텐트를 수정하거나 데이터를 변경하지 않기 때문에 사용자는 tar 및 gzip 파일과 같은 컨텐트 유형을 다운로드할 수 있습니다.

Proxylet 구성

Proxylet 사용 및 구성에 대한 자세한 내용은 13 장, Proxylet 구성을 참조하십시오.

사용자가 Proxylet을 실행할 수 있는 JVM(Java Virtual Machine)을 가지고 있지 않으면 브라우저에서 Sun 웹 사이트에 연결하여 JRE(Java Runtime Environment)를 다운로드합니다. 사용자의 브라우저 설정에 정확한 값이 포함되어 있지 않거나 사용자가 인터넷에 액세스하지 않고 직접 프록시 설정을 사용하는 경우 Proxylet을 다운로드할 수 없습니다.

4장 Rewriter 작업

Secure Remote Access의 Rewriter 구성 요소를 사용하면 사용자가 인트라넷 웹 페이지를 분석하여 게이트웨이를 통해 해당 웹 페이지에 액세스할 수 있습니다.

이 장에서는 다음 주제를 다룹니다.

• 문자 집합 암호화

• Rewriter 사용 시나리오

• 규칙 집합 작성

• 공용 인터페이스(규칙 집합 DTD)

• 디버그 로그를 사용한 문제 해결

• 공용 인터페이스(규칙 집합 DTD)

• 작업 예제

• 사례 연구

• 6.x 규칙 집합을 3.0과 매핑

Rewriter 소개

SRA(Secure Remote Access)의 Rewriter 구성 요소를 통해 최종 사용자가 게이트웨이를 가리키도록 웹 페이지의 URI(Uniform Resource Identifier)를 수정하여 인트라넷을 찾아볼 수 있습니다. URI는 등록된 이름 공간에서 이름을 캡슐화하고 여기에 이름 공간으로 레이블을 설정하는 방법을 정의합니다. URI의 가장 일반적인 유형으로는 URL(Uniform Resource Locator)이 있습니다. Rewriter는 HTTP 또는 HTTPS만 지원합니다. 이러한 지원은 프로토콜에서 대소문자를 구분하지 않고 이루어집니다. Rewriter는 상대 URL의 일부인 경우에만 백슬래시를 지원합니다.

예 4–1 URL 다시 쓰기

http://abc.sesta.com\\index.html이 다시 작성됩니다.

다시 작성되지 않는 URL: http:\\\\abc.sesta.com. http:/abc.com

문자 집합 암호화

HTTP 표준에 따르면 HTTP 헤더 또는 HTML 메타 태그에서 웹 페이지에 사용할 문자 집합을 지정해야 합니다. 하지만 이 정보를 사용할 수 없는 경우도 있습니다. 데이터의 암호화를 설정하고 만든 사람의 의도에 맞게 데이터를 표시하려면 문자 집합을 알아야 합니다.

문자 집합을 검색하려면 SUNWjchdt 패키지를 Java Enterprise System Accessory CD에서 설치하십시오. 이 제품이 설치되면 Rewriter에서 필요한 경우 이를 검색하여 사용합니다.

이 제품을 사용하면 성능이 저하될 수 있기 때문에 필요한 경우에만 설치해야 합니다. 설치, 구성 및 사용에 관한 자세한 내용은 jcharset_readme.txt를 참조하십시오.

Rewriter 사용 시나리오

사용자가 게이트웨이를 통해 인트라넷 웹 페이지에 액세스하려고 할 때 Rewriter가 웹 페이지를 사용할 수 있도록 해줍니다. Rewriter는 URLScraper 및 게이트웨이에서 사용됩니다.

URLScraper

URL Scraper 공급자는 구성된 URI에서 컨텐트를 가져오며, 이러한 URI를 브라우저로 보내기 전에 모든 상대 URI를 절대 URI로 확장합니다.

예를 들어 다음과 같이 사이트에 액세스하는 경우

<a href="../mypage.html">

Rewriter는 이것을 다음으로 변환합니다.

<a href="http://yahoo.com/mypage.html">

여기서 http://yahoo.com/test/는 페이지의 기본 URL입니다.

URLScraper 공급자에 대한 자세한 내용은 Sun Java System Portal Server 관리 설명서를 참조하십시오.

게이트웨이

게이트웨이는 인터넷 포털에서 컨텐트를 가져옵니다. 게이트웨이에서 컨텐트를 브라우저로 보내기 전에 게이트웨이 URI를 기존 URI 앞에 추가하므로 브라우저의 후속 URI 요청이 해당 게이트웨이에 도달할 수 있습니다.

예를 들어, 다음과 같은 인터넷 컴퓨터의 HTML 페이지에 액세스하려고 하는 사용자에 대해

<a href="http://mymachine.intranet.com/mypage.html>"

Rewriter는 이 URL에 다음과 같이 게이트웨이에 대한 참조를 갖는 URL 이름을 접두어로 붙입니다.

<a href="https://gateway.company.com/http://mymachine.intranet.com/ mypage.html>"

사용자가 이 앵커와 관련된 링크를 누르면 브라우저가 게이트웨이에 접속합니다. 게이트웨이는 mymachine.intranet.com에서 mypage.html의 컨텐트를 가져옵니다.

게이트웨이는 가져온 웹 페이지에서 다시 작성할 요소를 결정하기 위해 몇 가지 규칙을 사용합니다.

규칙 집합 작성

규칙 집합 정의에 대한 자세한 내용은 Portal Server 관리 설명서를 참조하십시오. 새 규칙 집합을 만든 후 필수 규칙을 정의해야 합니다.

이 부분에서는 다음 주제를 다룹니다.

• 공용 인터페이스(규칙 집합 DTD)

• 예제 XML DTD

• 규칙 작성을 위한 절차

• 규칙 집합 관련 지침

• 규칙 집합의 루트 요소 정의

• 재귀적 기능 사용

• HTML 컨텐트에 대한 규칙

• JavaScript 컨텐트에 대한 규칙

• XML 컨텐트에 대한 규칙

• CSS(Cascading Style Sheet)에 대한 규칙

• WML에 대한 규칙

공용 인터페이스(규칙 집합 DTD)

규칙 집합 DTD:

<?xml version="1.0" encoding="UTF-8"?>
<!--
The following constraints are not represented in DTD, but taken care of programmatically
    1. In a Rule, All Mandatory attributes cannot be "*".
    2. Only one instance of the below elements is allowed, but in any order.
    1)HTMLRules
    2)JSRules
    3)XMLRules
    3. ID should always be in lower case.
-->
<!ENTITY % eURL ’URL’>
<!ENTITY % eEXPRESSION ’EXPRESSION’>
<!ENTITY % eDHTML ’DHTML’>
<!ENTITY % eDJS ’DJS’>
<!ENTITY % eSYSTEM ’SYSTEM’>

<!ENTITY % ruleSetElements ’(HTMLRules | JSRules | XMLRules)?’>
<!ENTITY % htmlElements ’(Form | Applet | Attribute)*’>
<!ENTITY % jsElements ’(Variable | Function)*’>
<!ENTITY % xmlElements ’(Attribute | TagText)*’>

<!ELEMENT RuleSet (%ruleSetElements;,%ruleSetElements;,%ruleSetElements;)>
<!ATTLIST RuleSet
    id ID #REQUIRED
    extends CDATA "none"
>

<!-- Rules for identifying rules in HTML content -->
<!ELEMENT HTMLRules (%htmlElements;)>
<!ELEMENT Form EMPTY>
<!ATTLIST Form
    name CDATA #REQUIRED
    field CDATA #REQUIRED
    valuePatterns CDATA ""
    source CDATA "*"
>

<!ELEMENT Applet EMPTY>
<!ATTLIST Applet
    code CDATA #REQUIRED
    param CDATA "*"
    valuePatterns CDATA ""
    source CDATA "*"
>

<!-- Rules for identifying rules in JS content -->
<!ELEMENT JSRules (%jsElements;)>
<!ELEMENT Variable EMPTY>
<!ATTLIST Variable
    name CDATA #REQUIRED
    type (%eURL; | %eEXPRESSION; | %eDHTML; | %eDJS; | %eSYSTEM;) "EXPRESSION"
    source CDATA "*"
>

<!ELEMENT Function EMPTY>
<!ATTLIST Function
    name CDATA #REQUIRED
    paramPatterns CDATA #REQUIRED
    type (%eURL; | %eEXPRESSION; | %eDHTML; | %eDJS;) "EXPRESSION"
    source CDATA "*"
>

<!-- Rules for identifying rules in XML content -->
<!ELEMENT XMLRules (%xmlElements;)>
<!ELEMENT TagText EMPTY>
<!ATTLIST TagText
    tag CDATA #REQUIRED
    attributePatterns CDATA ""
    source CDATA "*"
>

<!ELEMENT Attribute EMPTY>
<!ATTLIST Attribute
    name CDATA #REQUIRED
    tag CDATA "*"
    valuePatterns CDATA ""
    type (%eURL; | %eDHTML; | %eDJS; ) "URL"
    source CDATA "*"
>

*를 규칙 값의 일부로 사용할 수 있지만 필수 속성 값에는 *만 사용할 수 없습니다. 이러한 규칙은 무시되지만 RuleSetInfo 로그 파일에 메시지가 기록됩니다. 이 로그 파일에 대한 자세한 내용은 디버깅 파일 이름을 참조하십시오.

예제 XML DTD

이 절에는 예제 규칙 집합이 들어 있습니다. 140페이지의 "사례 연구"를 통해 Rewriter에서 이러한 규칙을 해석하는 방식을 살펴볼 수 있습니다.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
Rules for integrating a mail client with the gateway.
-->
<!DOCTYPE RuleSet SYSTEM "jar://rewriter.jar/resources/RuleSet.dtd">
<RuleSet type="GROUPED" id="owa">
<HTMLRules>
<Attribute name="action" />
<Attribute name="background" />
<Attribute name="codebase" />
<Attribute name="href" />
<Attribute name="src" />
<Attribute name="lowsrc" />
<Attribute name="imagePath" />
<Attribute name="viewClass" />
<Attribute name="emptyURL" />
<Attribute name="draftsURL" />
<Attribute name="folderURL" />
<Attribute name="prevMonthImage" />
<Attribute name="nextMonthImage" />
<Attribute name="style" />
<Attribute name="content" tag="meta" />
</HTMLRules>
<JSRules>
<!-- Rules for Rewriting JavaScript variables in URLs -->
<Variable name="URL"> _fr.location </Variable>
<Variable name="URL"> g_szUserBase </Variable>
<Variable name="URL"> g_szPublicFolderUrl </Variable>
<Variable name="URL"> g_szExWebDir </Variable>
<Variable name="URL"> g_szViewClassURL </Variable>
<Variable name="URL"> g_szVirtualRoot </Variable>
<Variable name="URL"> g_szBaseURL </Variable>
<Variable name="URL"> g_szURL </Variable>
<Function name="EXPRESSION" name="NavigateTo" paramPatterns="y"/>
</JSRules>
<XMLRules>
<Attribute name="xmlns"/>
<Attribute name="href" tag="a"/>
<TagText tag="baseroot" />
<TagText tag="prop2" />
<TagText tag="prop1" />
<TagText tag="img" />
<TagText tag="xsl:attribute"
attributePatterns="name=src" />
</XMLRules>
</RuleSet>

규칙 작성을 위한 절차

규칙을 작성하는 일반적인 절차는 다음과 같습니다.

• 컨텐트를 다시 작성해야 하는 HTML 페이지가 있는 디렉토리를 확인합니다.

• 이 디렉토리에서 다시 작성해야 하는 페이지를 확인합니다.

• 각 페이지에서 다시 작성해야 하는 URL을 확인합니다. "http" 및 "/"를 검색하여 대부분의 URL이 간단하게 확인할 수 있습니다.

• URL의 컨텐트 유형 확인: HTML, JavaScript 또는 XML.

• Access Manager 관리 콘솔의 [Portal Server 구성] 아래에 있는 [Rewriter 서비스]에서 필요한 규칙 집합을 편집하여 이러한 각 URL을 다시 쓰기 위해 필요한 규칙을 작성합니다.

• 모든 규칙을 해당 도메인에 대한 하나의 규칙 집합으로 결합시킵니다.

규칙 집합 관련 지침

규칙 집합을 작성하는 경우 다음 사항을 주의하십시오.

• 특정 호스트의 우선 순위는 가장 긴 URI 대응부터 결정됩니다. 예를 들어, 다음 규칙 집합에서

  mail1.central.abc.com|iplanet_mail_ruleset
  *.sfbay.abc.com|sfbay_ruleset
  *.abc.com|generic_ruleset

  sfbay_ruleset이 가장 긴 대응이기 때문에 사용됩니다.

• 규칙 집합의 규칙들은 규칙이 특정 구문과 일치할 때까지 페이지의 각 구문에 차례로 적용됩니다.

  규칙을 작성할 때 규칙의 순서에 주의하십시오. 규칙은 규칙 집합에 있는 순서대로 페이지의 구문에 적용됩니다. 특정한 규칙과 "*"를 포함한 일반적 규칙이 있는 경우, 특정한 규칙을 먼저 정의한 다음 일반적 규칙을 적용하십시오. 그렇게 하지 않으면 특정한 규칙을 발견하기 전에 모든 구문에 일반 규칙이 적용됩니다.

• 모든 규칙은 <RuleSet> </RuleSet> 태그 내에 넣어야 합니다.

• HTML 컨텐트를 다시 써야 하는 모든 규칙은 규칙 집합의 <HTMLRules> </HTMLRules> 부분에 포함시키십시오.

• JavaScript 컨텐트를 다시 써야 하는 모든 규칙은 규칙 집합의 <JSRules> </JSRules> 부분에 포함시키십시오.

• XML 컨텐트를 다시 써야 하는 모든 규칙은 규칙 집합의 <XMLRules> </XMLRules> 부분에 포함시키십시오.

• 인트라넷 페이지에서, 다시 써야 하는 URL을 확인하고 규칙 집합의 해당 부분(HTML, JSRules 또는 XMLRules)에 필요한 규칙을 포함시키십시오.

• 규칙 집합을 필요한 도메인에 할당합니다.

• 게이트웨이를 다시 시작하여 변경 사항을 적용합니다.

  gateway-install-root/SUNWportal/bin/gateway -n gateway-profile-name start

규칙 집합의 루트 요소 정의

규칙 집합의 루트 요소에는 두 가지 속성이 있습니다.

• RuleSetName. 예를 들어 default_ruleset입니다. 이 이름은 규칙 집합에서 URI 매핑에 참조합니다.

• Extends. 이 속성은 규칙 집합의 상속 기능을 참조합니다. 값은 규칙 집합을 유도할 기준 집합을 가리킵니다.

  값 none을 사용하면 이 새로운 독립 규칙 집합이 다른 규칙 집합에 의존하지 않는 다는 것을 나타내며 RuleSetName을 지정하면 규칙 집합이 다른 규칙 집합에 의존한다는 것을 나타냅니다.

재귀적 기능 사용

Rewriter에서는 재귀적 기능을 사용하여 대응되는 문자열 패턴의 끝까지에서 같은 패턴을 검색합니다.

예를 들어 Rewriter에서 다음 문자열을 구문 분석하는 경우

<a href="src=abc.jpg,src=bcd.jpg,src=xyz.jpg>

규칙

<Attribute name="href" valuePatterns="*src=**"/>

은 처음 나타나는 패턴만을 다시 작성하며 그 결과는 다음과 같습니다.

<a href="src=http://jane.sun.com/abc.jpg>

재귀적 옵션을 사용하는 경우

<Attribute name="href" valuePatterns="REC:*src=**"/>;

Rewriter는 대응되는 문자열 패턴에서 끝까지 같은 패턴을 찾기 때문에 다음과 같은 출력을 얻게 됩니다.

<a href="src=http://jane.sun.com/abc.jpg,src=http://jane.sun.com/bcd.jpg,src=http://jane.sun.com/xyz.jpg>

언어 기반 규칙 정의

규칙은 다음 언어를 바탕으로 합니다.

• HTML

• JavaScript

• XML

HTML 컨텐트에 대한 규칙

웹 페이지의 HTML 컨텐트는 속성, 폼 및 애플릿으로 더욱 세분할 수 있습니다. 이에 따라 HTML 컨텐트에 대한 규칙은 다음과 같이 분류됩니다.

• HTML 컨텐트에 대한 속성 규칙

• HTML 컨텐트에 대한 폼 규칙

• HTML 컨텐트에 대한 애플릿 규칙

HTML 컨텐트에 대한 속성 규칙

이 규칙은 값을 다시 써야 하는 대상 태그의 속성을 확인합니다. 속성 값은 단순한 URL, JavaScript 또는 DHTML 컨텐트일 수 있습니다. 예:

• "img" 태그의 src 속성은 이미지 위치를 가리킵니다(단순 URL).

• href 속성의 onClick 속성은 링크를 누를 때 처리됩니다(DJS).

이 절에서는 다음을 설명합니다.

• 속성 규칙 구문

• 속성 규칙 예제

• DJS 속성 예제

속성 규칙 구문

<Attribute name="attributeName" [tag="*" valuePatterns="" source=”*” type=”URL|DHTML|DJS”]/>

여기서,

attributeName은 속성의 이름입니다(필수).

tag는 속성이 속하는 태그입니다(옵션, 기본값 *, 모든 태그를 의미).

valuePatterns에 대해서는 규칙에 패턴 매칭 사용을 참조하십시오.

source는 이 속성이 정의되는 페이지의 URI를 지정합니다(옵션, 기본값 * , 모든 페이지를 의미).

type은 값의 유형을 지정합니다(옵션). 다음이 가능합니다.

URL - 단순 URL(기본값)

DHMTL - DHTML 컨텐트. 이런 종류의 컨텐트는 표준 HTML 컨텐트에서 나타나며 Microsoft의 HTC 형식 파일에서 사용됩니다.

DJS - JavaScript 컨텐트. onClick 및 onMouseover와 같은 모든 HTML 이벤트 처리기는 HTML 속성과 연계된 JavaScript를 가지고 있습니다.

속성 규칙 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://mymachine.intranet.com/mypage.html

페이지 컨텐트

<a href="http://mymachine.intranet.com/mypage.html">

규칙

<Attribute name="href"/>
or
<Attribute name="href" tag="a"/>

결과

<a href=gateway-URL/http://mymachine.intranet.com/myhome.html>

설명

다시 작성될 URL은 이미 절대 URL이므로 URL의 접두어로는 게이트웨이 URL만 사용됩니다.

DJS 속성 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://abc.sesta.com/focus.html

페이지 컨텐트

<Form>

<input TYPE=TEXT SIZE=20 value=focus onClick="Check(\q/focus.html\q,\qfocus\q);return;">

</Form>

규칙

<Attribute name=”onClick” type=”DJS”/>
<Function type="URL" name="Check" paramPatterns="y,"/>

결과

<Form>

<INPUT TYPE=TEXT SIZE=20 value=focus onClick="Check(\q
gateway-URL
/http://abc.sesta.com/focus.html\q,\qfocus\q);return;">

</Form>

설명

지정된 페이지 컨텐트를 다시 쓰기 위해 두 가지 규칙이 필요합니다. 첫 번째 규칙은 onClick JavaScript 토큰을 확인합니다. 두 번째 규칙은 다시 작성되어야 하는 check 함수의 매개 변수를 확인합니다. 이 경우에는 paramPatterns가 첫 번째 매개 변수 자리에 y 값을 갖기 때문에 첫 번째 매개 변수만 다시 작성됩니다.

게이트웨이 URL과 JavaScript 토큰이 나타나는 페이지의 기본 URL이 필요한 매개 변수 앞에 덧붙여집니다.

HTML 컨텐트에 대한 폼 규칙

사용자가 찾아보는 HTML 페이지에는 폼이 있을 수 있습니다. 일부 폼 요소는 URL을 값으로 취할 수 있습니다.

이 절은 다음으로 세분됩니다.

• 폼 규칙 구문

• 폼 규칙 예제

폼 규칙 구문

<Form name="form1" field="visit" [valuePatterns="" source="*"]/>

여기서

name은 폼의 이름입니다(필수).

field는 값을 다시 작성해야 하는 폼의 필드입니다(필수).

valuePatterns에 대해서는 규칙에 패턴 매칭 사용을 참조하십시오.

source는 이 폼 정의가 있는 html 페이지의 URL입니다(옵션, 기본값 *, 모든 페이지를 의미).

폼 규칙 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://test.siroe.com/testcases/html/form.html

페이지 컨텐트

페이지 URI가 form.html이고 서버의 루트 디렉토리에 있다고 가정합니다.

<form name=form1  method=POST action=
"http://test.siroe.com/testcases/html/form.html">
<input type=hidden name=abc1 value="0|1234|/test.html">
</form>

form1의 일부인 abc1이라는 이름의 숨겨진 필드 값에 존재하는/text.html을 다시 쓰기 위해 다음 규칙이 필요합니다.

규칙

<Form source="*/form.html" name="form1" 
field="abc1" valuePatterns="0|1234|"/>
<Attribute name="action"/>

결과

<FORM name=”form1” 
method=”POST” action="gateway-URL/
http://test.siroe.com/testcases/html/form.html">
<input type=hidden name=abc1 
value="0|1234|gateway-URL/
http://test.siroe.com/test.html">
</FORM>

설명

action 태그는 정의된 특정 HTML 속성 규칙을 사용하여 다시 작성됩니다.

입력 태그 속성 값의 value는 결과에 나와 있는 것처럼 다시 작성됩니다. 지정된 valuePatterns를 찾고 일치하는 valuePatterns 이후의 모든 컨텐트는 페이지의 기본 URL과 게이트웨이 URL을 앞에 덧붙여 다시 작성됩니다. 규칙에 패턴 매칭 사용을 참조하십시오.

HTML 컨텐트에 대한 애플릿 규칙

단일 웹 페이지에 많은 애플릿이 있을 수 있고 각 애플릿에는 많은 매개 변수가 있을 수 있습니다. Rewriter는 규칙에 지정된 값을 애플릿의 HTML 정의에 대응시키고 애플릿 매개 변수 정의의 일부로 존재하는 URL 값을 수정합니다. 이러한 교체는 사용자가 특정 웹 페이지를 찾아볼 때가 아니라 서버에서 이루어집니다. 이 규칙은 HTML 컨텐트의 개체 태그 및 애플릿 모두에서 매개 변수를 찾아 다시 작성합니다.

이 절은 다음으로 세분됩니다.

• 애플릿 규칙 구문

• 애플릿 규칙 예제

애플릿 규칙 구문

<Applet code="ApplicationClassName/ObjectID
" param="parametername" [valuePatterns="" source="*"] />

여기서

code는 애플릿 또는 개체 클래스의 이름입니다(필수).

param은 값을 다시 작성해야 하는 매개 변수의 이름입니다(필수).

valuePatterns에 대해서는 규칙에 패턴 매칭 사용을 참조하십시오.

source는 애플릿 정의가 있는 페이지의 URL입니다(옵션, 기본값 *, 모든 페이지를 의미).

애플릿 규칙 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://abc.siroe.com/casestudy/test/HTML/applet/rule1.html

페이지 컨텐트

<applet codebase=”appletcode” code=”
RewriteURLinApplet.class” archive=”/test.jar”>
<param name=Test1 value="/index.html">
</applet>

규칙

<Applet source="*/rule1.html" code=
"RewriteURLin*.class" param="Test*"/>

결과

<APPLET codebase=”gateway-URL
/http://abc.siroe.com/casestudy/test/HTML/
applet/appletcode” code=”RewriteURLinApplet.class”
 archive=”/test.jar”><param name=”Test1” value="
gateway-URL/http:
//abc.siroe.com/index.html">
</APPLET>

설명

<Attribute name="codebase"/>가 default_gateway_ruleset에서 정의된 규칙이므로 codebase 속성은 다시 작성됩니다.

이름이 Test로 시작되는 모든 매개 변수는 다시 작성됩니다. 애플릿 코드가 표시되는 페이지의 기본 URL과 게이트웨이 URL이 값 param 태그의 value 속성에 접두어로 사용됩니다.

규칙에 패턴 매칭 사용

valuePatterns 필드를 사용하여 패턴 매칭을 수행하고 다시 써야 하는 구문의 특정 부분을 확인할 수 있습니다.

규칙의 일부로 valuePatterns를 지정했다면 매칭된 패턴 이후의 모든 컨텐트는 다시 작성됩니다.

아래 예제 폼 규칙을 생각해 보겠습니다.

<Form source="*/source.html
" name="form1" field="visit
" [valuePatterns="0|1234|"]/>

여기서

source는 폼이 표시되는 html 페이지의 URL입니다.

name은 폼의 이름입니다.

field는 값을 다시 써야 하는 폼의 필드입니다.

valuePatterns는 다시 써야 하는 문자열 부분을 나타냅니다. valuePatterns 뒤에 나타나는 모든 컨텐트는 다시 작성됩니다(옵션, 기본값 ""는 전체 값을 다시 써야 함을 나타냄).

valuePatterns에 특수 문자 지정

특수 문자는 백슬래시로 이스케이프하면 지정할 수 있습니다. 예:

<Form source="*/source.html " name="form1" field=" visit" [valuePatterns="0|1234| \\;original text|changed text”]/>

valuePatterns에서 와일드카드 사용

와일드카드 별표(*) 문자를 사용하여 다시 쓰기 위한 패턴 매칭을 수행할 수 있습니다.

valuePatterns 필드에 단순히 *만 지정할 수는 없습니다. *는 모든 텍스트와 일치함을 나타내기 때문에 valuePattern 뒤에 텍스트가 없습니다. 따라서 Rewriter가 다시 작성할 텍스트가 없습니다. *를 *abc와 같이 다른 문자열과 연결하여 사용해야 합니다. 이 경우에 *abc 이후의 모든 컨텐트가 다시 작성됩니다.

별표(*)는 규칙의 어떤 필드에서나 와일드카드로 사용할 수 있습니다. 그러나 규칙의 모든 필드에 *를 포함시킬 수는 없습니다. 모든 필드에 *가 있으면 규칙이 무시됩니다. 오류 메시지는 표시되지 않습니다.

원본 명령문에서 여러 필드를 구별하기 위해 표시되는 구분 문자(세미콜론 또는 쉼표)와 함께 * 또는 **를 사용할 수 있습니다. 하나의 별표(*)는 다시 작성되지 않을 모든 필드와 매칭되며 두 개의 별표(**)는 다시 작성해야 하는 모든 필드와 매칭됩니다.

valuePatterns에서 와일드카드 사용에는 * 와일드카드 사용에 대한 몇 가지 예제가 나와 있습니다.

JavaScript 컨텐트에 대한 규칙

JavaScript에는 다양한 위치에 URL이 있을 수 있습니다. Rewriter는 JavaScript를 직접 구문 분석하여 URL 부분을 확인할 수 없습니다. 특별한 규칙 집합을 작성하여 JavaScript 처리기가 URL을 확인하여 변환하도록 합니다.

URL 유형을 가진 JavaScript 요소는 다음으로 분류됩니다.

• 변수

• 함수의 인수

변수

변수의 일반 구문은 다음과 같습니다.

<Variable name="variableName" [type="URL|EXPRESSION|DHTML|DJS|SYSTEM" source="*"]>

JavaScript 변수는 가지고 있는 값의 유형에 따라 5가지 범주로 더욱 세분할 수 있습니다.

• URL 변수

• EXPRESSION 변수

• DHTML(Dynamic HTML) 변수

• DJS(Dynamic JavaScript) 변수

• SYSTEM 변수

URL 변수

변수 값은 URL로 취급할 수 있는 단순한 문자열입니다.

이 절은 다음으로 세분됩니다.

• URL 변수 구문

• URL 변수 예제

URL 변수 구문

<Variable name="variableName" type="URL" [source="*"]>

여기서

variableName은 변수의 이름입니다. variableName의 값은 다시 작성됩니다(필수).

type은 URL 변수입니다(필수, 이 값은 URL이어야 함).

source는 이 JavaScript 변수가 발견되는 페이지의 URI입니다(옵션, 기본값 *는 모든 페이지를 의미).

URL 변수 예제

기본 URL이 다음과 같다고 가정합니다.

http://abc.siroe.com/tmp/page.html

페이지 컨텐트

<script LANGUAGE="Javascript">
<!--
//URL Variables
var imgsrc1="/tmp/tmp.jpg";
var imgsrc2="http://srap.sesta.com/tmp/tmp.jpg";
var imgsrc3=imgsrc2;
//-->
</SCRIPT>

규칙

<Variable name=”imgsrc*” type="URL"/>

결과

<script LANGUAGE="Javascript">
<!--
//URL Variables
var imgsrc="gateway-URL/http://abc.siroe.com/tmp/tmp.jpg";
var imgsrc="gateway-URL/http://srap.sesta.com/tmp/tmp.jpg";
var imgsrc3=imgsrc2;
//-->
</SCRIPT>

설명

유형이 URL이고 이름이 imgsrc로 시작되는 모든 변수가 다시 작성됩니다. 결과의 첫 라인에서 게이트웨이 URL과 변수가 표시되는 페이지의 기본 URL이 앞에 덧붙습니다. 두 번째 라인에는 이미 절대 경로가 있기 때문에 게이트웨이 URL만 덧붙습니다. 세 번째 var imagsrc2는 그 값이 문자열이 아니라 다른 JavaScript 값이기 때문에 다시 작성되지 않습니다.

EXPRESSION 변수

Expression 변수에는 오른쪽에 표현식이 있습니다. 이 표현식의 결과는 URL입니다. Rewriter는 서버에서 이러한 표현식을 평가할 수 없기 때문에 HTML 페이지에 JavaScript 함수(psSRAPRewriter_convert_expression)를 추가합니다. 이 함수는 표현식을 하나의 매개 변수로 받아들여 클라이언트 브라우저에서 필요한 URL로 평가합니다.

명령문에 단순 URL이 있는지 EXPRESSION URL이 있는지 잘 모르는 경우에는 두 시나리오를 모두 처리할 수 있는 EXPRESSION 규칙을 사용하십시오.

이 절은 다음으로 세분됩니다.

• EXPRESSION 변수 구문

• EXPRESSION 변수 예제

EXPRESSION 변수 구문

<Variable name="variableName" [type="EXPRESSION" source="*"]/>

여기서

variableName은 그 값이 표현식인 JavaScript 변수의 이름입니다(필수).

type은 JavaScript 변수의 유형입니다(옵션, 기본값은 EXPRESSION).

source는 페이지의 URI입니다(옵션, 기본값 *, 모든 소스를 의미)

EXPRESSION 변수 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://abc.siroe.com/dir1/dir2/page.html

페이지 컨텐트

<script LANGUAGE="Javascript">
<!--
//Expression variables
var expvar= getURIPreFix() + "../../images/graphics"+".gif";
document.write("<A HREF="+expvar+">Link to XYZ content</A><P>")
var expvar="../../images/graphics"+".gif";
//-->
</SCRIPT>

규칙

<Variable name=”expvar” type="EXPRESSION"/>
or
<Variable name=”expvar”/>

결과

var expvar=psSRAPRewriter_convert_expression(getURIPreFix()
 + "../../images/graphics"+".gif");document.write("<a href="+expvar+">>
Link to XYZ content</A><P>")var expvar=”gateway-URL/http://abc.siroe.com/images/graphics"+".gif";

설명

첫 번째 줄에서 함수 psSRAPRewriter_convert_expression이 expvar 표현식 변수의 오른쪽에 덧붙여집니다. 이 함수는 표현식을 처리하고 런타임에 컨텐트를 다시 작성합니다. 세 번째 라인에서 값이 단순 URL로 다시 작성됩니다.

DHTML(Dynamic HTML) 변수

이것은 HTML 컨텐트를 포함한 JavaScript 변수입니다.

이 절은 다음으로 세분됩니다.

• DHTML 구문

• DHTML 예제

DHTML 구문

<Variable name="variableName" type="DHTML" [source="*"]/>

여기서

variableName은 DHTML 컨텐트가 있는 JavaScript 변수의 이름입니다(필수).

type은 변수의 유형입니다(필수, 이 값은 DHTML이어야 함).

source는 페이지의 URL입니다(옵션, 기본값은 *, 모든 페이지를 의미).

DHTML 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://abc.sesta.com/graphics/set1/
graphics/jsscript/JSVAR/page.html

페이지 컨텐트

<script LANGUAGE="Javascript">
<!--
//DHTML Var
var dhtmlVar="<a href=../../images/test.html>"
var dhtmlVar="<a href=/images/test.html>"
var dhtmlVar="<a href=images/test.html>"
//-->
</SCRIPT>

규칙

<Variable name=”dhtmlVar” type="DHTML"/>
<Attribute name="href"/>
or
<Attribute name="href" tag="a"/>

결과

<script LANGUAGE="Javascript">
<!--
//DHTML Var
var dhtmlVar="<a href=gateway-URL
/http://abc.sesta.com/graphics/
set1/graphics/images/test.html>"
var dhtmlVar="<a href=gateway-URL/
http
://abc.sesta.com/images/test.html>"
var dhtmlVar="<a href=gateway-URL/
http://abc.sesta.com/graphics/set1/
graphics/jscript/JSVAR/images/test.html>"
//--></SCRIPT>

설명

JavaScript 구문 분석기는 dhtmlVar의 값을 HTML 컨텐트로 읽고 이 컨텐트를 HTML 구문 분석기로 보냅니다. HTML 구문 분석기가 href 속성 규칙이 대응된 HTML 규칙을 적용하기 때문에 URL이 다시 작성됩니다.

DJS(Dynamic JavaScript) 변수

이것은 JavaScript 컨텐트를 포함한 JavaScript 변수입니다.

이 절은 다음으로 세분됩니다.

• DJS 구문

• DJS 예제

DJS 구문

<Variable name="variableName" type="DJS" [source="*"]/>

여기서

variable은 그 값이 javascript인 JavaScript 변수입니다.

DJS 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://abc.sesta.com/dir1/dir2/dir3/jscript/dir4/page.html

페이지 컨텐트

//DJS Var
var dJSVar="var dJSimgsrc=\q/tmp/tmp.jpg\q;"
var dJSVar="var dJSimgsrc=\q../tmp/tmp.jpg\q;"
var dJSVar="var dJSimgsrc=
\qhttp://abc.sesta.com/tmp/tmp.jpg\q;"

규칙

<Variable name="DJS">dJSVar/>
<Variable name="URL">dJSimgsrc/>

결과

//DJS Var - need 2 rules
var dJSVar="var dJSimgsrc=\qgateway-URL
/http://abc.sesta.com/tmp/tmp.jpg\q;"var dJSVar="var dJSimgsrc=\q
gateway-URL/http
://abc.sesta.com/dir1/dir2/dir3/jscript/tmp/tmp.jpg\q;"
var dJSVar="var dJSimgsrc=\qgateway-URL/
http://abc.sesta.com/tmp/tmp.jpg\q;"

설명

여기에 두 가지 규칙이 필요합니다. 첫 번째 규칙은 동적 JavaScript 변수 dJSVar을 찾습니다. 이 변수의 값은 다시 URL 유형의 JavaScript입니다. 이 JavaScript 변수의 값을 다시 쓰기 위해 두 번째 규칙이 적용됩니다.

SYSTEM 변수

사용자가 사용하지 못하도록 선언되어 있어 지원이 제한되는 변수입니다. 이 변수들은 JavaScript 표준의 일부로 사용할 수 있습니다. 예: window.location.pathname

이 절은 다음으로 세분됩니다.

• SYSTEM 변수 구문

• SYSTEM 변수 예제

SYSTEM 변수 구문

<Variable name="variableName" type="SYSTEM" [source="*"]/>

여기서

variableName은 JavaScript 시스템 변수입니다. 필수이며 값은document.URL, document.domain, location, doument.location, location.pathname, location.href, location.protocol, location.hostname, location.host 및 location.port 등의 패턴과 일치하는 변수일 수 있습니다. 이러한 값은 generic_ruleset에 있습니다. 이러한 시스템 변수 규칙을 수정하지 마십시오.

type은 시스템 유형 값을 지정합니다(필수이며 값은 DJS임).

source는 이 페이지의 URI입니다(옵션, 기본값 *는 모든 페이지를 의미).

SYSTEM 변수 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://abc.siroe.com/dir1/page.html

페이지 컨텐트

<script LANGUAGE="Javascript">
<!--
//SYSTEM Var
alert(window.location.pathname);
//-->
</SCRIPT>

규칙

<Variable name=”window.location.pathname” type="SYSTEM"/>

결과

</SCRIPT>
<SCRIPT LANGUAGE="Javascript">
<!--
//SYSTEM Var
alert(psSRAPRewriter_convert_pathname(window.location.pathname));
//-->
</SCRIPT>

설명

Rewriter가 규칙에 대응되는 시스템 변수를 찾으면 psSRAPRewriter_convert_system 함수가 접두어로 사용됩니다. 이 함수는 런타임 때 시스템 변수를 처리하고 그에 따라 얻어지는 URL을 다시 씁니다.

함수의 인수

그 값을 다시 작성해야 하는 함수 매개 변수는 4가지 범주로 분류됩니다.

• URL 매개 변수

• EXPRESSION 매개 변수

• DHTML 매개 변수

• DJS 매개 변수

일반 구문

<Function name="functionName " paramPatterns="y,y," [type="URL|EXPRESSION|DHTML|DJS" source=”*”]/>

여기서

name은 JavaScript 함수의 이름입니다(필수).

paramPatterns는 다시 작성해야 하는 매개 변수를 지정합니다(필수).

y. y의 위치는 다시 작성해야 하는 매개 변수를 나타냅니다. 예를 들어 구문에서 첫 번째 매개 변수는 다시 써야 하지만 두 번째 매개 변수는 다시 쓰지 않아야 합니다.

type은 이 매개 변수에 필요한 값의 종류를 지정합니다(옵션, 기본값은 EXPRESSION 유형).

source는 페이지의 소스 URI입니다(옵션, 기본값은 *, 모든 페이지를 의미).

URL 매개 변수

함수는 이 매개 변수를 문자열로 취하며 이 문자열은 URL로 취급할 수 있습니다.

이 절은 다음으로 세분됩니다.

• URL 매개 변수 구문

• URL 매개 변수 예제

URL 매개 변수 구문

<Function name="functionName" paramPatterns="y,," type="URL" [source=”*”]/>

여기서

name은 URL 유형의 매개 변수를 갖는 함수 이름입니다(필수).

paramPatterns는 다시 작성해야 하는 매개 변수를 지정합니다(필수).

y. y의 위치는 다시 작성해야 하는 매개 변수를 나타냅니다. 예를 들어 구문에서 첫 번째 매개 변수는 다시 써야 하지만 두 번째 매개 변수는 다시 쓰지 않아야 합니다.

type은 함수의 유형입니다(필수, 이 값은 URL이어야 함).

source는 이 함수 호출을 갖는 페이지의 URL입니다(옵션, 기본값은 *, 모든 URL을 의미).

URL 매개 변수 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://abc.sesta.com/test/rewriter/test1/jscript/test2/page.html

페이지 컨텐트

<script language="JavaScript">
<!--
function test(one,two,three){
alert(one + "##" + two + "##" +three);
}
test("/test.html","../test.html","123");
window.open("/index.html","gen",width=500,height=500);
//-->
</SCRIPT>

규칙

<Function name="URL" name="test" paramPatterns="y,y,"/>
<Function name="URL" name="window.open" paramPatterns="y,,,"/>

결과

<SCRIPT language="JavaScript">
<!--
function test(one,two,three) {
alert(one + "##" + two + "##" +three);
}
test("gateway-URL/http://abc.sesta.com/test.html","
gateway-URL/http://abc.sesta.com/test/rewriter/
test1/jscript/test.html","123");window.open("gateway-URL/
http://abc.sesta.com/index.html","gen",width=500,height=500);
//-->
</SCRIPT>

설명

첫 번째 규칙은 test 이름의 함수에 있는 처음 두 매개 변수를 다시 작성해야 한다고 지정합니다. 따라서 test 함수의 처음 두 매개 변수는 다시 작성됩니다. 두 번째 규칙은window.open 함수의 처음 매개 변수를 다시 작성해야 한다고 지정합니다. window.open 함수 내의 URL에는 이 함수 매개 변수를 포함한 페이지의 기본 URL과 게이트웨이 URL이 앞에 덧붙여집니다.

EXPRESSION 매개 변수

이 매개 변수는 표현식 값을 취하며 평가 결과는 URL이 됩니다.

이 절은 다음으로 세분됩니다.

• EXPRESSION 매개 변수 구문

• EXPRESSION 매개 변수 예제

EXPRESSION 매개 변수 구문

<Function name="functionName" paramPatterns="y" [type="EXPRESSION" source=”*”]/>

여기서

name은 함수의 이름입니다(필수).

paramPatterns는 다시 작성해야 하는 매개 변수를 지정합니다(필수).

y. y의 위치는 다시 작성해야 하는 매개 변수를 나타냅니다. 위의 구문에서 첫 번째 매개 변수만 다시 작성됩니다.

type은 값 EXPRESSION을 지정합니다(옵션).

source는 이 함수가 호출되는 페이지의 URI입니다.

EXPRESSION 매개 변수 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://abc.sesta.com/dir1/dir2/page.html

페이지 컨텐트

<script language="JavaScript">
<!--
function jstest2(){
return ".html";
}
function jstest1(one){
return one;
}
var dir="/images/test"
var test1=jstest1(dir+"/test"+jstest2());
document.write("<a HREF="+test1+">TEST</a>");
alert(test1);
//-->
</SCRIPT>

규칙

<Function type="EXPRESSION" name="jstest1" paramPatterns="y"/>
or
<Function name="jstest1" paramPatterns="y"/>

결과

<script language="JavaScript">
<!--
function jstest2(){
return ".html";
}
function jstest1(one){
return one;
}
var dir="/images/test"
var test1=jstest1(psSRAPRewriter_convert_expression(dir+"/test"+jstest2()));
document.write("<a HREF="+test1+">TEST</a>");
alert(test1);
//-->
</SCRIPT>

설명

이 규칙은 jstest1 함수의 첫 번째 매개 변수를 EXPRESSION 함수 매개 변수로 취급하여 다시 써야 한다는 것을 지정합니다. 예제 페이지 컨텐트에서 첫 번째 매개 변수는 런타임 때만 평가되는 표현식입니다. Rewriter는 이 표현식에 psSRAPRewriter_convert_expression 함수로 접두어를 붙입니다. 이 표현식이 평가되고 psSRAPRewriter_convert_expression 함수가 런타임 시 결과를 다시 씁니다.

위의 예제에서 JavaScript 변수 규칙의 일부로 test1 변수가 있을 필요는 없습니다. jstest1에 대한 함수 규칙이 다시 쓰기를 처리합니다.

DHTML 매개 변수

그 값이 HTML인 함수 매개 변수입니다.

HTML 페이지를 동적으로 생성하는 document.write() 같은 원시 JavaScript 메소드가 이 범주에 속합니다.

이 절은 다음으로 세분됩니다.

• DHTML 매개 변수 구문

• DHTML 매개 변수 예제

DHTML 매개 변수 구문

<Function name="functionName" paramPatterns="y" type="DHTML" [source=”*”]/>

여기서

name은 함수의 이름입니다.

paramPatterns는 다시 작성해야 하는 매개 변수를 지정합니다(필수).

y. y의 위치는 다시 작성해야 하는 매개 변수를 나타냅니다. 위의 구문에서 첫 번째 매개 변수만 다시 작성됩니다.

DHTML 매개 변수 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://xyz.siroe.com/test/rewriter/test1/jscript/JSFUNC/page.html

페이지 컨텐트

<script>
<!--
document.write(\q<a href="/index.html">write</a><BR>\q)
document.writeln(\q<a href="index.html">writeln</a><BR>\q)
document.write("http://abc.sesta.com/index.html<BR>")
document.writeln("http://abc.sesta.com/index.html<BR>")
//-->
</SCRIPT>

규칙

<Function name="DHTML" name="document.write" paramPatterns="y"/>
<Function name="DHTML" name="document.writeln" paramPatterns="y"/>
<Attribute name="href"/>

결과

<SCRIPT>
<!--
document.write(\q<a href="gateway-URL/
http://xyz.siroe.com/index.html">write</a><BR>\q)
document.writeln(\q<a href="gateway-URL/
http://xyz.siroe.com/test/rewriter/test1/
jscript/JSFUNC/index.html">writeln</a><BR>\q)
document.write("http://abc.sesta.com/index.html<BR>")
document.writeln("http://abc.sesta.com/index.html<BR>")
//-->
</SCRIPT>

설명

첫 번째 규칙은 document.write 함수의 첫 번째 매개 변수를 다시 작성해야 한다고 지정합니다. 두 번째 규칙은 document.writeln 함수의 첫 번째 매개 변수를 다시 작성해야 한다고 지정합니다. 세 번째 규칙은 href 이름의 모든 속성을 다시 작성해야 한다고 지정하는 단순 HTML 규칙입니다. 이 예에서, DHTML 매개 변수 규칙이 함수에서 다시 작성해야 하는 매개 변수를 확인합니다. 그런 다음 HTML 속성 규칙이 적용되어 실제로 확인된 매개 변수가 다시 작성됩니다.

DJS 매개 변수

그 값이 JavaScript인 함수 매개 변수입니다.

이 절은 다음으로 세분됩니다.

• DJS 매개 변수 구문

• DJS 매개 변수 예제

DJS 매개 변수 구문

<Function name="functionName" paramPatterns="y" type="DJS" [source=”*”]/>

여기서

name은 하나의 매개 변수가 DJS인 함수의 이름입니다(필수).

paramPatterns는 위 함수에서 어떤 매개 변수가 DJS인지를 지정합니다(필수).

y. y의 위치는 다시 작성해야 하는 매개 변수를 나타냅니다. 위의 구문에서 첫 번째 매개 변수만 다시 작성됩니다.

type은 DJS입니다(필수).

source는 페이지의 URI입니다(옵션, 기본값은 *, 모든 URI를 의미).

DJS 매개 변수 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://abc.sesta.com/page.html

페이지 컨텐트

<script>
menu.addItem(new NavBarMenuItem("All Available Information","JavaScript:top.location=\qhttp://abc.sesta.com\q"));
</script>

규칙

<Function name="DJS" name="NavBarMenuItem" paramPatterns=",y"/>
<Variable name="URL">top.location</Variable>

결과

<script>
menu.addItem(new NavBarMenuItem("All Available Information",
"JavaScript:top.location=\qgateway-URL/
http://abc.sesta.com\q"));
</script>

설명

첫 번째 규칙은 JavaScript를 포함한 NavBarMenuItem 함수의 두 번째 매개 변수를 다시 작성해야 한다고 지정합니다. JavaScript 내에서 top.location 변수도 다시 작성해야 합니다. 이 변수는 두 번째 규칙을 사용하여 다시 작성됩니다.

XML 컨텐트에 대한 규칙

웹 페이지에 XML 컨텐트가 있을 수 있으며 여기에는 다시 URL이 있을 수 있습니다. 다시 작성해야 하는 XML 컨텐트는 두 범주로 구분됩니다.

• 태그 텍스트(태그의 PCDATA 또는 CDATA와 같음)

• 속성

태그 텍스트

이 규칙은 태그 요소의 PCDATA 또는 CDATA를 다시 작성하기 위한 것입니다.

이 절은 다음으로 세분됩니다.

• 태그 텍스트 구문

• 태그 텍스트 예제

태그 텍스트 구문

<TagText tag="tagName" 
[attributePatterns=”attribute_patterns_for_ this_tag" source=”*”]/>

여기서

tagName은 태그의 이름입니다.

attributePatterns는 이 태그에 대한 속성 및 그 값의 패턴입니다(옵션, 이 태그에 속성이 전혀 없다는 것을 의미).

source는 이 xml 파일의 URI입니다(옵션, 기본값은 *, 모든 xml 페이지를 의미).

태그 텍스트 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://abc.sesta.com/test/rewriter/test1/xml/page.html

페이지 컨텐트

<xml>
<Attribute name="src">test.html</attribute>
<attribute>abc.html</attribute>
</xml>

규칙

<TagText tag="attribute" attributePatterns="name=src"/>

결과

<xml>
<Attribute name="src">gateway-URL/
http://abc.sesta.com/test/rewriter/test1/
xml/test.html</attribute><attribute>abc.html</attribute>
</xml>

설명

페이지 컨텐트의 첫 번째 행에는 속성 예제가 있습니다. 페이지 컨텐트의 두 번째 행에 name이라는 속성이 없는데 name 속성의 값이 src여야 하기 때문에 다시 작성하는 작업은 수행되지 않습니다. 이것도 다시 작성하려면 <TagText tag="attribute"/>가 있어야 합니다.

속성

XML 속성의 규칙은 HTML에 대한 속성 규칙과 유사합니다. XML의 속성 규칙이 대소문자를 구분하는 반면 HTML 속성은 그렇지 않다는 차이점이 있습니다. 이는 근본적으로 HTML에는 없지만 XML에는 있는 대소문자 구분 특성 때문입니다.

Rewriter는 속성 이름을 바탕으로 속성 값을 변환합니다.

이 절은 다음으로 세분됩니다.

• 속성 구문

• 속성 예제

속성 구문

<Attribute name="attributeName " [tag="*" type=”URL” valuePatterns="*" source=”*”]/>

여기서

attributeName은 속성의 이름입니다(필수).

tag는 이 속성이 있는 태그의 이름입니다(옵션, 기본값은 *, 모든 태그를 의미).

valuePatterns에 대해서는 규칙에 패턴 매칭 사용을 참조하십시오.

source는 이 XML 페이지의 URI입니다(옵션, 기본값은 *, 모든 XML 페이지를 의미).

속성 예제

페이지의 기본 URL이 다음과 같다고 가정합니다.

http://abc.sesta.com/test/rewriter/test1/xml/page.html

페이지 컨텐트

<xml>
<baseroot href="/root.html"/>
<img href="image.html"/>
<string href="1234|substring.html"/>
<check href="1234|string.html"/>
</xml>

규칙

<Attribute name="href"tag="check" valuePatterns="1234|"/>

결과

<xml>
<baseroot href="/root.html"/><img href="image.html"/>
<string href="1234|substring.html"/><check href="1234|
gateway-URL
/http://abc.sesta.com/test/rewriter/test1/xml/string.html"/></xml>

설명

위의 예에서 네 번째 라인만 규칙에 지정된 모든 조건을 만족하기 때문에 이 라인만 다시 작성됩니다. 규칙에 패턴 매칭 사용을 참조하십시오.

CSS(Cascading Style Sheet)에 대한 규칙

HTML 페이지에서 CSS(CSS2 포함)가 변환됩니다. URL이 CSS의 가져오기 구문과 url() 함수에만 있기 때문에 이 변환에 대해 정의된 규칙은 없습니다.

WML에 대한 규칙

WML은 HTML과 유사하므로 WML 컨텐트에 HTML 규칙이 적용됩니다.WML 컨텐트에 일반 규칙 집합을 사용하십시오. HTML 컨텐트에 대한 규칙을 참조하십시오.

재귀적 기능 사용

Rewriter에서는 재귀적 기능을 사용하여 대응되는 문자열 패턴의 끝까지에서 같은 패턴을 검색합니다.

예를 들어 Rewriter에서 다음 문자열을 구문 분석하는 경우

<a href="src=abc.jpg,src=bcd.jpg,src=xyz.jpg>

규칙

<Attribute name="href" valuePatterns="*src=**"/>

은 처음 나타나는 패턴만을 다시 작성하며 그 결과는 다음과 같습니다.

<a href="src=http://jane.sun.com/abc.jpg>

하지만 재귀적 옵션을 사용하면

<Attribute name="href" valuePatterns="REC:*src=**"/>;

Rewriter는 대응되는 문자열 패턴에서 끝까지 같은 패턴을 찾기 때문에 다음과 같은 출력을 얻게 됩니다.

<a href="src=http://jane.sun.com/abc.jpg,src= http://jane.sun.com/bcd.jpg,src=http://jane.sun.com/xyz.jpg>

디버그 로그를 사용한 문제 해결

Rewriter 문제를 해결하려면 디버깅 로그를 사용해야 합니다.

디버깅 메시지는 다음과 같이 분류됩니다.

• 오류– Rewriter가 복구할 수 없는 오류입니다.

• 경고– Rewriter의 기능에 심각한 영향을 미치지 않는 경고입니다. Rewriter는 이 유형의 오류를 복구할 수 있지만 약간의 오작동이 생길 수도 있습니다. 경고 메시지 일부는 정보 제공을 위한 것입니다. 예를 들어 경고 메시지로 "이미지 컨텐트 다시 쓰지 않음"이 기록될 수 있습니다. 이 메시지는 Rewriter에서 이미지를 다시 쓰게 하지 않으므로 문제가 없습니다.

• 메시지– Rewriter가 제공하는 가장 높은 수준의 정보입니다.

Rewriter 디버깅 수준 설정

Rewriter 디버깅 수준을 설정하려면

1. 게이트웨이 컴퓨터에 루트로 로그인하여 다음 파일을 편집합니다.

   gateway-install-root/SUNWam/config/AMConfig-instance-name.properties

2. 디버깅 수준을 설정합니다.

   com.iplanet.services.debug.level=

   디버깅 수준은 다음과 같습니다.

   오류 - 디버그 파일에 심각한 오류만 기록됩니다. 이런 오류가 발생하면 보통 Rewriter가 중지됩니다.

   경고 - 경고 메시지가 기록됩니다.

   메시지 - 모든 디버그 메시지가 기록됩니다.

   off - 디버그 메시지가 기록되지 않습니다.

3. AMConfig-instance-name .properties 파일의 다음 등록 정보에 디버그 파일의 디렉토리를 지정합니다.

   com.iplanet.services.debug.directory=/var/opt/SUNWam/debug

   여기서 /var/opt/SUNWam/debug는 기본 디버그 디렉토리입니다.

4. 터미널 창에서 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

디버깅 파일 이름

디버그 수준이 메시지로 설정된 경우 디버그에서 파일 집합이 생성됩니다. 디버깅 파일 이름에는 Rewriter 파일과 해당 파일에 포함된 정보가 나와 있습니다.

위의 파일 이외에도 Rewriter는 위 파일에서 포착하지 않은 디버그 메시지의 파일을 생성합니다. 이 파일 이름은 두 부분으로 구성됩니다. 첫 번째 부분은 pwRewriter 또는 psSRARewriter이고 두 번째 부분은 portal 또는 gateway-profile-name을 사용하는 확장 부분입니다.

디버깅 파일은 포털 또는 게이트웨이에 표시됩니다. 이 파일은 AMConfig-instance-name .properties 파일에 표시된 디렉토리에 있습니다.

Rewriter 구성 요소는 다음 파일 집합을 생성하여 디버깅을 지원합니다.

prefix_RuleSetInfo.extension

prefix_OrginalPages.extension

prefix_RewrittenPages.extension

prefix_UnaffectedPages.extension

prefix_URIInfo.extension

여기서

prefix는 URLScraper 사용 로그의 경우 psRewriter이고 게이트웨이 사용 로그의 경우 psSRAPRewriter입니다.

extension은 URLScraper 사용의 경우 portal이고 게이트웨이 사용의 경우 gateway-profile-name입니다.

예를 들어, 게이트웨이에서 Rewriter가 페이지를 변환하는데 사용되고 기본 게이트웨이 프로필이 사용되는 경우 디버깅이 다음 파일을 만듭니다.

psSRAPRewriter_RuleSetInfo.default

psSRAPRewriter_OriginalPages.default

psSRAPRewriter_RewrittenPages.default

psSRAPRewriter_UnaffectedPages.default

psSRAPRewriter_URIInfo.default

psSRAPRewriter.default

작업 예제

이 절에서 다루는 내용은 다음과 같습니다.

• 다시 작성해야 하는 컨텐트를 가진 단순 HTML 페이지

• 컨텐트를 다시 작성할 때 필요한 규칙

• 해당 재작성된 HTML 페이지

이러한 예제 페이지는 portal-server-URL/rewriter 디렉토리에 있습니다. 규칙을 적용하기 전에 페이지를 둘러본 다음 게이트웨이를 통해 재작성된 결과 파일을 검토하여 규칙의 작용에 대해 알아봅니다. 규칙이 이미 default_gateway_ruleset의 일부인 경우도 있습니다. 어떤 예제에서는 default_gateway_ruleset에 규칙을 포함시켜야 할 수 있습니다. 해당 위치에서 이에 대해 언급합니다.

굵게 표시된 부분은 다시 작성된 내용입니다.

다음 예제를 이용할 수 있습니다.

HTML

• HTML 속성 예제

• HTML 폼 예제

• HTML 애플릿 예제

JavaScript

• 변수

  • JavaScript URL 변수 예제

  • JavaScript 컨텐트 예제

  • JavaScript DHTML 변수 예제

  • JavaScript DJS 변수 예제

  • JavaScript SYSTEM 변수 예제

함수

• JavaScript URL 함수 예제

• JavaScript EXPRESSION 함수 예제

• JavaScript DHTML 함수 예제

• JavaScript DJS 함수 예제

XML

• XML 속성 예제

HTML 컨텐트 예제

HTML 속성 예제

HTML 속성 예제를 사용하려면

1. 이 예제는 다음에서 액세스할 수 있습니다.

   portal-server-URL /rewriter/HTML/attrib/attribute.html

2. 게이트웨이 서비스에서 [도메인 및 하위 도메인의 프록시] 목록에 abc.sesta.com 및 host1.siroe.com이 정의되어 있어야 합니다.

   정의되어 있지 않으면 직접 연결이 가정되고 게이트웨이 URL이 앞에 덧붙지 않습니다.

   이 예제에서 지정한 규칙은 이미 정의되어 있기 때문에 default_gateway_ruleset에 추가할 필요가 없습니다.

재작성 전의 HTML

<html>
Rewriting starts
<head>
<title>TEST PAGE () </title>
</head>
ID-htmlattr.1
<br><br>
1.a href <a href="http://abc.sesta.com/images/logo.gif">http://..</a>
<br><br>
2. href <a href="https://host1.siroe.com">https://..</a>
<br><br>
3. href <a href="../images/logo.gif">../images/</a>
<br><br>
4. href <a href="images/logo.gif">images/..</a> <br><br>
5. href <a href="../../images/logo.gif">../../images/</a> <br><br>
Rewriting ends
</html>

규칙

<Attribute name="href"/>

재작성 후의 HTML

<html>
Rewriting starts
<head>
<title>TEST PAGE () </title>
</head>
ID-htmlattr.1
<br><br>
1. a href <a href="gateway-URL/http://abc.sesta.com/images/logo.gif">http://..</a> <br>

<Attrib name="href"/> 규칙이 default_gateway_ruleset에 이미 정의되었기 때문에 이 URL은 다시 작성됩니다. URL이 이미 절대 경로이므로 게이트웨이 URL만 접두어로 사용됩니다. 게이트웨이 서비스에서 [도메인 및 하위 도메인의 프록시] 목록에 abc.sesta.com이 정의되어 있어야 합니다. 그렇게 하지 않으면 직접 연결이 가정되기 때문에 게이트웨이 URL이 접두어로 사용되지 않습니다.

2. href <a href="gateway-URL/https://host1.siroe.com">https://..</a>

// 다시 한번, 게이트웨이 서비스에서 [도메인 및 하위 도메인의 프록시] 목록에 host1.siroe.com이 정의되어 있어야 합니다. 그렇게 하지 않으면 직접 연결이 가정되기 때문에 게이트웨이 URL이 접두어로 사용되지 않습니다.

<br><br>
3. href <a href="gateway-URL/portal-server-URL/rewriter/HTML/images/logo.gif">../images/</a>

// 상대 경로가 지정되었기 때문에 필요한 하위 디렉토리와 함께 게이트웨이 URL과 Portal Server URL이 접두어로 사용됩니다. 제공된 예제 구조에서 HTML 디렉토리 아래에 images라는 디렉토리가 지정되지 않았기 때문에 이 링크가 작동하지 않습니다.

<br><br>

4 href <a href="gateway-URL/portal-server-URL/rewriter/HTML/attrib/images/
logo.gif">images/..</a> <br><br>

// 상대 경로가 지정되었기 때문에 필요한 하위 디렉토리와 함께 게이트웨이 URL과 Portal Server URL이 접두어로 사용됩니다.

5. href <a href="gateway-URL/portal-server-URL/rewriter/images/logo.gif">
../../images/</a> <br><br>

// 상대 경로가 지정되었기 때문에 필요한 하위 디렉토리와 함께 게이트웨이 URL과 Portal Server URL이 접두어로 사용됩니다. 제공된 예제 구조에서 Rewriter 디렉토리 아래에 images라는 디렉토리가 지정되지 않았기 때문에 이 링크가 작동하지 않습니다.

Rewriting ends</html>

HTML 동적 JavaScript 토큰 예제

이 절에서는 HTML JavaScript 토큰 예제 사용에 대해 설명합니다.

HTML JavaScript 토큰 예제를 사용하려면

1. 이 예제는 다음에서 액세스할 수 있습니다.

   portal-server-URL /rewriter/HTML/jstokens/JStokens.html

2. 이 예제에 지정된 규칙을 "JavaScript 소스 재작성을 위한 규칙" 부분의 default_gateway_ruleset에 추가하십시오.

3. Portal Server 관리 콘솔에 있는 Portal Server 구성의 Rewriter 서비스에서 default_gateway_ruleset을 편집합니다.

4. 터미널 창에서 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 HTML

<html>
<head>
Rewriting starts
<script language="javascript">
function Check(test,ind){
if (ind == \qblur\q)
{alert("testing onBlur")}
if (ind == \qfocus\q)
{alert("testing onFocus")}
}
</SCRIPT>
</head>
<body>
<form>
<input TYPE=TEXT SIZE=20 value=blur onAbort="Check
(\q/indexblur.html\q,\qblur\q);return;">
<input TYPE=TEXT SIZE=20 value=blur onBlur="Check
(\q/indexblur.html\q,\qblur\q);return;">
<input TYPE=TEXT SIZE=20 value=focus onFocus="Check
(\q/focus.html\q,\qfocus\q);return;">
<input TYPE=TEXT SIZE=20 value=focus onChange="Check
(\q/focus.html\q,\qfocus\q);return;">
<input TYPE=TEXT SIZE=20 value=focus onClick="Check
(\q/focus.html\q,\qblur\q);return;">
<br><br>
</form>
</body>
Rewriting ends
</html>

규칙

<Attribute name=”onClick” type=”DJS”/>
<Function type="URL" name="Check" paramPatterns="y"/>

<Function name="URL" name="Check" paramPatterns="y"/>는 JavaScript 함수 규칙이며 JavaScript 함수 예제에 자세하게 설명되어 있습니다.

재작성 후의 HTML

<html>
<head>
Rewriting starts
<script language="javascript">
function Check(test,ind){
if (ind == \qblur\q)
{alert("testing onBlur")}
if (ind == \qfocus\q)
{alert("testing onFocus")}
}
</SCRIPT>
</head>
<body>
<form>
<input TYPE=TEXT SIZE=20 value=blur onAbort="Check
(\qgateway URL/portal-server-URL/indexblur.html\q,\qblur\q);return;">
<input TYPE=TEXT SIZE=20 value=blur onBlur="Check
(\qgateway URL/portal-server-URL/indexblur.html\q,\qblur\q);return;">
<input TYPE=TEXT SIZE=20 value=focus onFocus="Check
(\qgateway URL/portal-server-URL/focus.html\q,\qfocus\q);return;">
<input TYPE=TEXT SIZE=20 value=focus onChange="Check
(\qgateway URL/portal-server-URL/focus.html\q,\qfocus\q);return;">
<input TYPE=TEXT SIZE=20 value=focus onClick="Check
(\qgateway URL/portal-server-URL/focus.html\q,\qblur\q);return;">

// 이 샘플에서는 모든 명령문이 다시 작성됩니다. 각 경우에 게이트웨이 및 Portal Server URL이 접두어로 사용됩니다. 이것은 onAbort, onBlur, onFocus, onChange 및 onClick에 대한 규칙이 default_gateway_ruleset 파일에 정의되었기 때문입니다. Rewriter는 JavaScript 토큰을 검색한 다음 추가 처리를 할 수 있도록 JavaScript 함수 규칙으로 전달합니다. 샘플의 두 번째 규칙은 Rewriter에 다시 작성할 매개 변수를 알려줍니다.

</body>
<br>

Rewriting ends

</html>

HTML 폼 예제

폼 예제를 사용하려면

1. 다음 위치에서 예제에 액세스합니다.

   portal-server-URL/rewriter/HTML/forms/formrule.html

2. 게이트웨이 서비스에서 [도메인 및 하위 도메인의 프록시] 목록에 abc.sesta.com이 정의되어 있어야 합니다.

   정의되어 있지 않으면 직접 연결이 가정되고 게이트웨이 URL이 앞에 덧붙지 않습니다.

3. 이 예제에 지정된 규칙을 "HTML 속성 재작성을 위한 규칙" 부분의 default_gateway_ruleset에 추가하십시오.

4. Portal Server 관리 콘솔에 있는 Portal Server 구성의 Rewriter 서비스에서 default_gateway_ruleset을 편집합니다.

5. 터미널 창에서 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 HTML 페이지

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body>
RW_START
<p>
<form name="form1" method="Post" action=
"http://abc.sesta.com/casestudy/html/form.html">
<input type="hidden" name="name1" value="0|1234|/test.html">
<input type="hidden" name="name3" value="../../html/test.html">
<form name="form2" method="Post" action="
http://abc.sesta.com/testcases/html/form.html"><br>
<input type="hidden" name="name1" value="0|1234|
../../html/test.html"></form>
RW_END </p>
</body>
</html>

규칙

<Form source="*" name="form1" field="name1" valuePatterns="0|1234|"/>

재작성 후의 HTML 페이지

<HTML>
<HEAD>
RW_START
</HEAD>
<BODY>
<P>
<FORM name=form1  method=POST action="gateway-URL/http://abc.sesta.com/casestudy/html/form.html">

<Attribute name="action"/>이 default_gateway_ruleset에서 HTML 규칙의 일부로 정의되었기 때문에 이 URL은 다시 작성됩니다. URL이 이미 절대 경로이므로 접두어로 게이트웨이 URL만 사용하면 됩니다. 게이트웨이 서비스에서 [도메인 및 하위 도메인의 프록시] 목록에 abc.sesta.com이 정의되어 있어야 합니다. 그렇게 하지 않으면 직접 연결이 가정되기 때문에 게이트웨이 URL이 접두어로 사용되지 않습니다.

<input type=hidden name=name1 value=
"0|1234|gateway URL/portal-server-URL/test.html">

// 여기서 폼 이름은 form1이고 필드 이름은 name1입니다. 이것은 규칙에서 지정된 폼 이름 및 필드 이름과 일치합니다. 규칙에 valuePatterns가 0|1234|로 나와 있으며 이 구문의 value와 일치합니다. 따라서 valuePattern 이후에 나오는 URL은 다시 작성됩니다. Portal Server URL과 게이트웨이 URL이 앞에 덧붙습니다. valuePatterns에 대한 자세한 내용은 “ 규칙에 패턴 매칭 사용을 참조하십시오.

<input type=hidden name=name3 value="../../html/test.html">

// name이 규칙에서 지정된 field 이름에 대응되지 않기 때문에 이 URL은 다시 작성되지 않습니다.

</FORM>
<FORM name=form2 method=POST action=
"gateway-URL/http://abc.sesta.com/casestudy/html/form.html"><BR>

// <Attribute name="action"/>이 기본 규칙 집합에서 HTML 규칙의 일부로 정의되었기 때문에 이 URL은 다시 작성됩니다. URL이 이미 절대 경로이므로 접두어로 게이트웨이 URL만 사용하면 됩니다.

<input type=hidden name=name1 value="0|1234|../../html/test.html">

// 폼 이름이 규칙에서 지정한 이름과 일치하지 않기 때문에 이 URL은 다시 작성되지 않습니다.

</FORM>
</BODY>
RW_END
</HTML>

HTML 애플릿 예제

애플릿 예제를 사용하려면

1. 애플릿 클래스 파일을 얻습니다. RewriteURLinApplet.class 파일은 다음 위치에 있습니다.

   portal-server-URL/rewriter/HTML/applet/appletcode

   애플릿 코드가 있는 페이지의 기본 URL은 다음과 같습니다.

   portal-server-URL/rewriter/HTML/applet/rule1.html

2. 이 예제에 지정된 규칙을 "HTML 속성 재작성을 위한 규칙" 부분의 default_gateway_ruleset에 추가하십시오.

3. Portal Server 관리 콘솔에 있는 Portal Server 구성의 Rewriter 서비스에서 default_gateway_ruleset을 편집합니다.

4. 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 HTML

<html>
Rewriting starts
<br>
<applet codebase=appletcode code=RewriteURLinApplet.class archive=/test>
<param name=Test1 value="/index.html">
<param name=Test2 value="../index.html">
<param name=Test3 value="../../index.html">
</applet>
Rewriting ends
</html>

규칙

<Applet source="*/rule1.html" code="RewriteURLinApplet.class" param="Test*" />

재작성 후의 HTML

<HTML>
Rewriting starts
<BR>
<APPLET codebase=gateway-URL/portal-server-URL
/rewriter/HTML/applet/appletcode=RewriteURLinApplet.class archive=/test>

// <Attribute name="codebase"/> 규칙이 default_gateway_ruleset의 일부로 이미 지정되었기 때문에 이 URL은 다시 작성됩니다. 게이트웨이 및 Portal Server URL에는 appletcode 디렉토리까지의 경로가 접두어로 붙습니다.

<param name=Test1 value=
"gateway-URL/portal-server-URL/index.html">

// 페이지의 기본 URL이 rule1.html이고 매개 변수 이름이 규칙에 지정된 매개 변수 Test* 에 대응되기 때문에 URL은 다시 작성됩니다. index.html이 루트 수준에 있도록 지정되었기 때문에 게이트웨이 및 Portal Server URL이 직접 접두어로 사용됩니다.

<param name=Test2 value="gateway-URL
/portal-server-URL/rewriter/HTML/index.html">

// 페이지의 기본 URL이 rule1.html이고 매개 변수 이름이 규칙에 지정된 매개 변수 Test* 에 대응되기 때문에 URL은 다시 작성됩니다. 필요에 따라 경로가 앞에 덧붙습니다.

<param name=Test3 value="gateway-URL
/portal-server-URL/rewriter/index.html">

// 페이지의 기본 URL이 rule1.html이고 매개 변수 이름이 규칙에 지정된 매개 변수 Test* 에 대응되기 때문에 URL은 다시 작성됩니다. 필요에 따라 경로가 앞에 덧붙습니다.

</APPLET>
Rewriting ends
</HTML>

JavaScript 컨텐트 예제

JavaScript URL 변수 예제

JavaScript URL 변수 예제를 사용하려면

1. 이 예제는 다음에서 액세스할 수 있습니다.

   portal-server-URL /rewriter/JavaScript/variables/url/js_urls.html

2. 게이트웨이 서비스에서 [도메인 및 하위 도메인의 프록시] 목록에 abc.sesta.com이 정의되어 있어야 합니다.

   정의되어 있지 않으면 직접 연결이 가정되고 게이트웨이 URL이 앞에 덧붙지 않습니다.

3. 이 예제에 지정된 규칙을 "JavaScript 소스 재작성을 위한 규칙" 부분의 default_gateway_ruleset에 추가하십시오.

4. Portal Server 관리 콘솔에 있는 Portal Server 구성의 Rewriter 서비스에서 default_gateway_ruleset을 편집합니다.

5. 규칙을 추가한 경우 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 HTML 페이지

<html>
Rewriting starts
<head>
<title>JavaScript Variable test page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
//URL Variables
var imgsrc="/tmp/tmp.jpg";
var imgsrc="./tmp/tmp.jpg";
var imgsrc="../tmp/tmp.jpg";
var imgsrc="../../tmp/tmp.jpg";
var imgsrc="http://abc.sesta.com/tmp/tmp.jpg";
var imgsrc="../../../tmp/tmp.jpg";
var imgsrc="tmp/tmp.jpg";
//-->
</SCRIPT>
<br>
Testing JavaScript variables!
<br>
<img src="images/logo.gif">
<br>
Image
</body>
<br>
Rewriting ends
</html>

규칙

<Variable name=”imgsrc” type="URL"/>

재작성 후의 HTML 페이지

<html>
Rewriting starts
<head>
<title>JavaScript Variable test page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
//URL Variables
var imgsrc="gateway-URL/portal-server-URL/tmp/tmp.jpg";
var imgsrc="gateway-URL/portal-server-URL
/rewriter/JavaScript/variables/url/tmp/tmp.jpg";
var imgsrc="gateway-URL/portal-server-URL
/rewriter/JavaScript/variables/tmp/tmp.jpg";
var imgsrc="gateway-URL/portal-server-URL
/rewriter/JavaScript/tmp/tmp.jpg";
var imgsrc="gateway-URL/http://abc.sesta.com/tmp/tmp.jpg";
var imgsrc="gateway-URL/portal-server-URL/rewriter/tmp/tmp.jpg";
var imgsrc="gateway-URL/portal-server-URL
/rewriter/JavaScript/variables/url/tmp/tmp.jpg";

// 위의 모든 URL은 규칙에 지정된 대로 URL 유형이며 이름이 imgsrc인 JavaScript 변수입니다. 따라서 게이트웨이 및 Portal Server URL이 앞에 덧붙습니다. Portal Server URL에 이어지는 경로는 필요에 따라 덧붙입니다.

//-->
</SCRIPT>
<br>
Testing JavaScript variables!
<br>
<img src="gateway URL/portal-server-URL/rewriter
/JavaScript/variables/url/images/logo.gif">

// <Attribute name="src"/>라는 규칙이 default_gateway_ruleset에 정의되었기 때문에 이 행은 다시 작성됩니다.

<br>
Image
</body>
<br>
Rewriting ends
</html>

JavaScript EXPRESSION 변수 예제

JavaScript Expression 변수 예제를 사용하려면

1. 이 예제는 다음에서 액세스할 수 있습니다.

   portal-server-URL /rewriter/JavaScript/variables/expr/expr.html

2. 이 예제에 지정된 규칙을 "JavaScript 소스 재작성을 위한 규칙" 부분의 default_gateway_ruleset에 추가하십시오(아직 없는 경우).

3. Portal Server 관리 콘솔에 있는 Portal Server 구성의 Rewriter 서비스에서 default_gateway_ruleset을 편집합니다.

4. 규칙을 추가한 경우 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 HTML 페이지

<html>
<head>
<title>JavaScript EXPRESSION Variables Test Page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
//Expression variables
var expvar1="images";
var expvar2="/logo.gif";
var expvar = expvar1 + expvar2;
document.write("<A HREF="+expvar+">EXPRESSION</A><P>")
var expvar="/images/logo"+".gif";
document.write("<A HREF="+expvar+">EXPRESSION</A><P>")
//-->
</SCRIPT>
Testing JavaScript EXPRESSION variables
</body>
</html>

규칙

<Variable type=”EXPRESSION” name="expvar"/>

재작성 후의 HTML 페이지

<html>
<head>
<title>JavaScript EXPRESSION Variables Test Page</title>
</head>
<body>
<SCRIPT>
// Rewriter appends the wrapper function 
psSRAPRewriter_convert_expression here
</SCRIPT>
<script LANGUAGE="Javascript">
<!--
//Expression variables
var expvar1="images";
var expvar2="/logo.gif";
var expvar =psSRAPRewriter_convert_expression( expvar1 + expvar2);

// Rewriter는 이 명령문의 오른쪽을 JavaScript EXPRESSION 변수인 것으로 인식합니다. Rewriter는 서버 쪽에서 이 표현식의 값을 결정할 수 없습니다. 따라서, psSRAPRewriter_convert_expression 함수가 표현식 앞에 덧붙습니다. 이 표현식은 클라이언트 쪽에서 평가되어 필요에 따라 다시 작성됩니다.

document.write("<A HREF="+expvar+">EXPRESSION</A><P>")

// 이전 구문에서 다시 작성된 expvar 값이 이 표현식의 값에 도달하기 위해 사용됩니다. 결과가 유효한 URL이기 때문에(그래픽이 샘플의 이 위치에) 링크가 제대로 작동합니다.

var expvar="gateway URL/portal-server-URL/images/logo"+".gif";

// Rewriter는 expvar의 오른쪽을 문자열 표현식으로 인식합니다. 이것은 서버 쪽에서 결정할 수 있기 때문에 직접 다시 작성됩니다.

document.write("<A HREF="+expvar+">EXPRESSION</A><P>")

// 이전 구문에서 다시 작성된 expvar 값이 이 표현식의 값에 도달하기 위해 사용됩니다. 결과가 유효한 URL이 아니기 때문에(샘플의 이 위치에 그래픽이 없음) 링크가 제대로 작동하지 않습니다.

//-->
</SCRIPT>
Testing JavaScript EXPRESSION variables
</body>
</html>

JavaScript DHTML 변수 예제

JavaScript DHTML 변수 예제를 사용하려면

1. 이 예제는 다음에서 액세스할 수 있습니다.

   portal-server-URL /rewriter/JavaScript/variables/dhtml/dhtml.html

2. 게이트웨이 서비스에서 [도메인 및 하위 도메인의 프록시] 목록에 abc.sesta.com이 정의되어 있어야 합니다. 정의되어 있지 않으면 직접 연결이 가정되고 게이트웨이 URL이 앞에 덧붙지 않습니다.

3. 이 예제에 지정된 규칙을 "JavaScript 소스 재작성을 위한 규칙" 부분의 default_gateway_ruleset에 추가하십시오(아직 없는 경우). Portal Server 관리 콘솔에 있는 Portal Server 구성의 Rewriter 서비스에서 default_gateway_ruleset을 편집합니다.

4. 규칙을 추가한 경우 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 HTML 페이지

<html>
<head>
<title>JavaScript DHTML Variable Test Page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
//DHTML Var
var dhtmlVar="<a href=../../images/test.html>"
var dhtmlVar="<a href=/../images/test.html>"
var dhtmlVar="<a href=/images/test.html>"
var dhtmlVar="<a href=images/test.html>"
var dhtmlVar="<a href=http://abc.sesta.com/images/test.html>"
var dhtmlVar="<img src=http://abc.sesta.com/images/test.html>"
//-->
</SCRIPT>
<br><br>
Testing DHTML Variables
<br><br>
<img src="images/logo.gif">IMAGE
</body>
</html>

규칙

<Variable name="DHTML">dhtmlVar</Variable>

재작성 후의 HTML 페이지

<html>
<head>
<title>JavaScript DHTML Variable Test Page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
//DHTML Var
var dhtmlVar="<a href=gateway-URL/portal-server-URL
/rewriter/JavaScript/images/test.html>"

// JavaScript DHTML 규칙이 dhtmlVar 오른쪽을 동적 HTML 컨텐트로 인식합니다. 따라서 default_gateway_ruleset 파일의 HTML 규칙이 적용됩니다. 동적 HTML에는 href 속성이 들어 있습니다. default_gateway_ruleset은 <Attribute name="href"/>의 규칙을 정의합니다. 따라서 href 속성의 값이 다시 작성됩니다. 하지만 URL은 절대 경로가 아닙니다. 따라서 상대 URL은 페이지의 기본 URL과 필요한 하위 디렉토리로 대체됩니다. 여기에 다시 접두어로 게이트웨이 URL이 사용되어 최종적으로 다시 작성된 결과가 유도됩니다.

var dhtmlVar="<a href=gateway-URL
/portal-server-URL/../images/test.html>"

// 페이지의 기본 URL이 추가되고 게이트웨이 URL이 앞에 덧붙여지지만 결과적인 URL은 올바로 작동하지 않습니다. 초기 URL /../images/test.html이 부정확하기 때문입니다.

var dhtmlVar="<a href=gateway-URL
/portal-server-URL/images/test.html>"

// 여기서 다시 JavaScript DHTML 규칙은 오른쪽을 동적 HTML 컨텐트로 인식하고 이를 HTML 규칙으로 전달합니다. default_gateway_ruleset의 HTML 규칙 <Attribute name="href"/>가 적용되며 명령문이 다음과 같이 다시 작성됩니다. Portal Server URL과 게이트웨이 URL이 접두어로 사용됩니다.

var dhtmlVar="<a href=gateway URL/portal-server-URL/
rewriter/JavaScript/variables/dhtml/images/test.html>"
var dhtmlVar="<a href=gateway URL/http://abc.sesta.com/images/test.html>"
var dhtmlVar="<img src=gateway-URL/
http://abc.sesta.com/images/test.html>"

// JavaScript DHTML 규칙은 오른쪽의 동적 HTML 컨텐트를 확인하고 문구를 HTML 규칙으로 전달합니다. default_gateway_ruleset의 <Attribute name="src"/> 규칙이 적용됩니다. URL이 절대 경로이기 때문에 접두어로 게이트웨이 URL만 사용하면 됩니다. 이 URL을 다시 작성하려면 [도메인 및 하위 도메인의 프록시] 목록에 abc.sesta.com이 정의되어 있어야 합니다.

//-->
</SCRIPT>
<br><br>
Testing DHTML Variables
<br><br>
<img src="gateway-URL/portal-server-URL/
rewriter/JavaScript/variables/dhtml/images/logo.gif">

// <Attribute name="src"/>라는 규칙이 default_gateway_ruleset에 정의되었기 때문에 이 행은 다시 작성됩니다.

<br><br>
Image
</body>
</html>

JavaScript DJS 변수 예제

JavaScript DJS 변수 예제를 사용하려면

1. 이 예제는 다음에서 액세스할 수 있습니다.

   portal-server-URL /rewriter/JavaScript/variables/djs/djs.html

2. 게이트웨이 서비스에서 [도메인 및 하위 도메인의 프록시] 목록에 abc.sesta.com이 정의되어 있어야 합니다. 정의되어 있지 않으면 직접 연결이 가정되고 게이트웨이 URL이 앞에 덧붙지 않습니다.

3. 이 예제에 지정된 두 규칙을 "JavaScript 소스 재작성을 위한 규칙" 부분의 default_gateway_ruleset에 추가하십시오(아직 없는 경우). Portal Server 관리 콘솔에 있는 Portal Server 구성의 Rewriter 서비스에서 default_gateway_ruleset을 편집합니다.

4. 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 HTML 페이지

<html>
<head>
<title>Dynamic JavaScript Variable Test Page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
var dJSVar="var dJSimgsrc=\q/tmp/tmp/jpg\q;"
var dJSVar="var dJSimgsrc=\q../../../tmp/tmp/jpg\q;"
var dJSVar="var dJSimgsrc=\qhttp://abc.sesta.com/tmp/tmp/jpg\q;"
//-->
</SCRIPT>
<br>
Testing Dynamic JavaScript Variables
<br>
<img src="images/logo.gif">
<br>
Image
</body>
</html>

규칙

<Variable name=”dJSVar” type="DJS"/>
<Variable name="dJSimgsrc“ type=URL"/>

재작성 후의 HTML 페이지

<html>
<head>
<title>Dynamic JavaScript Variable Test Page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
var dJSVar="var dJSimgsrc=\qgateway-URL
/portal-server-URL/tmp/tmp/jpg\q;"
var dJSVar="var dJSimgsrc=\qgateway-URL
/portal-server-URL/rewriter/tmp/tmp/jpg\q;"
var dJSVar="var dJSimgsrc=\qgateway-URL
/http://abc.sesta.com/tmp/tmp/jpg\q;"

// 위의 모든 구문은 게이트웨이 및 Portal Server URL로 다시 작성됩니다. 필요한 경로가 적합하게 앞에 덧붙여집니다. 첫 번째 규칙은 dJSVar의 오른쪽을 동적 JavaScript 변수로 인식합니다. 그런 다음 dJSimgsrc의 오른쪽을 URL 유형의 JavaScript 변수로 인식하는 두 번째 규칙으로 전달됩니다. 규칙에 따라 다시 작성됩니다.

//-->
</SCRIPT>
<br>
Testing Dynamic JavaScript Variables
<br>
<img src="gateway-URL/portal-server-URL
/rewriter/JavaScript/variables/djs/images/logo.gif">

// <Attribute name="src"/>라는 규칙이 default_gateway_ruleset에 정의되었기 때문에 이 행은 다시 작성됩니다.

<br>
Image
</body>
</html>

JavaScript SYSTEM 변수 예제

JavaScript System 변수 예제를 사용하려면

1. 이 예제는 다음에서 액세스할 수 있습니다.

   portal-server-URL /rewriter/JavaScript/variables/system/system.html

2. 이 예제에 지정된 규칙을 "JavaScript 소스 재작성을 위한 규칙" 부분의 default_gateway_ruleset에 추가하십시오(아직 없는 경우).

3. Portal Server 관리 콘솔에 있는 Portal Server 구성의 Rewriter 서비스에서 default_gateway_ruleset을 편집합니다.

4. 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 HTML 페이지

<html>
<head>
<title>JavaScript SYSTEM Variables Test Page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
//SYSTEM Var
alert(window.location.pathname);
//document.write
("<A HREF="+window.location.pathname+">SYSTEM</A><P>")
//-->
</SCRIPT>
Testing JavaScript SYSTEM Variables
<br>
This page displays the path where 
the current page is located when loaded.
</body>
</html>

규칙

<Variable name=”window.location.pathname” type="SYSTEM"/>

재작성 후의 HTML

<html>
<head>
<title>JavaScript SYSTEM Variables Test Page</title>
</head>
<body>
<SCRIPT>
convertsystem function definition...
</SCRIPT>
<script LANGUAGE="Javascript">
<!--
//SYSTEM Var
alert(psSRAPRewriter_convert_system
(window.location, window.location.pathname,”window.location”));

// Rewriter는 window.location.pathname을 JavaScript SYSTEM 변수로 인식합니다. 이 변수의 값은 서버 쪽에서 결정할 수 없습니다. 따라서 Rewriter는 변수 앞에 psSRAPRewriter_convert_pathname 함수를 덧붙입니다. 이 래퍼 함수는 클라이언트 쪽에서 변수의 값을 결정하고 필요에 따라 다시 작성합니다.

//-->
</SCRIPT>
Testing JavaScript SYSTEM Variables
<br>
This page displays the path where
the current page is located when loaded.
</body>
</html>

JavaScript URL 함수 예제

JavaScript URL 함수 예제를 사용하려면

1. 이 예제는 다음에서 액세스할 수 있습니다.

   portal-server-URL /rewriter/JavaScript/functions/url/url.html

2. 이 예제에 지정된 규칙을 "JavaScript 소스 재작성을 위한 규칙" 부분의 default_gateway_ruleset에 추가하십시오(아직 없는 경우). Portal Server 관리 콘솔에 있는 Portal Server 구성의 Rewriter 서비스에서 default_gateway_ruleset을 편집합니다.

3. 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 HTML 페이지

<html>
<body>
JavaScript URL Function Test Page
<br>
<script language="JavaScript">
<!--
function test(one,two,three)
{
alert(one + "##" + two + "##" +three);
}
test("/test.html","../test.html","123");
window.open("/index.html","gen",width=500,height=500);
//-->
</SCRIPT>
</body>
</html>

규칙

<Function type="URL" name="test" paramPatterns="y,y"/>
<Function type="URL" name="window.open" paramPatterns="y"/>

재작성 후의 HTML 페이지

<html>
<body>
JavaScript URL Function Test Page
<br>
<script language="JavaScript">
<!--
function test(one,two,three)
{
alert(one + "##" + two + "##" +three);
}
test("/test.html","../test.html","123");
window.open("gateway-URL/portal-server-URL
/index.html","gen",width=500,height=500);
//-->
</SCRIPT>
</body>
</html>

JavaScript EXPRESSION 함수 예제

JavaScript Expressions 함수 예제를 사용하려면

1. 이 예제는 다음에서 액세스할 수 있습니다.

   <portal-install-location>/SUNWportal/samples/rewriter

2. 이 예제에 지정된 규칙을 JavaScript 소스 재작성을 위한 규칙 부분의 default_gateway_ruleset에 추가하십시오(아직 없는 경우).

3. Portal Server 관리 콘솔을 사용하여 Rewriter 서비스의 default_gateway_ruleset을 편집합니다.

4. 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 HTML 페이지

<html>
<body>
JavaScript EXPRESSION Function Test Page
<br><br><br>
<script language="JavaScript">
<!--
function jstest2()
{
return ".html";
}
function jstest1(one)
{
return one;
}
var dir="/images/test"
var test1=jstest1(dir+"/test"+jstest2());
document.write("<a HREF="+test1+">Test</a>");
alert(test1);
//-->
</SCRIPT>
</body>
</html>

규칙

<Function type="EXPRESSION" name="jstest1" paramPatterns="y"/>

재작성 후의 HTML 페이지

<html>
<body>
JavaScript EXPRESSION Function Test Page
<br><br><br>
<script>
<!--
// various functions including psSRAPRewriter_
convert_expression appear here.//-->
</SCRIPT>
<script language="JavaScript">
<!--
function jstest2()
{
return ".html";
}
function jstest1(one)
{
return one;
}
var dir="/images/test"
var test1=jstest1(psSRAPRewriter_convert_
expression(dir+"/test"+jstest2()));

// 규칙이 EXPRESSION 유형인 jstest1 함수의 첫 번째 매개 변수를 다시 써야 한다고 규정합니다. 이 표현식의 값은 /test/images/test.html입니다. 이 앞에 게이트웨이 및 Portal Server URL이 덧붙습니다.

document.write("<a HREF="+test1+">Test</a>");
alert(test1);
//-->
</SCRIPT>
</body>
</html>

JavaScript DHTML 함수 예제

JavaScript DHTML 함수 예제를 사용하려면

1. 이 예제는 다음에서 액세스할 수 있습니다.

   portal-server-URL /rewriter/JavaScript/functions/dhtml/dhtml.html

2. 이 예제에 지정된 규칙을 "JavaScript 소스 재작성을 위한 규칙" 부분의 default_gateway_ruleset에 추가하십시오(아직 없는 경우).

3. Portal Server 관리 콘솔에 있는 Portal Server 구성의 Rewriter 서비스에서 default_gateway_ruleset을 편집합니다.

4. 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 HTML 페이지

<html>
<head>
Testing JavaScript DHTML Functions
<br>
<br>
<script>
<!--
document.write(\q<a href="/index.html">write</a><BR>\q)
document.writeln(\q<a href="index.html">writeln</a><BR>\q)
document.write("http://abc.sesta.com/index.html<BR>")
document.writeln("http://abc.sesta.com/index.html<BR>")
//-->
</SCRIPT>
</head>
<body BGCOLOR=white>
<br><br>
Testing document.write and document.writeln
</body>
</html>

규칙

<Function type="DHTML" name=" document.write" paramPatterns="y"/>
<Function type="DHTML" name=" document.writeln" paramPatterns="y"/>

재작성 후의 HTML 페이지

<html>
<head>
Testing JavaScript DHTML Functions
<br>
<br>
<script>
<!--
document.write(\q<a href="gateway-URL
/portal-server-URL/index.html">write</a><BR>\q)

// 첫 번째 규칙은 DHTML JavaScript 함수 document.write의 첫 번째 매개 변수를 다시 작성해야 한다고 지정합니다. Rewriter는 첫 번째 매개 변수를 단순 HTML 명령문으로 파악합니다. default_gateway_ruleset의 HTML 규칙 부분에는 구문을 다시 써야 한다고 지시하는<Attribute name="href" /> 규칙이 있습니다.

document.writeln(\q<a href="gateway-URL
/portal-server-URL/rewriter/JavaScript/functions/dhtml/index.html">writeln</a><BR>\q)

// 두 번째 규칙은 DHTML JavaScript 함수 document.writeln의 첫 번째 매개 변수를 다시 작성해야 한다고 지정합니다. Rewriter는 첫 번째 매개 변수를 단순 HTML 명령문으로 파악합니다. default_gateway_ruleset의 HTML 규칙 부분에는 구문을 다시 써야 한다고 지시하는<Attribute name="href" /> 규칙이 있습니다.

document.write("http://abc.sesta.com/index.html<BR>")
document.writeln("http://abc.sesta.com/index.html<BR>")

// DHTML 규칙이 함수 document.write 및 document.writeln을 식별하지만 위의 구문이 다시 작성되지 않습니다. 이 경우의 첫 번째 매개 변수가 단순 HTML이 아니기 때문입니다. 이것은 어떤 문자열도 될 수 있으며 Rewriter는 이를 다시 작성하는 방법을 알지 못합니다.

//-->
</SCRIPT>
</head>
<body BGCOLOR=white>
<br><br>
Testing document.write and document.writeln
</body>
</html>

JavaScript DJS 함수 예제

JavaScript DJS 함수 예제를 사용하려면

1. 이 예제는 다음에서 액세스할 수 있습니다.

   portal-server-URL /rewriter/JavaScript/functions/djs/djs.html

2. 게이트웨이 서비스에서 [도메인 및 하위 도메인의 프록시] 목록에 abc.sesta.com이 정의되어 있어야 합니다.

   정의되어 있지 않으면 직접 연결이 가정되고 게이트웨이 URL이 앞에 덧붙지 않습니다.

3. 이 예제에 지정된 규칙을 "JavaScript 소스 재작성을 위한 규칙" 부분의 default_gateway_ruleset에 추가하십시오(아직 없는 경우). Portal Server 관리 콘솔에 있는 Portal Server 구성의 Rewriter 서비스에서 default_gateway_ruleset을 편집합니다.

4. 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 HTML 페이지

<html>
Test for JavaScript DJS Functions
<br>
<script>
menu.addItem(new NavBarMenuItem("All Available
Information","JavaScript:top.location=\qhttp://abc.sesta.com\q"));
//menu.addItem(new NavBarMenuItem("All Available Information","http://abc.sesta.com"));
</script>
</html>

규칙

<Function type="DJS" name="NavBarMenuItem" paramPatterns=",y"/>
<Variable type="URL" name=”top.location”/>

재작성 후의 HTML 페이지

<html>
Testing JavaScript DJS Functions
<br>
<script>
menu.addItem(new NavBarMenuItem
("All Available Information","javaScript:top.location=
\qgateway-URL/http://abc.sesta.com\q"));

// abc.sesta.com은 게이트웨이 서비스에서 [도메인 및 하위 도메인의 프록시] 목록에 있는 항목입니다. 따라서 Rewriter는 이 URL을 다시 작성해야 합니다. 그러나 이 값은 절대 URL이기 때문에 접두어로 Portal Server URL을 사용할 필요가 없습니다. DJS 규칙은 DJS 함수 NavBarMenuItem의 두 번째 매개 변수를 다시 작성해야 한다고 지정합니다. 하지만 두 번째 매개 변수 역시 JavaScript 변수입니다. 이 변수의 값을 다시 쓰기 위해 두 번째 규칙이 필요합니다. 두 번째 규칙은 JavaScript 변수 top.location의 값을 다시 써야 한다고 지정합니다. 모든 조건이 충족되면 URL이 다시 작성됩니다.

//menu.addItem(new NavBarMenuItem("All Available Information","http://abc.sesta.com"));

// DJS 규칙에서 함수 NavBarMenuItem의 두 번째 매개 변수를 다시 써야 한다고 지정하고 있지만 이 구문에서는 다시 쓰지 않습니다. Rewriter가 두 번째 매개 변수를 단순 HTML로 인식하지 않기 때문입니다.

</script>
</html>

XML 속성 예제

XML 속성 예제를 사용하려면

1. 이 예제는 다음에서 액세스할 수 있습니다.

   portal-server-URL /rewriter/XML/attrib.html

2. 이 예제에 지정된 규칙을 "XML 소스 재작성을 위한 규칙" 부분의 default_gateway_ruleset에 추가하십시오(아직 없는 경우).

3. Portal Server 관리 콘솔에 있는 Portal Server 구성의 Rewriter 서비스에서 default_gateway_ruleset을 편집합니다.

4. 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

재작성 전의 XML

<html>
RW_START
<body>
<xml>
<baseroot href="/root.html"/>
</xml>
<xml>
<img href="image.html"/>
</xml>
<xml>
<string href="1234|substring.html"/>
</xml>
<xml>
<check href="1234|string.html"/>
</xml>
</body>
RW_END
</html>

규칙

<Attribute name="href" tag="check" valuePatterns="1234|"/>

재작성 후의 HTML

<html>
Rewriting starts
<br>
<br>
<body>
<xml><baseroot href="/root.html"/></xml>
<xml><img href="image.html"/></xml>
<xml><string href="1234|substring.html"/></xml>
<xml><check href="1234|gateway-URL/portal-server-URL
/rewriter/XML/string.html"/></xml>

// 이 명령문은 규칙에 지정된 조건에 대응되기 때문에 다시 작성됩니다. Attribute name은 href이고 tag는 check이고 valuePatterns는 1234이며, valuePatterns 이후의 문자열이 다시 작성됩니다. valuePatterns에 대한 자세한 내용은 규칙에 패턴 매칭 사용을 참조하십시오.

</body>
Rewriting ends
</html>

사례 연구

여기에는 예제 메일 클라이언트에 대한 소스 HTML 페이지가 포함되어 있습니다. 이 사례 연구에서는 가능한 모든 경우와 규칙을 다루지 않습니다. 실제 인트라넷 페이지의 규칙을 쉽게 구성하도록 돕기 위한 예제 규칙 집합입니다.

가정

이 사례 연구에서는 다음을 가정합니다.

• 메일 클라이언트의 기본 URL이 abc.siroe.com이라고 가정합니다.

• 게이트웨이 URL이 gateway.sesta.com이라고 가정합니다.

• 게이트웨이 서비스의 [도메인 및 부속 도메인의 프록시] 목록에 관련 항목이 있습니다.

예제 페이지 1

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0053)http://abc.siroe.com/mailclient/destin/?Cmd=navbar -->
<HTML XMLNS:WM><HEAD>
<META http-equiv=Content-Type content="text/html; CHARSET=utf-8">
<META http-equiv=Pragma content=no-cache>
<META http-equiv=Expires content=0><!--Copyright (c) 2000 Microsoft Corporation.
All rights reserved.--><!--CURRENT FILE== "IE5" "WIN32" navbar -->
<STYLE>WM\\:DROPMENU {
BEHAVIOR: url(http://abc.siroe.com/mailweb/controls/dropmenu.htc)
}
</STYLE>
<LINK href="destin_files/navbar.css" type=text/css rel=stylesheet>
<SCRIPT language=javascript>
var g_szUserBase= "http://abc.siroe.com/mailclient/destin"+"/";
var g_szFolder= ".";
var g_szVirtualRoot= "http://abc.siroe.com/mailweb";
var g_szImagePath= g_szVirtualRoot + "/img/";
</SCRIPT>
<SCRIPT src="/destin_files/navbar.js"></SCRIPT>
<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY oncontextmenu=return(event.ctrlKey); onselectstart=return(false);
id=outbar_mainbody style="BACKGROUND-COLOR: appworkspace" leftMargin=0
topMargin=0 scroll=no>
<TABLE class=nbTableMain id=nbTableMain style="HEIGHT: 100%" cellSpacing=0
cols=1 cellPadding=0 rows="2">
<TBODY>
<TR>
<TD class=treeBrand>
<DIV class=treeOFLOW><IMG
style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; PADDING-TOP: 0px"
src="/destin_files/logo-ie5.gif" border=0></DIV></TD></TR>
<TR height="100%">
<TD>
<TABLE class=nbTable cellSpacing=0 cols=1 cellPadding=0 rows="4">
<TBODY>
<TR>
<TD class=nbFlybar id=show_navbar onkeydown=flybar_keydown()
onclick=ToggleTab(this.id) tabIndex=0 noWrap>
<DIV class=treeOFLOW>Shortcuts</DIV></TD></TR>
<TR style="HEIGHT: 100%">
<TD id=idOutbarpane style="TEXT-ALIGN: center" vAlign=top><A
id=inbox
href="http://abc.siroe.com/mailclient/destin/Inbox/?Cmd=contents&amp;Page=1"
target=viewer alt="Go to inbox"><IMG class=nbImage alt="Go to inbox"
src="destin_files/navbar-inbox.gif"></A>
<DIV class=nbLabel>Inbox</DIV><BR><A id=calendar
href="http://abc.siroe.com/mailclient/destin/Calendar/?Cmd=contents"
target=viewer alt="Go to calendar"><IMG class=nbImage
alt="Go to calendar" src="destin_files/navbar-calendar.gif"></A>
<DIV class=nbLabel>Calendar</DIV><BR><A id=contacts
            href="http://abc.siroe.com/mailclient/destin/Contacts/?Cmd=contents"
target=viewer alt="Go to contacts"><IMG class=nbImage
alt="Go to contacts" src="destin_files/navbar-contacts.gif"></A>
<DIV class=nbLabel>Contacts</DIV><BR><A id=options
href="http://abc.siroe.com/mailclient/destin/?Cmd=options"
target=viewer alt="Go to options"><IMG class=nbImage
alt="Go to options" src="destin_files/navbar-options.gif"></A>
<DIV class=nbLabel>Options</DIV></TD></TR>
<TR style="HEIGHT: 1.5em">
<TD class=nbFlybar id=show_folders onkeydown=flybar_keydown()
onclick=ToggleTab(this.id) tabIndex=0 noWrap>
<DIV class=treeOFLOW>Folders</DIV></TD></TR>
<TR>
<TD class=nbTreeProgress id=treeProgress style="DISPLAY: none"
vAlign=top noWrap><SPAN id=idLoading
style="OVERFLOW: hidden">Loading...</SPAN>
</TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
</BODY></HTML>

설명

설명에서는 예제 규칙 집합과 사례 연구 사이의 매핑을 보여줍니다.

var g_szVirtualRoot=
"http://abc.siroe.com/mailweb";

var g_szVirtualRoot= 
"http://gateway.sesta.com
/http://abc.siroe.com/mailweb";

src="/destin_files/
logo-ie5.gif"

src="http://gateway.sesta.com/
http://abc.siroe.com/
destin_files/logo-ie5.gif

href="http://abc.siroe.com

/mailclient/destin/Inbox/
?Cmd=contents&Page=1"

href="http://gateway.sesta.com/
http://abc.siroe.com
/mailclient/destin/
Inbox/?Cmd=contents&Page=1"

규칙 집합을 적용하는 우선 순위는 hostname-subdomain-domain입니다.

예를 들어, 도메인 기반 규칙 집합 목록에 다음 항목이 있다고 가정합니다.

sesta.com|ruleset1
eng.sesta.com|ruleset2
host1.eng.sesta.com|ruleset3

ruleset3은 host1의 모든 페이지에 적용됩니다.

ruleset2는 host1에서 가져온 페이지를 제외하고 eng 하위 도메인의 모든 페이지에 적용됩니다.

ruleset1은 eng 하위 도메인과 host1에서 가져온 페이지를 제외하고 sesta.com 도메인의 모든 페이지에 적용됩니다.

1. [저장]을 눌러 완료합니다.

2. 터미널 창에서 게이트웨이를 다시 시작합니다.

   ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

Outlook Web Access의 규칙 집합

Secure Remote Access 서버는 Sun Java System Web Server 및 IBM 응용 프로그램 서버에 설치된 MS Exchange 2000 SP3과 Outlook Web Access(OWA)의 MS Exchange 2003을 지원합니다.

OWA 규칙 집합을 구성하려면

1. Portal Server 관리 콘솔에 관리자로 로그인합니다.

2. [Secure Remote Access] 탭을 선택하고 속성을 설정할 게이트웨이 프로필을 선택합니다.

3. [규칙 집합에 URI 매핑] 필드에서 Exchange 2000이 설치된 서버 이름, 그리고 이어 Exchange 2000 서비스 팩 4 OWA 규칙 집합의 이름을 입력합니다.

   예:

   exchange.domain.com|exchange_2000sp3_owa_ruleset.

공용 폴더 사용

Exchange에서 NTLM 인증을 사용하도록 공용 폴더를 구성합니다. HTTP 기본 인증을 사용하려면 이러한 구성이 필요합니다.

이를 수행하려면 Exchange 서버에서 [제어판]-->[관리 도구]를 선택한 다음 [인터넷 정보 서비스(IIS)]를 엽니다.

[기본 웹 사이트] 아래에 [공용]이라는 공용 폴더용 탭이 있습니다. 등록 정보를 마우스 오른쪽 버튼으로 눌러 선택합니다. [디렉터리 보안] 탭을 누릅니다. [익명 액세스 및 인증] 제어판에서 [편집...]을 선택합니다. 다른 옵션은 모두 선택을 취소하고 [기본 인증]만 선택합니다.

6.x 규칙 집합을 3.0과 매핑

다음 표에는 Secure Remote Access 서버 Rewriter 규칙과 이전 릴리스의 Portal Server 제품의 매핑이 정리되어 있습니다.

5장 NetFile 작업

이 장에서는 NetFile 및 관련 작업에 대해 설명합니다. NetFile을 구성하려면 14 장, NetFile 구성을 참조하십시오.

• NetFile 소개

• 지원되는 파일 액세스 프로토콜

NetFile 소개

NetFile은 사용자가 원격 파일 시스템과 디렉토리에 원격으로 액세스하여 작업할 수 있도록 해주는 파일 관리자 응용 프로그램입니다.

Secure Remote Access의 NetFile 구성 요소는 Java2 애플릿으로 사용할 수 있습니다. Java2 애플릿에는 뛰어난 인터페이스가 있으며 액세스가 더 편합니다.

NetFile에는 다음과 같은 주요 기능이 있습니다.

• 공유 또는 폴더를 추가하거나 제거하는 기능

• 파일 업로드 및 다운로드

• 파일 및 폴더 검색

• GZIP 및 ZIP을 통한 파일 압축

• NetFile 환경의 메일 기능

• 현재 NetFile 세션 정보 저장

• 파일 끌어서 놓기

지원되는 파일 액세스 프로토콜

NetFile에서는 FTP, NFS 및 jCIFS(Microsoft Windows) 프로토콜을 사용하여 원격 시스템에 액세스할 수 있습니다. NetFile에는 다음과 같은 파일 액세스 프로토콜 기능도 있습니다.

• 사용자가 AUTODETECT를 지정하여 시스템을 추가하면 NetFile은 다음 시퀀스를 통해 사용할 프로토콜을 자동으로 감지합니다.

  • 포트 21에서 FTP 서버용 호스트를 확인합니다. FTP 응답에 문자열 "NetWare"가 들어 있으면 NETWARE 호스트로 간주됩니다.

  • 포트 2049에서 NFS 서버용 호스트를 확인합니다.

  • 포트 139에서 Microsoft Windows용 호스트를 확인합니다.

  • 위의 모든 조치가 실패할 경우 호스트 유형을 결정할 수 없다는 메시지가 표시됩니다.

    감지되는 첫 번째 파일 시스템 유형이 요청된 호스트에 연결하는 데 사용됩니다. 호스트 감지 순서는 Portal Server 관리 콘솔(PSConsole)에서 변경할 수 있습니다.

서버가 비 표준 포트에서 실행 중이면 연결이 실패합니다.

• NetFile을 사용하면 사용자가 원하는 파일 서버와 프로토콜을 선택할 수 있습니다.

  각 프로토콜에 지원되는 플랫폼이 아래에 나열되어 있습니다.

NetFile을 사용하여 파일을 ProFTPD 서버에 업로드하려면 ProFTPD 서버가 실행되는 호스트의 proftpd.conf 파일에서 "AllowStoreRestart"를 "on"으로 설정해야 합니다.

Novell Netware는 FTP서버를 통해서만 지원되며 원시 액세스를 통해서는 지원되지 않습니다.

Microsoft Windows(SMB/CIFS) 파일 시스템에 액세스하려면 jCIFS를 Portal Server에 설치해야 합니다. jCIFS는 CIFS/SMB 네트워킹 프로토콜을 구현하는 Open Source 클라이언트 라이브러리입니다.

NetFile 정책을 만들려면

1. Portal 관리 콘솔에 관리자로 로그인합니다.

2. [Secure Remote Access] 탭과 [NetFile] 탭을 차례로 선택합니다.

3. [DN 선택] 드롭다운 상자에서 조직/역할/사용자를 선택합니다.

4. 호스트 및 서비스에 대한 액세스/거부 권한을 설정합니다.

5. [저장]을 누릅니다.

6. 게이트웨이를 다시 시작합니다.

6장 Netlet 작업

이 장에서는 Netlet을 사용하여 사용자의 원격 데스크탑과 인트라넷에서 응용 프로그램을 실행하는 서버 사이에서 응용 프로그램을 안전하게 실행하는 방법을 설명합니다. Netlet을 구성하려면 11 장, Netlet 구성을 참조하십시오.

이번 장은 다음 절로 구성됩니다.

• Netlet 소개

• 원격 호스트에서 애플릿 다운로드

• Netlet 규칙 정의

• 예제 Netlet 규칙

• Netlet 로깅 정보

• Sun Ray 환경에서 Netlet 실행

Netlet 소개

Sun Java System Portal Server 소프트웨어 사용자는 원격 데스크탑에서 가장 많이 사용하는 응용 프로그램이나 회사별 응용 프로그램을 안전한 방식으로 실행할 수 있습니다. 플랫폼에 Netlet을 설치하면 이 응용 프로그램에 대한 액세스를 보호할 수 있습니다.

Netlet을 사용하면 인터넷과 같은 비보안 네트워크에서 공통 TCP/IP 서비스를 안전하게 실행할 수 있습니다. TCP/IP 응용 프로그램(예: 텔넷 및 SMTP), HTTP 응용 프로그램 및 모든 고정 포트 응용 프로그램을 실행할 수 있습니다.

TCP/IP 기반 응용 프로그램 또는 고정 포트를 사용하는 응용 프로그램은 Netlet을 통해 실행할 수 있습니다.

동적 포트는 FTP를 사용할 때에만 지원됩니다. Microsoft Exchange를 사용하려면 Outlook Web Access(OWA)를 사용합니다.

Netlet을 사용하는 경우에는 브라우저에서 팝업 차단 옵션을 비활성화하도록 사용자에게 알려야 합니다.

Netlet 구성 요소

Netlet에서 사용하는 다양한 구성 요소는 Netlet 구성 요소에 나와 있습니다.

그림 6–1 Netlet 구성 요소

localhost의 수신 포트

Netlet 애플릿이 수신하는 클라이언트 컴퓨터에 있는 포트입니다. 클라이언트 컴퓨터는 localhost입니다.

Netlet 애플릿

Netlet 애플릿은 원격 클라이언트 컴퓨터와 Telnet, Grphon 또는 Citrix와 같은 인트라넷 응용 프로그램 사이에 암호화된 TCP/IP 터널을 설정하는 역할을 합니다. 애플릿은 패킷을 암호화하여 이를 게이트웨이로 보낸 다음, 게이트웨이로부터 받은 응답 패킷의 암호를 해독하여 로컬 응용 프로그램으로 보냅니다.

정적 규칙의 경우 Netlet 애플릿은 사용자가 포털에 로그인하면 자동으로 다운로드됩니다. 동적 규칙의 경우, 사용자가 동적 규칙에 해당하는 링크를 누르면 애플릿이 다운로드됩니다. 정적 및 동적 규칙에 대한 자세한 내용은 규칙의 유형을 참조하십시오.

Sun Ray 환경에서 Netlet을 실행하려면 Sun Ray 환경에서 Netlet 실행을 참조하십시오.

Netlet 규칙

Netlet 규칙은 클라이언트 시스템에서 실행해야 하는 응용 프로그램을 해당 대상 호스트로 매핑합니다. 이는 Netlet 규칙에 정의된 포트로 패킷이 전송되는 경우에만 Netlet이 작동한다는 것을 의미합니다. 이 옵션을 설정하면 보안이 강화됩니다.

관리자로서 Netlet이 제 기능을 발휘하도록 하려면 특정 규칙을 구성해야 합니다. 이 규칙은 사용할 암호, 불러올 URL, 다운로드할 애플릿, 대상 포트 및 대상 호스트와 같은 다양한 상세 정보를 지정합니다. 클라이언트 시스템에 있는 사용자가 Netlet을 통해 요청하면 이 규칙에 의해 연결 설정 방식이 결정됩니다. 자세한 내용은 Netlet 규칙 정의를 참조하십시오.

Netlet 공급자

Netlet의 UI 구성 요소입니다. 공급자는 사용자가 Portal Server 데스크탑에서 필요한 응용 프로그램을 구성할 수 있도록 해줍니다. 공급자에서 링크를 만든 후 사용자가 그 링크를 누르면 필요한 응용 프로그램 실행됩니다. 사용자는 Netlet 공급자의 데스크탑에서 동적 규칙의 대상 호스트를 지정할 수도 있습니다. Netlet 규칙 정의를 참조하십시오.

Netlet 프록시(선택 사항)

게이트웨이는 원격 클라이언트 컴퓨터와 게이트웨이 사이에 보안 터널을 보장합니다. Netlet 프록시는 선택 사항이며 설치 중에 이 프록시의 설치는 선택하지 않아도 됩니다. Netlet 프록시에 대한 자세한 내용은 Netlet 프록시 사용을 참조하십시오.

Netlet 사용 시나리오

Netlet을 사용하는 경우 다음 이벤트 시퀀스가 사용됩니다.

1. 원격 사용자가 Portal Server 데스크탑에 로그인합니다.

2. 사용자, 역할 또는 조직에 정적 Netlet 규칙이 정의되어 있으면 Netlet 애플릿이 원격 클라이언트에게 자동으로 다운로드됩니다.

   사용자, 역할 또는 조직에 동적 규칙이 정의되어 있으면 사용자는 Netlet 공급자에서 필요한 응용 프로그램을 구성해야 합니다. 사용자가 Netlet 공급자에서 응용 프로그램 링크를 누르면 Netlet 애플릿이 다운로드됩니다. 정적 및 동적 규칙에 대한 자세한 내용은 Netlet 규칙 정의를 참조하십시오.

3. Netlet이 Netlet 규칙에 정의된 로컬 포트에서 수신합니다.

4. Netlet이 Netlet 규칙에 지정된 포트에서 원격 클라이언트와 호스트 사이의 채널을 설정합니다.

Netlet 작업

Netlet이 여러 조직에 있는 다양한 사용자의 필요에 따라 작동할 수 있으려면 다음을 수행해야 합니다.

1. 사용자 요구사항에 따라 정적 규칙이나 동적 규칙 중 어느 것을 만들어야 할지 결정합니다. 규칙의 유형을 참조하십시오.

2. Portal Server 관리 콘솔에서 Netlet 서비스의 옵션을 구성합니다. Netlet 구성에 대한 자세한 내용은 11 장, Netlet 구성을 참조하십시오.

3. 규칙이 조직, 역할 또는 사용자 중 어디에 기반할지 결정하고 각 수준에서 필요에 따라 수정합니다. 조직, 역할, 사용자에 대한 자세한 내용은 Portal Server 관리 설명서를 참조하십시오.

   ---

   주 –

   srapNetletServlet.properties 파일에서 프레임 집합 매개 변수의 값을 현지화하지 마십시오.

   ---

원격 호스트에서 애플릿 다운로드

원격 시스템에서 가져와야 하는 내장된 애플릿이 포함된 URL에서 페이지가 반환되는 경우가 있습니다. 하지만 Java 보안에서는 애플릿을 다운로드한 호스트가 아닌 호스트와 애플릿이 통신하는 것을 허용하지 않습니다. 애플릿이 로컬 네트워크 포트를 통해 게이트웨이와 통신할 수 있도록 허용하려면 Access Manager 관리 콘솔에서 [애플릿 다운로드] 필드를 선택하고 다음 구문을 지정해야 합니다.

local-port:server-host:server-port

여기서

local-port는 Netlet이 애플릿에서 오는 트래픽을 수신하는 로컬 포트입니다.

server-host는 애플릿을 다운로드하는 위치입니다.

server-port는 애플릿 다운로드에 사용되는 포트입니다.

Netlet 규칙 정의

Netlet 구성은 Portal Server 관리 콘솔에서 Secure Remote Access 구성 탭을 사용하여 구성되는 Netlet 규칙에 의해 정의됩니다. Netlet 규칙은 조직, 역할 또는 사용자용으로 구성할 수 있습니다. Netlet 규칙이 역할이나 사용자용인 경우 조직을 선택한 다음 원하는 역할이나 사용자를 선택합니다.

Netlet 규칙은 멀티바이트 항목을 지원하지 않습니다. Netlet 규칙의 모든 필드에 멀티바이트 문자를 지정하지 마십시오.

Netlet 규칙에는 64000 보다 큰 포트 번호가 포함되면 안됩니다.

Netlet 규칙 정의에는 Netlet 규칙의 필드가 나와 있습니다.

게이트웨이에서 Portal Server의 세션 알림을 수신하려면 다음을 추가합니다.

com.iplanet.am.jassproxy.trustAllServerCerts=true

아래의 등록 정보 파일에 추가합니다.

Portal Server의 /etc/opt/SUNWam/config/AMConfig.instance-name .properties

규칙의 유형

대상 호스트가 어떻게 규칙에 지정되어 있는지에 따라 Netlet 규칙에는 2가지 유형이 있습니다.

정적 규칙

정적 규칙은 대상 호스트를 규칙의 일부로 지정합니다. 정적 규칙을 만드는 경우 사용자는 필요한 대상 호스트를 지정하지 못합니다. 다음 예제에서 sesta는 대상 호스트입니다.

다중 대상 호스트와 포트는 정적 규칙에만 구성할 수 있습니다. 예제는 다중 호스트 연결이 있는 정적 규칙을 참조하십시오.

동적 규칙

동적 규칙에서는 대상 호스트가 규칙의 일부로 지정되지 않으며사용자가 Netlet 공급자에서 필요한 대상 호스트를 지정할 수 있습니다. 다음 예제에서 TARGET은 대상 호스트의 자리 표시자를 말합니다.

암호화 암호

암호화 암호를 기준으로 Netlet 규칙은 다음과 같이 세분화될 수 있습니다.

• 사용자 구성 가능 암호 규칙 - 이 규칙에서 사용자가 선택할 수 있는 암호 목록을 지정할 수 있습니다. 암호 옵션이 Netlet 공급자에 목록으로 나타납니다. 사용자는 목록에서 필요한 암호를 선택할 수 있습니다. 다음 예제에서 사용자는 여러 암호 중에서 선택할 수 있습니다.

Portal Server 호스트에 사용 가능하도록 설정된 다양한 비밀번호가 있을 수도 있으나 사용자는 Netlet 규칙의 일부로 구성된 목록에서만 선택할 수 있습니다.

Netlet에서 지원되는 암호 목록은 지원되는 암호를 참조하십시오.

• 관리자 구성 암호 규칙 - 이 규칙에서는 Netlet 규칙의 일부로 암호를 구성합니다. 사용자는 필요한 암호를 선택할 수 없습니다. 다음 예제에서는 암호가 SSL_RSA_WITH_RC4_128_MD5로 구성되어 있습니다.

Netlet에서 지원되는 암호 목록은 지원되는 암호를 참조하십시오.

지원되는 암호

지원되는 암호에는 Netlet에서 지원되는 암호가 나와 있습니다.

이전 버전과의 호환성

Portal Server의 이전 버전에서는 Netlet 규칙의 일부로 암호를 지원하지 않습니다. 암호가 없는 기존 규칙과의 이전 호환성을 위해 규칙에서는 기본 암호를 사용합니다. 암호가 없는 기존 규칙은 다음과 같습니다.

아래와 같이 해석됩니다.

이는 암호화 암호 필드가 기본값으로 선택된 관리자 구성 규칙과 비슷합니다.

Netlet 규칙에는 64000보다 큰 포트 번호를 포함할 수 없습니다.

Netlet 규칙 예제

이 절에서는 Netlet 구문의 원리를 설명하기 위해 몇 가지 Netlet 규칙의 예제가 나와 있습니다.

• 기본 정적 규칙

• 다중 호스트 연결이 있는 정적 규칙

• URL을 불러오기 위한 동적 규칙

• 애플릿을 다운로드하기 위한 동적 규칙

기본 정적 규칙

이 규칙은 클라이언트에서 컴퓨터 sesta로 가는 Telnet 연결을 지원합니다.

여기서

myrule은 규칙의 이름입니다.

SSL_RSA_WITH_RC4_128_MD5는 사용할 암호를 나타냅니다.

null은 이 응용 프로그램이 URL에 의해 호출되거나 데스크탑을 통해 실행되지 않음을 나타냅니다.

false는 클라이언트가 이 응용 프로그램을 실행하기 위해 애플릿을 다운로드하지 않음을 나타냅니다.

true는 Netlet 연결이 활성 상태인 경우 Portal Server에서 시간 초과가 발생하면 안 됨을 나타냅니다.

1111은 Netlet에서 대상 호스트로부터 오는 연결 요청을 수신하는 클라이언트의 포트입니다.

sesta는 Telnet 연결의 수신자 호스트 이름입니다.

23은 연결에 사용되는 대상 호스트의 포트 번호이며 이 경우에는 Telnet에 잘 알려진 포트입니다.

데스크탑 Netlet 공급자는 링크를 표시하지 않지만 Netlet은 자동으로 시작되어 지정된 포트(1111)에서 수신합니다. 사용자에게 클라이언트 소프트웨어를 시작하라고 지시하십시오. 이 경우에는 포트 1111의 localhost에 연결하는 Telnet 세션을 시작합니다.

예를 들어, Telnet 세션을 시작하려면 클라이언트는 단말기의 UNIX 명령줄에 다음을 입력해야 합니다.

telnet localhost 1111

다중 호스트 연결이 있는 정적 규칙

이 규칙은 클라이언트에서 2대의 컴퓨터 sesta 및 siroe로 가는 Telnet 연결을 지원합니다.

여기서

23은 연결에 사용할 대상 호스트의 포트 번호로, Telnet용으로 예약된 포트입니다.

1111은 Netlet에서 첫 번째 대상 호스트 sesta로부터 오는 연결 요청을 수신하는 클라이언트의 포트입니다.

1234는 Netlet에서 두 번째 대상 호스트 siroe로부터 오는 연결 요청을 수신하는 클라이언트의 포트입니다.

이 규칙의 처음 6개 필드는 기본 정적 규칙에서와 동일합니다. 차이는 두 번째 대상 호스트를 식별하는 3개의 추가 필드가 있다는 점입니다.

규칙에 대상을 추가할 때에는 각각의 새로운 대상 호스트에 local port, destination host 및 destination port 필드를 추가해야 합니다.

각 대상 호스트에 대한 연결을 설명하는 3개의 필드 집합은 여러 개가 있을 수 있습니다. 원격 클라이언트가 UNIX 기반인 경우 번호가 낮은 포트는 제한되고 수신기를 시작할 수 있으려면 루트여야 하므로 2048 보다 작은 수신 포트 번호는 사용하면 안됩니다.

이 규칙은 앞의 규칙과 동일하게 적용됩니다. Netlet 공급자는 어떠한 링크도 표시하지 않지만 Netlet은 자동으로 시작되어 지정된 2개의 포트(1111과 1234)에서 수신합니다. 사용자는 클라이언트 소프트웨어를 시작해야 합니다. 이 경우 포트 1111의 localhost나 포트 1234의 localhost에 연결하는 Telnet 세션을 시작하여 두 번째 예제의 호스트에 연결해야 합니다.

다중 호스트 선택이 가능한 정적 규칙

다중 대체 호스트를 지정하려면 이 규칙을 사용합니다. 첫 번째 호스트에 대한 규칙의 연결이 실패하면 Netlet은 지정된 두 번째 호스트에 연결을 시도합니다.

여기서

10491은 Netlet에서 대상 호스트로부터 오는 연결 요청을 수신하는 클라이언트의 포트입니다.

Netlet은 사용 가능한 포트에 따라 포트 35, 포트 26 및 포트 491에서 같은 순서로 siroe에 연결을 시도합니다.

siroe에 연결할 수 없으면 Netlet은 포트 35 및 491에서 같은 순서로 sesta에 연결을 시도합니다.

호스트 사이의 더하기(+) 기호는 대체 호스트를 나타냅니다.

포트 번호 사이의 플러스(+) 기호는 한 대상 호스트에 대체 포트가 있음을 나타냅니다.

포트 번호 사이의 마이너스(-) 기호는 여러 대상 호스트의 포트 번호를 구분하는 기호입니다.

체인에서 제공되는 호스트 연결은 순서대로 연결 시도됩니다. 예를 들어, 규칙이 siroe+ sesta이면 siroe에 대한 연결을 먼저 시도합니다. 연결이 실패하면 sesta에 대한 연결을 시도합니다. 규칙에 먼저 나열된 호스트를 활성 네트워크에서 물리적으로 사용할 수 없는 경우 규칙에서 사용 불가능한 호스트 수가 증가함에 따라 다음 사용 가능 호스트에 연결하는 데 소요되는 시간이 증가합니다.

URL을 불러오기 위한 동적 규칙

이 규칙을 사용하면 사용자가 필요한 대상 호스트를 구성하여 Netlet을 통해 다양한 호스트에 Telnet 연결을 수행할 수 있습니다.

여기서

myrule은 규칙의 이름입니다.

SSL_RSA_WITH_RC4_128_MD5는 사용할 암호를 나타냅니다.

telnet://localhost:30000은 규칙에서 불러오는 URL입니다.

false는 애플릿이 다운로드되지 않음을 나타냅니다.

세션 확장(true)은 Netlet 연결이 활성 상태이면 Portal Server에서 시간 초과가 발생하면 안 됨을 나타냅니다.

30000은 Netlet에서 이 규칙에 대한 연결 요청을 수신하는 클라이언트의 포트입니다.

TARGET은 사용자가 Netlet 공급자를 사용하여 대상 호스트를 구성해야 함을 나타냅니다.

23은 Netlet에서 열린 대상 호스트의 포트 번호이며, 이 경우에는 Telnet에 잘 알려진 포트입니다.

규칙을 추가한 후 Netlet을 실행하려면

이 규칙을 추가한 후 Netlet이 예상대로 실행되도록 하려면 사용자는 몇 가지 단계를 완료해야 합니다. 사용자는 클라이언트 쪽에 다음을 수행해야 합니다.

1. Portal Server 데스크탑의 Netlet 공급자 섹션에서 [편집]을 누릅니다.

   새 Netlet 규칙이 [새 대상 추가] 섹션의 [규칙 이름]에 나열됩니다.

2. 규칙 이름을 선택하고 대상 호스트의 이름을 입력합니다.

3. 변경 사항을 저장합니다.

   새 링크가 Netlet 공급자 섹션에 표시되 있는 상태로 사용자는 데스크탑으로 돌아갑니다.

4. 새 링크를 누릅니다.

   Netlet 규칙에 주어진 URL로 이동하는 새 브라우저가 시작됩니다.

   ---

   주 –

   이 단계를 반복하여 같은 규칙에 대상 호스트를 2개 이상 추가할 수 있습니다. 선택된 마지막 링크만 활성화됩니다.

   ---

애플릿을 다운로드하기 위한 동적 규칙

이 규칙은 클라이언트에서 동적 할당된 호스트로의 연결을 정의합니다. 규칙은 애플릿이 있는 서버에서 클라이언트로 GO-Joe 애플릿을 다운로드하게 됩니다.

여기서

gojoe는 규칙의 이름입니다.

SSL_RSA_WITH_RC4_128_MD5는 사용할 암호를 나타냅니다.

예를 들어 /gojoe.html은 애플릿이 있는 HTML 페이지의 경로이고 이 경로는 포털이 배포된 웹 컨테이너의 문서 루트에 상대적인 값이어야 합니다.

8000:server:8080은 포트 8000은 애플릿을 수신하는 클라이언트의 대상 포트임을 나타내며 gojoeserve는 애플릿을 제공하는 서버의 이름이고, 8080은 애플릿을 다운로드할 서버의 포트입니다.

세션 확장(true)은 Netlet 연결이 활성 상태이면 Portal Server에서 시간 초과가 발생하면 안 됨을 나타냅니다.

3399는 Netlet에서 이 유형의 연결 요청을 수신하는 클라이언트의 포트입니다.

TARGET은 사용자가 Netlet 공급자를 사용하여 대상 호스트를 구성해야 함을 나타냅니다.

58은 Netlet에서 열린 대상 호스트의 포트 번호이며, 이 경우에는 GoJoe용 포트입니다. 포트 58은 대상 호스트가 자체 트래픽과 관련하여 수신하는 포트입니다. Netlet은 새 애플릿에서 이 포트로 정보를 전달합니다.

예제 Netlet 규칙

예제 Netlet 규칙에는 일부 공통 응용 프로그램에 대한 예제 Netlet 규칙이 나와 있습니다.

이 표에는 Netlet 규칙의규칙 이름, URL, 애플릿 다운로드, 로컬 포트, 대상 호스트, 대상 포트 필드에 해당하는 7개 열이 있습니다. 마지막 열에는 규칙에 대한 설명이 나와 있습니다.

예제 Netlet 규칙에는 Netlet 규칙의 암호 및 세션 확장 필드는 나와 있지 않습니다. 제시된 예제에 대해 이 필드 값을 "SSL_RSA_WITH_RC4_128_MD5" 및 "true"라고 가정하십시오.

Netlet 로깅 정보

Netlet 애플릿 또는 jws의 클라이언트쪽 로그는 해당 클라이언트의 Java 콘솔에 표시됩니다.

Netlet의 서버쪽 로그는 /var/opt/SUNWportal/portals/<portal_ID>/logs/<INSTANCE_ID> 디렉토리의 portal.0.0.log 파일에 저장됩니다.

Sun Ray 환경에서 Netlet 실행

Sun Ray 환경에 있는 클라이언트 컴퓨터에 애플릿을 다운로드해야 하는 응용 프로그램을 실행하려면 HTML 파일을 변경해야 합니다. 다음은 필요한 수정 사항을 보여주는 예제 파일입니다.

새로운 HTML 파일

<!-- @(#)citrix_start.html 2.1
98/08/17 Copyright (c) 1998 i-Planet, Inc., All rights reserved.-->
<html>
<script language="JavaScript">
var KEY_VALUES;  // KEY_VALUES[\qkey\q] = \qvalue\q;
function retrieveKeyValues() {
      KEY_VALUES = new Object();
      var queryString  = \q\q + this.location;
      queryString = unescape(queryString);
      queryString = queryString.substring((queryString.indexOf(\q?\q)) + 1);
      if (queryString.length < 1) {
          return false; }
      var keypairs = new Object();
      var numKP = 0;
      while (queryString.indexOf(\q&\q) > -1) {
        keypairs[numKP] = queryString.substring(0,queryString.indexOf(\q&\q));
        queryString = queryString.substring((queryString.indexOf(\q&\q)) + 1);
        numKP++;
      }
      // Store what\qs left in the query string as the final keypairs[] data.
      keypairs[numKP++] = queryString;
      var keyName;
      var keyValue;
      for (var i=0; i < numKP; ++i) {
        keyName = keypairs[i].substring(0,keypairs[i].indexOf(\q=\q));
        keyValue = keypairs[i].substring((keypairs[i].indexOf(\q=\q)) + 1);
        while (keyValue.indexOf(\q+\q) > -1) {
          keyValue = keyValue.substring(0,keyValue.indexOf(\q+\q)) + \q \q
           + keyValue.substring(keyValue.indexOf(\q+\q) + 1);

        }
        keyValue = unescape(keyValue);
          // Unescape non-alphanumerics
        KEY_VALUES[keyName] = keyValue;
      }
}
function getClientPort(serverPort) {
    var keyName = "clientPort[\q" + serverPort +"\q]";
    return KEY_VALUES[keyName];
}
function generateContent() {
    retrieveKeyValues();
    var newContent =
        "<html>\\n"
          + "<head></head>\\n"
          + "<body>\\n"
          + "<applet code=\\"com.citrix.JICA.class\\" archive=\\
               "JICAEngN.jar\\" width=800 height=600>\\n"
          + "<param name=\\"cabbase\\" value=\\"JICAEngM.cab\\">\\n"
          + "<param name=\\"address\\" value=\\"localhost\\">\\n"
          + "<param name=ICAPortNumber value="
          + getClientPort(\q1494\q)
          + ">\\n"
          + "</applet>\\n"
          + "</body>\\n"
          + "</html>\\n";
    document.write(newContent);
}
</script>
<body onLoad="generateContent();">
</body>
</html>

지원되지 않는 HTML 파일

<html>
<body>
<applet code="com.citrix.JICA.class" archive=
   "JICAEngN.jar" width=800 height=600>
<param name="cabbase" value="JICAEngM.cab">
<param name="address" value="localhost">
<param name=ICAPortNumber value=1494>
</applet>
</body></html>