Java EE Custom Authentication - j_security_check / j_username / j_password

Java EE 提供了 JSP/Servlet此種 Web Programming Model

在認證/授權 (AA, Authentication & Authorization) 的部分，係透過 Deployment Descriptor 採用宣告式的安全設定(Declarative Security)

然而，在Java EE 的規範當中，儘規範了如何定義角色、如何限制相關的功能(URL)可被何種角色存取

而沒有規範到實際的認證、授權如何進行? 使用者的帳號、密碼、角色 是存在哪裡 ?

實際的使用者資料庫(User Registry)是使用 DB? LDAP? File? OS? 哪一種...

在做 JSP 的 form authentication 時, 我們知道 login 頁面要有一個 form action 為 j_seurity_check, 帳號/密碼欄位名為 j_username、j_password，但是 開發人員不必做任何事情，Java EE Container 即會幫你完成後續的認證/授權相關事宜

實際上，因為Java EE沒有規範Container要如何實作認證授權，所以 每個Container所用的 User Registry可能都不一樣。如，Apache Tomcat 預設就是透過 tomcat-users.xml 這個檔案來儲存使用者的帳號、密碼。

有時候，我們已經有既有的 User Registry 或是 想要自已客製化實作認證/授權時，這時候，就要用到Container 提供的 Custom Registry 機制，來加以客制化。同樣的，因為此段在Java EE沒有規範到，所以是依各Container 的不同，而有不同的作法 (亦即，使用 Custom Registry的Application, 在更換Container時，可能有可攜性的問題要處理，需依新的Container的規定，額外實做Custom Registry的功能)

以 Tomcat 為例，預設是使用 「UserDatabaseRealm」(註: 所謂的Realm, 即用在儲存使用者認證/授權資訊的儲存庫, 即 前述的 User Registry)，我們可以在 $CATALINA_BASE/conf/server.xml 此檔案裡，看到相關的宣告:

<resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml">

<realm classname="org.apache.catalina.realm.UserDatabaseRealm" resourcename="UserDatabase">

在Tomcat中，若要自訂其它種User Registry，可以參考官方的說明文件，基本上，它提供了六種管道:

- JDBCRealm
- DataSourceRealm
- JNDIRealm
- UserDatabaseRealm
- MemoryRealm
- JAASRealm

在 WebSphere 中，則是在Container透過 Custom Registry的設定，提供了LDAP、OS 及 自訂三種方法
在使用者自訂Registry的部分，只要實作 com.ibm.websphere.security.UserRegistry 這個介面，並在Container的設定中使用自行實作的 UserRegistry Class 即可~

閱讀全文...

如何自動回收 IIS 的 Application Pool

在IIS6 中，ASP.NET default 是跑在 worker process isolation mode

即，我們可以透過 Application Pool 的設定，讓不同的 ASP.NET 應用程式，跑在不同的 application pool中，由不同的 worker process 來處理，這樣的做法，可以避免將一個雞蛋放在同一個籠子裡，讓表現異常的應用程式，沒法影響到在其它Application Pool 中的程式

談到「異常」的應用程式...

有些人寫出來的APP就是莫明奇妙會掛點、Hang住、出問題~
積極的處理方式是做完整的測試、Code Review將問題查出並修正
消極的處理方式則是進行 IIS重啟(iisreset) 或 Application Pool Recycle(應用程式集區回收)，看看有沒有辦法恢復正常

因使用IIS重啟是整個IIS都會被影響到，所以 可以就發生問題的Application Pool 進行回收 以降低影響範圍

Application Pool Recycle 這種被動的方式，除了可透過application pool 設定進行定期的回收外:


有時，我們可能想要透過一監測程式，在監測到有異常時，才執行application pool 回收
更甚者，我們可能在一台主機監測，而需要回收遠端主機的 application pool...

此時，主要可透過兩種方式來達成:

A. 透過 WMI 的方式, 我有 google 到下列的方式，但未試做:
http://gallery.technet.microsoft.com/ScriptCenter/en-us/22b10d93-e734-4fda-8ebe-2df30e54c64b
http://www.vistax64.com/powershell/103705-remote-application-pool-recycle-using-wmi-powershell.html
http://forums.iis.net/p/1033115/1421721.aspx

B. 透過 IIS 主機內建的 c:\windows\system32\iisapp.vbs 此 script，並搭配如 psexec 此類的遠端執行shell 指命的tool, 來達成:

iisapp.vbs 用法:

C:\>cscript c:\windows\system32\iisapp.vbs /a {ApplicationPoolName} /r

搭配 psexec 在 C# 程式中，可以用這種方式來達成遠端回收 application pool的效果:

Process process = new Process();
process.StartInfo.FileName = @"D:\PsTools\psexec.exe";
process.StartInfo.Arguments = @"\\{原端主機IP} -u {帳號} -p {密碼} cscript c:\windows\system32\iisapp.vbs /a {要回收的application pool name} /r";
process.StartInfo.UseShellExecute = false;
process.StartInfo.RedirectStandardOutput = true;
process.Start();
process.WaitForExit();

psexec 為 PsTools 內的一項utility，可在此下載

閱讀全文...

Axis2 與 .Net 1.1 Web Services 互通性問題

最近在實驗 Java Client to .Net Web Services 的互通性

Java 的部分，是使用 Apache 的 Axis 2

當我用 Axis 2 呼叫用 VS 2003 開發出來的 .Net 1.1 Web Services 時，總是會出現

Exception in thread "main" org.apache.axis2.AxisFault: Transport error: 404 Error: Not Found

百思不得其解，但使用 Axis 1 時，卻可正常呼叫

透過 WireShark 查知，Axis 2 在用 Http 傳送封包時，Transfer-Encoding 預設係使用 Http 1.1 規範裡新增的 Chunked Encoding 方式傳遞(HTTP Header -> Transfer-Encoding: chunked)，而 Axis 1 則不使用 Chunked Encoding

因此，第一直覺，猜想是不是 IIS 的 metabase 設定中 ( C:\WINDOWS\system32\inetsrv\MetaBase.xml)AspEnableChunkedEncoding 這個設定值設成 FALSE 了? (Default 是 TRUE)

但 check 了一下，發現 IIS 有 enable Chunked Encoding

因此，就懷疑是不是 .Net Web Services 不直援 HTTP Chunked Encoding ?? 與用來開發的 .Net 版本有沒有關 ??

所以，就分別使用 VS 2003, 2005, 2008, 2010 製做 Web Services 來實驗

結果發現 不管 IIS 的 AspEnableChunkedEncoding 設定為何
VS 2003 開發出的 Web Services 是不能透過 Chunked Encoding 方式呼叫的
而 VS 2005 以上的版本開發出的 Web Services 則無此限制

因此，若使用 Axis 2 呼叫用 VS 2003 開發出的 Web Services 時，可以調整 Axis 2 呼叫時的參數，以正常呼叫 Web Services, 如下例(註: 我是使用 Axis2 預設的 "ADB Binding" -> XML to Object 的Binding方法啦):

Service1Stub stub = new Service1Stub(); stub._getServiceClient().getOptions().setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE);
Service1Stub.HelloWorld hello = new Service1Stub.HelloWorld();
hello.setName("test");
System.out.println(stub.helloWorld(hello).getHelloWorldResult());

(註: 用 Eclipse 產生 Axis Web Services Client Project 時，目前預設是走 Axis 1, 若用 Axis2 附的 WSDL2Java 來產生 Web Services Stub 的話，則是走 Axis 2)

P.S. 這是我測試的結果啦~ 若大家有其它經驗 請再跟我分享 :)

閱讀全文...

Metaphor: Pig & Chicken

在Scrum裡面有用到一個 pig & chicken 的隱喻 來說明 project 內的參與者

pig - 指的是犧牲、奉獻並對project最終成敗負責的相關角色

chicken - 指的是project的參與者，不必負最終成敗的相關角色

還有 rooster / gamecock 的角色(鬥雞)，這些人 光放屁 提出的意見對project的產出有負效果

--

以下是這個metaphor 的緣由

A number of roles are defined in Scrum. All roles fall into two distinct groups—pigs and chickens—based on the nature of their involvement in the development process. These groups get their names from a joke about a pig and a chicken opening a restaurant:[5]

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.”

So the “pigs” are committed to building software regularly and frequently, while everyone else is a “chicken”—interested in the project but really indifferent because if it fails they’re not the pigs—that is, they weren’t the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but are not in any way allowed to affect, distort or get in the way of the actual Scrum project.

ref: wiki Scrum

閱讀全文...

Notes: ASP.NET Diagnostics

1. Perfmon - windows 內建的 performance monitor

2. IIS Log + Log Parser -> 分析執行時間過長網頁
a. 加入 time-taken log 欄位
b. 安裝 Log Parser, 下 query 統計查詢:

logparser "select top 10 cs-uri-stem, time-taken from ex071105.log group by cs-uri-stem order by time-taken desc" -q:on

3. 安裝微軟 Debug Diagnostic Tool v1.1
a. 可透過 wizard 設定要監控的網址及效能門檻植，並在超過門檻時 進行相關process 的 memory dump, 並透過該工具內建的script 進行分析以產生報表 (可 check memory leak, application hang的問題)
b. 可自製 Debug Diagnostic Service 使用的 script ( C:\Program Files\DebugDiag\Scripts\DbgSvc.vbs) 來自定 trigger core dump 的時機，如 當 Performance Counter 中的 Request Execution Time 超過一定時限時，trigger core dump )，範例可見 C:\Program Files\DebugDiag\Samples\ControlScripts\PerfTriggers\ASPNETExecutionTime\DbgSvc.vbs

ref: http://blogs.msdn.com/debugdiag/

4. 透過 request based tracing

How to Trace Requests for a Specific URL or Set of URLs (IIS 6.0)
How to Create a Provider File for Request-Based Tracing (IIS 6.0)
How to Process and View Trace Log Files (IIS 6.0)

閱讀全文...

XML element 與 attribute 的使用時機 (元素 v.s. 屬性)

基本上 XML 的標準裡面，並沒有說明何時該用 element, 何時該用 attribute
所以，會出現一種狀況，就是資料有多種表示方式，如:
＜person id="123" name="REX"＞＜/person＞ 或
＜person id="123"＞＜name＞REX＜/name＞＜/person＞

下列是看到的兩篇相關文章，各別有建議判斷準則:

1. w3school 中的文章 http://www.w3schools.com/DTD/dtd_el_vs_attr.asp

總而言之，建議 data 放 element, metadata 放 attribute

2. IBM Developerworks 中的文章 http://www.ibm.com/developerworks/xml/library/x-eleatt.html

提到了四類原則:

1. 核心內容原則 (priciple of core content)
屬於主要內容 用來表達所欲傳達資訊時，放在 element
屬於附帶內容或是便於application處理實際的主要內容之用途時，放在 attribute
這個原則，基本上就是 w3school 文章內提到的 data/metadata 的原則

2. 結構化資訊原則 (priciple of structured information)
當資訊必需以結構化方式表示(如, parent/child 的關係) 或結構未來可能會擴充時，使用element
當資訊用最基本方式即可表達時(atomic token)，使用 attribute

3. 可讀性原則 (principle of readability)
當資訊是提供給人時，使用element
當資訊是提供給系統以利處理時，使用attribute

4. 元素/屬性繫結原則 (principle of element/attribute binding)
當資訊會因其它attribute值改變 而必然隨之改變時，使用element
(即, 避免一個attribute的變動 連帶變動另一個attribute的狀況發生, 或可說為 避免 attribute 與 attribute 間有binding的關係)

上述的四個原則，在考量採 element or attribute 時，應一併納入進行總體考量

--
以上~ 希望對各位有幫助

閱讀全文...