balance9235 的部落格

Web2.0=賺錢?

"

網際網路的一切每天都在翻新,就連網際網路到底「互動」到何種程度都有人急欲為它下定義,「Web2.0」這個名詞就這樣熱門起來,從前面的文章讀者已大概知道,它主要是網路演進的一個概念,只是,Web2.0真有好得足以將Web1.0網站經營形式丟在一旁,並且讓所有人為其歌功頌德嗎?事實上,在技術層面上的突破,Web2.0主要集中於表現層,強調其內容不同的組織方式,而在實際應用上,則在指稱其由靜態社群網頁邁向動態個人性網站,最鮮明的例子就是Blog與RSS技術,說穿了只是如何將以前常提到的「個人化」做到更符合人們需求。

[@more@]

所有網際網路經營業者首要目標便是如何從網路服務中獲利,透過以RSS技術專看特定範疇資料的瀏覽者,或利用個別Blog內容性質吸引特定讀者,屆時趕緊餵養他們感興趣的廣告,但這樣的作法卻像大海撈針,在原本充滿廣告連結的所謂Web1.0的網頁下,敏銳的消費者常能一眼看穿廣告並視而不見,上述鎖定特定族群的廣告方式對理性的消費者似乎作用也是有限。

另一方面,全球Blog瀰漫,擁有高度讀者關注的屈指可數,而在這些頗負盛名的Blog中,真正能讓讀者在閱讀內容、發表回應之餘,進而點選置入其間的贊助廣告使其獲得長期利潤者,目前為止還未有實際例子。

一個新技術的產生,不必然能取代原有的技術,就像是新媒體的出現從未使任何舊媒體滅失一般,Web2.0也一樣,諸如Blog、RSS、即時通訊軟體等其概念下相關應用的出現,應該以累加的方式思考,如何利用這些新的個人化服務讓原本在Web1.0時代提供的行銷機制更提升其獲利效益,單憑Web2.0的嶄新技術而想成為主要獲利模式,可行性恐怕還有待觀察。

"

Vista第一個漏洞攻擊程式俄國網站現身

"

該概念性驗證攻擊程式鎖定用來啟動及關閉應用程式的微軟CSRSS,影響包Windows 2000、XP、Windows Server 2003,以及Vista。

俄國的駭客論壇近日公布了一漏洞攻擊的概念驗證程式,該漏洞影響微軟四個版本的作業系統,包括Windows 2000、XP、Windows Server 2003,以及最新的Vista,這使得微軟啟動緊急回應程序。

微軟安全回應中心營運經理Mike Reavey證實,該公司正密切偵測這起在俄國駭客論壇公布的攻擊程式,該概念性驗證程式鎖定用來啟動及關閉應用程式的微軟CSRSS(Client-Server Runtime Subsystem)。

駭客只要將一個特定字串透過MessageBox API傳送就能造成記憶體錯誤,並可提昇使用者在作業系統中的權限。

不過,Mike Reavey表示,初步發現駭客若要進行攻擊必須先有進入目標系統的權限,微軟已啟動緊急回應程序,有許多人共同在調查此事並確定其規模以及對微軟客戶的影響。

Mike Reavey指出,雖然他知道此一漏洞影響了Windows Vista,但他仍非常確定Vista是有史以來最安全的視窗作業系統。

現階段尚未有任何的實際攻擊行動傳出,不過微軟已開始督促旗下客戶啟動防火牆,進行所有的安全更新,並部署防毒及防間諜程式保護措施。

由於該漏洞攻擊必須先登入系統或取得進入企業網路權限,因此資安業者Secunia將其列為低風險等級。eEye將其列為中度威脅,賽門鐵克(Symantec)則將該漏洞歸類為權限提昇漏洞,該類型的漏洞通常被該公司列為低風險漏洞。

但Secunia技術長Thomas Kristensen指出,駭客還是能夠在機器中植入rootkit,並消除在機器中竄改的痕跡,因此還是一個值得IT管理人員注意的重要漏洞。

(編譯/陳曉莉)

http://www.ithome.com.tw/itadm/article.php?c=41220"

JSP 內幕大剖析:JavaServer Pages 簡介

"第一部份:JSP 專案開發所需技術概觀
目前而言,最熱門的網站技術之一,要算是JavaServer Pages(JSP)了。JSP 是以 Java 程式語言為基礎的網站伺服器描述語言程式,可用來建構網站。很多人都想在這個重要的程式語言發展平台上成為專家。這篇專欄的目的,就是要在你的 JSP 自訓過程中,助你一臂之力。我們的目的並不是在教你 JSP,而是在於提供給你如何成功的學習 JSP 的概念,以及告訴你,一個專業的 JSP 開發人員所需的技巧。
學習 JSP 可以是簡單,但同時也可以是複雜的事情。原因在於,JSP 並不是傳統的程式語言。學習 JSP 的基本概念可以在短短的一個禮拜的訓練之內完成。然而,要成為一個成功的 JSP 程式工程師,你還得要學習很多其他的技術。了解這些各式各樣的技術,以及這些技術之間如何互相結合,是學習 JSP 困難的地方。

如果你剛開始接觸 JSP,你很容易被那個長長的技術名單給嚇到。不過,請記住,那些必要的技術都很容易學。難就難在要在同一時間內把它們都學起來。因此,不要被 JSP 嚇到,相反的,你應該運用以下兩個訣竅:

按部就班依序學習,不要一次就想把所有的東西都學起來。許多人犯下的錯誤便是急著要一次把所有的東西都學起來。下面我們會列出學習 JSP 的過程中所會涵蓋到的技術課題。然後,在這個文章系列的第二部分裡面,我們會提供給你一個學習 JSP 的邏輯順序。
將幾個程式設計師組成一個 JSP 專案小組,每個人一次只負責學習幾套技術。如此一來,整個專案小組就能以合理的速度學習 JSP。然後,過些時候,每個人輪流學習新的一套技術。這樣一方面可以讓專案有合理的進度,另一方面又可以讓每個人都學到應有的技術。

JSP 相關技術
一個 JSP 專案所需的技術包括以下所列:

Java
使 用 JSP 時,一個程式設計師免不了要接觸 Java 程式語言。JSP 本身是以一套 Java 物件所寫成的。更重要的是,JSP 的內建描述語言就是 Java。總得來說,一個 JSP 程式設計師一定要懂得 Java 的基本技巧。我建議一個程式設計師在接觸 JSP 之前,至少必須有一個月紮實的 Java 經驗。


HTML / XHTML
不管你如何看待 JSP,你的資料輸出中,至少有百分之九十五會是HTML 檔案。因此,要想成為一個 JSP 程式設計師,你必須要對 HTML 完全了解。我建議在你考慮學習 JSP 以前,必須要先有至少一個月 HTML / XHTML 的經驗。


了解網頁伺服器
因為 JSP 是用來建構網站的,因此就某一個時點來說,對於你的網站所用的伺服器,你也必須略知一二。一個網頁伺服器是用來處理 HTML 網頁的, 通常它必須與其他軟體合作,共同處理 JSP 檔案。談到這裡,我們不得不談到下一個與 JSP 有關的難題。


了解實際運作處理 JSP 的 Container
Container 通常也被稱為 JSP 伺服器。這是用來將某個 JSP 的回詢(request)做解析處理,然後將其結果回傳給那個發出 JSP 回詢的網路用戶的一個軟體。這個 Container 很像一個網頁伺服器,只不過它並不是用來處理 HTML 網頁,而是用來處理 JSP 檔案。學習這個 JSP Container 的相關細節所需的時間,端賴於你到最後選的是哪一套 Container。有些軟體很簡單而易學。另外一些雖然提供的功能強大, 但是卻必須要有人專責來花時間學習並維護該套軟體。欲知詳情,請參考有關 JSP 工具程式的 FAQ 網頁。


JavaScript
JSP 將所產生的資料傳送給客戶(client),通常就是一個網頁瀏覽器,也就是所謂的「客戶端」。目前大部分的 JSP 輸出結果都是以 HTML 為基調的。JavaScript 是 HTML 使用的描述語言的首選工具。JavaScript 允許程式設計師在客戶端撰寫條件式敘述的邏輯。這表示客戶端減少了與伺服端來回交談的次數, 如此一來提昇了客戶端的效能。另外,JavaScript 也允許程式設計師修改 HTML 頁面顯示的方式,加強了 HTML 的能力。JavaScript 不是 Java。在大多數實用的狀況下,它只在用來觀看 HTML 頁面的瀏覽器上執行。

對於 JavaScript,我們有一點必須澄清,市面上有很多不同版本的 JavaScript,每個版本的名字也不一樣(例如,Microsoft 的 JScript)。雖然 JavaScript 被當作這種描述程式語言的通用名稱,不過新的 JavaScript 標準目前在歐洲是以 ECMAScript 的名字來維護的。因此當有人將 JavaScript 稱為 JScript 或 ECMAScript 的時候,你也不用感到困惑。

學習 JSP
JSP 不是真正的程式語言,而是:

— 一套由 Java 寫成的物件。
— 一個簡單的描述程式語法,用來處理物件與 JSP 集裝軟體之間的溝通過程。

學習 JSP 包括熟悉簡單的描述語言語法以及構成 JSP 標準的 Java 物件。在當一個程式設計師了解 Java 以後,學起 JSP 來就很簡單了。


用 JSP 的邏輯方式思考
JSP 是一個離散式,以網頁為基礎的應用程式(Distributed web-based application)。這表示它的邏輯處理過程是分散在不同的主機上面。大部分的處理過程是發生在 JSP 應用程式所在的主機上。 額外的邏輯處理時間則是花在觀看網頁的客戶端處理 HTML 檔案的上面。很多專案也將處理資料的資料庫伺服器整合進來。較大的專案可能會有一個元件伺服器, 集中處理 Enterprise JavaBean 物件。如果一個網頁應用程式夠大,它的 JSP 中央處理中心很可能散佈在不同的 JSP 伺服器上面。 這在在表示,你必須了解如何將一個 JSP 應用程式的邏輯處理散置在不同的機器上。更重要的是,你必須了解一個結合客戶端以及伺服端邏輯的網站應用程式的雙面性質。 以 JSP 的邏輯方式思考,事實上是一種藝術。

學習 JSP 語法以及物件是基本的第一步。但是要完成你對 JSP 的了解,你還必須再跨出更大的一步來。這包括學習:

— 這不同的元件之間是如何交談而互相合作的,還有
— 這個過程是何時開始,從何處開始的

如何讓一個分散式的應用程式取得平衡是最難學習的一項技術。這就需要有一位具備經驗的良師來加速你的學習過程。否則的話,這個技術的養成需要經過一段長時間的嘗試錯誤的過程。


還有更多的技術
其他開發 JSP 專案所需的技術包括了:

DHTML 以及 串接樣式表

任 何一個我現在架構的網站應用軟體都會用到某些 DHTML(動態 HTML),而我通常用的工具就是串接樣式表(Cascading Style Sheets)。這些工具程式大大的擴展了 HTML 網頁的可能性。它們允許使用者架構網站應用軟體,而所架構的軟體可以模仿客戶端與伺服端的應用程式。我個人覺得運用這些工具程式的技巧已經成為必要的了, 然而,很多簡單的專案還是不會用到這些工具程式。


Servlets

你或許不用學這麼多有關 servlet 的東西。事實上,JSP 就是簡化了的 Servlet。當初 Sun 開發 JSP 時,它的目標就是在於提供 Servlet 大部分強大的功能,並且同時提供一個簡單的寫程式的環境平台。而將 JSP 簡單化的代價,就是失去了些微 Servlet 所能提供的強大功能。 有些時候,你還是會需要寫 Servlet 來做一些比較特別的事情。


J2EE(大型專案使用)

比較大型的 JSP 專案需要功能比較強大的伺服器,以及高度的資源再利用性。這就是當專案需要跨入 Java 2 Enterprise Edition 伺服器解決方案的領域的時候了。一個 J2EE 伺服器可以提供很多 JSP 專案所需要的功能,包括大量資料傳輸所需的功能。J2EE 同時也內定使用 Enterprise JavaBeans,這可以讓我們更能重複使用程式碼。最後,J2EE 伺服器一向比較穩定,支援較好的失效備援(fail-over), 以及其他較高階的功能,像是可以提昇資料存取速度的物件共同管理(Object Pooling)。J2EE 所需的成本較高,而且也需要有經驗比較多的人去維護。

這些技術的重要性
大部分在 JSP 討論區被問到的問題,嚴格說來並不是有關 JSP 的問題。其中大約有三分之二是求助有關 Java,JavaScript,JSP Container,以及 HTML 的問題。在開始一項 JSP 專案之前,先把這些技術學好,你就不會感到氣餒、困惑,也比較不會出錯。到頭來, 也會節省你不少時間跟金錢。

在這篇專欄的下一部份,我們會討論一套訓練時程,幫助你成為專業的 JSP 程式設計師。


建立一套 JSP 自學課程
很 多人都犯了同樣的毛病,那就是把 JSP 誤認為是 Java 程式語言的簡化。其實不是這樣的。(事實上,應該說 JSP 是 Servlet 的簡化。)這個錯誤的結果是,程式設計師們大都只嘗試學習 JSP 而不去學其他相關必要的支援技術。JSP 是一種其他技術的橋樑,而要想成功的運用它,你必須了解橋樑另外一端的技術。這表示,如果你已經知道 Java,HTML 還有 JavaScript,那麼 JSP 會變得很簡單。否則的話,你必須花比別人更多的力氣。

以下這套循序漸進的時程,讓我們了解要想成為一個成功的 JSP 程式設計師所必須具備的條件。這套時程是筆者自己設計的,並在所有的 JSP 網站應用程式訓練中使用。請注意下面事項:

— 跳過任何你已經知道的步驟。
— 訓練所需的時間只包括學習其中足夠的基本技巧,以便能前往下一個步驟。

安裝你的網頁伺服器,並針對你的網頁伺服器做一個初步的了解。

因為 Apache 是免費的,而且在大部分的作業平台都可以用,筆者推薦使用 Apache 當作你訓練自己用的網頁伺服器。安裝時間:兩天。


接著,確定你了解 HTML / XHTML。

你 將需要涵蓋一些基本的技巧,尤其是如何在 HTML 頁面控制項(layout control)上 使用表格(table)。另外,由於 XHTML 即將很快的取代 HTML,所以你不妨也學一些有關 XHTML 的基本事項。在學習 HTML 時,你也要注意建立一個格式嚴謹的文件所必須遵守的規則。很多程式設計師透過 HTML IDE(整合性開發環境平台,Integrated Development Environment)學習 HTML。因為大部分的 HTML IDE 所產生的 HTML 程式碼雜亂無章,完全不遵守 XHTML 的規則,你還是花時間手動建立自己的 HTML 吧!你會發現,所花的時間是值得的。這個步驟很重要,因為你在某些情況下必須使用 JSP 來寫定製的 HTML。所以你必須能夠很流利的撰寫 HTML 程式碼。訓練時間:二到四週。


開始學習 Java。從 Java 1.3 開始。

了 解 Java 程式語言的基本技巧是很重要的。你不用擔心要去學那些什麼 Swing 或其他有關 Java 的圖形元件。你在 JSP 裡面用不到它們。 你應該把注意力集中在學習 Java 語言的邏輯,以及有關 Java 是如何運作的細節上面。另外,你可以再花時間學習 JavaBeans。學習 Applets 是很好,不過,跟 Swing 一樣,很多 JSP 專案不會用到 Applets。學習 Applets 有一個好處,那就是它們提供了一個學習基本的 Java 語言技巧的視覺架構,並同時加強了某些基本的 HTML 技術。訓練時間:三到六週。


學習 JavaScript。

學 習如何建構 JavaScript 函式,以便驗證你的 HTML 的 Form,是個不錯的主意。你也可以研究一下,JavaScript 是如何更動 HTML 網頁裡面的某些元件。最後,再看看 HTML 網頁提供給你哪些事件(Event)以便讓你用來觸發一個 JavaScript 函式。 訓練時間:一到兩週。


檢視並了解你的網頁伺服器的較小的細節。

這個步驟很重要,因為它會讓你對於網頁伺服器的功能有更進一步的了解。訓練時間:兩天。


安裝你的 JSP Container。

我 建議使用 Tomcat 做為開端。它是 JSP Container 的參考執行計劃(reference implementation)。或許你不會在正式的生產環境上使用 Tomcat,但是它畢竟是個穩固的伺服器。再者,很多 JSP 程式設計師使用 Tomcat。當你遇到問題的時候,會比較容易找到人問。安裝時間: 一到兩天。


開始學習 JSP。

學習 JSP 包括將從步驟一到六所學的,應用到 JSP 物件以及程式撰寫上,以建構一個 JSP 頁面。其他有關 JSP 訓練方面是學習如何建構一個分散式應用軟體。 訓練時間:四到六週。


學習更多有關你的 JSP Container。

學 會 JSP 而沒有學很多有關真正解析頁面的 JSP Container,是可能的。不過很多 JSP Container 都提供特有的特殊功能, 了解這些技術對於你 JSP 專案的進行是有幫助的。它值得你花時間致力去研究,你也應該學習那個真正執行你的專案的伺服器裡面的有關知識。這對於如何最佳化你的伺服器, 以讓你的 JSP 程式跑得更快、同時也不會出現問題,是有幫助的。訓練時間:二到七天。


研究/學習 JDBC。

大部分的 JSP 專案都會使用某種形式的資料庫。JDBC 是用來跟資料庫連結用的。每一個 JDBC 驅動程式很可能在它所支援的功能上有所不同。 這件事情通常都會被忽略掉。因此,了解並學習專案所使用的 JDBC 驅動程式就變得很重要。(有時候,這部分的訓練會因專案需要或時程因素而被併到 Java 或 JSP 那個步驟裡面。)訓練時間:一到兩週。
到這裡,我認為大多數人都已經具備身為一個初階的 JSP 程式設計師所應有的專業知識。雖然還有很多要學習的,不過,一個人學到這裡就有紮實的根基, 而可以繼續往下一步前進了。從這個點開始,你可以只專精你的專案所需要學習的領域。另外,你也可以考慮將你的專業知識延伸到 DHTML,XML,certificates, JSP Tag Libraries 以及/或者 Servlets,端看你所架構的網頁伺服器是哪一類型而定。

以上就是一個紮實的 JSP 訓練時程。依照你的專案小組的分散性,以及你已經有的知識而言,你或許不用將所有東西學起來。但是我使用過這個學習時程來訓練程式設計師, 而且相當成功。主要的關鍵在於時間。大致上說來,要真正的從頭到尾訓練一個人,讓其成為一個成功的 JSP 使用者,所需的時間大概是五個月。你可以也應該將一個專案做為你訓練過程的基礎架構。 它能夠提供訓練的焦點,同時也允許專案小組專心於某個特定專案的重要課題。縱使五個月好像很長,這個時程還是不足以讓一個人成為完全成熟的網頁應用工程 師。

如果你認為這個時間實在是太長,而覺得學習 ASP 比較快,我勸你再仔細想想。雖然 ASP 的學習曲線跟 JSP 不一樣,我所用的 ASP 訓練時程跟 JSP 訓練時程比起來其實是大同小異。這項訓練重點是在反映網頁應用程式開發的過程,而非只針對某個特定的程式語言。

在這篇專欄的下一部份,我們會帶你看看某些不錯的網路資源,可以幫助你上手。


網路上 JSP 教學資料的快速簡介
網路上有很多很棒的 JSP 學習資料。在第一節我們會列出一些目前在網路上很熱門的 JSP 教學資料。這些教學資料都是免費的,而且也都提供針對 JSP 的很好的介紹。第二節裡面,我們會提到其他你會覺得有用的網路上的學習資料。

JSP 教學手冊
到目前為止,所有的 JSP 教學手冊都有類似以下的兩個弱點:

對於如何安裝一個 JSP Container,都沒有足夠的細節討論。

沒有任何手冊針對 JSP 應用程式的分散性有足夠深入的討論。
說 句公道話,要在基本的教學手冊中做到以上任何一點是有點難。這些教學手冊有一個共同的目的:提供 JSP 簡短的概觀,同時也提供讀者一個學習過程的起點。 就這方面來說,這些教學手冊都做得很成功。每一個手冊所針對的讀者群都有一點不同,有些程式設計師會有興趣輪流閱讀這些手冊,因為每個手冊都有不同的資 訊。


Servlets and JavaServer Pages (JSP) 1.0: A Tutorial(Marty Hall。1999)是網路上最廣為使用的 JSP 教學手冊之一。它也有一點點過時,因為它是為 JSP 1.0 設計的,而現在 JSP 已經到 1.2 版了。其中影響最大的是 "Getting Started:Software and Server Setup" 這一章,應該完全省略掉,其中提到的集裝軟體已經過時。這個教學手冊會被列在這裡的原因是, 它討論的內容也涵蓋了 Servlet。事實上,這個手冊的前四分之三討論有關 Servlet,而後面四分之一才討論到 JSP。結果是,讀者能夠對於 Servlet 有一個基本的認識,同時也能了解為什麼 JSP 會成為開發網頁應用程式簡單化的一大步。這篇手冊討論 JSP 的章節有一點點匆促,而沒有提供太多的程式範例。 如果你對學習更多有關 Servelt 以及它們與 JSP 的關係有興趣,這是個不錯的教學手冊。如果你只對如何開始使用 JSP 有興趣,那麼你可以選擇這裡所列的其他手冊。


JSP: The Short Course(Ray Carnes 8.26.2000)是 JSP 的快速簡介。這個課程假設你對 JSP 一無所知, 而且對於 Java 或 HTML 也認識不多。它是個簡單而快速的教學手冊。如果你是一個中級或進階的程式設計師,你會發現這本手冊太淺了。如果你是個程式設計的新手, 那麼你會覺得這本手冊是個有關 JSP 的簡單介紹,同時也有很多簡單的範例帶著你走過 JSP 的基本知識。既然這本手冊是為資歷較淺的程式設計師而編的,它並不會深入的提到 JSP 的機制。另一個有關這本手冊的好處是,Mr.Carnes 將這本手冊分章節編寫,而且也在 2001 持續的為這本手冊加入新的東西。


JavaServer Pages Fundamentals's(Govind Seshadri 9.13.2000)這本手冊是一個編寫良好的中級課程。它提供很好的 JSP 概觀,並且也讓你對於 JSP 有紮實的觀念。這本手冊沒有提供太多的程式範例,但是它有一些很不錯的圖表,可以幫助程式設計師了解 JSP 的機制。 在所有的 JSP 教學手冊裡面,這份手冊提供最好的 JSP 快速技術簡介。對程式設計方面的新手而言,這份手冊有兩個弱點。首先,除非你有相當的 Java 基礎,否則它讀起來會有點難。其次,程式範例的解釋不是很夠。總的來說,我會推薦這份教學手冊做為任何想要學習 JSP 的人的起點。


額外的 JSP 學習資源
既然使用 JSP 意味著要有 Java 的基本認識,我們認為應該有必要再給你一個 Java 教學手冊,以免你在研讀 JSP 教學手冊時碰到 Java 的問題。

The Java Tutorial (Sun)是 Sun 本身所出版有關 Java 的教學手冊。它是個教你如何使用 Java 的好書。這份手冊分成幾個學習路線。每一個路線涵蓋不同的課題。 例如,如果你要學習如何為你的 JSP 專案建構 JavaBean 物件,你可以到這裡然後使用 JavaBean 學習路線。另一個有關 Servlet 的學習路線可以在 這裡 找到。Servlet 學習路線非常完整,它讓你對 Servlet 會有初步的了解。不過使用 Servlet 學習路線有一個問題,那就是它有點過時, 而沒有討論到目前的 Servlet 版本。網站上並沒有有關 JSP 的學習路線,不過筆者期待 Sun 會在 2001 年年底前為 JSP 1.2 寫一個。

關於 JSP,有一點是先前的手冊都沒有提到的,就是如何建構一個 Tag Library。事實上,一個基本的 JSP 手冊應該不會提到 Tag Library,這是一個進階的 JSP 課題。這表示,直到你熟悉 JSP 手冊中所提到的基本技巧為止,你不用去看 Tag Library 的教學手冊。


JSP Tag Extensions(Wrox 2000)提供一個有關 Tag Library 的教學手冊,這個手冊其實是 Wrox 出版的書 "Java Server Programming — J2EE Edition" 的第十二章。這本書寫得不錯,而且也很完整。 這本手冊則有很好的範例同時對如何建構一個 JSP Tag Library 也解釋得不錯。它包含所有剛開始學習 Tag Library 時所涵蓋的所有東西。


最後,JSP Product Page (Sun)是 JSP 產品的官方網站,你可以在這裡找到正式的官方文件以及有關 JSP 的統計資料。

"

ASP、JSP、PHP 三種技術比較

"目前,最常用的三種動態網頁語言有ASP(Active Server Pages),JSP(JavaServer Pages),PHP (Hypertext Preprocessor)。現在,我們來做個比較。

簡 介

  ASP全名Active Server Pages,是一個WEB伺服器端的開發環境,利用它可以產生和執行動態的、互動的、高性能的WEB服務應用程式。ASP採用腳本語言VBScript(Java script)作為自己的開發語言。

   PHP是一種跨平台的伺服器端的嵌入式腳本語言。它大量地借用C,Java和Perl語言的語法, 並耦合PHP自己的特性,使WEB開發者能夠快速地寫出動態產生頁面。它支援目前絕大多數資料庫。還有一點,PHP是完全免費的,不用花錢,你可以從 PHP官方站點(http: //www.php.net)自由下載。而且你可以不受限制地獲得源碼,甚至可以從中加進你自己需要的特色。

   JSP是Sun公司推出的新一代網站開發語言,Sun公司借助自己在Java上的不凡造詣,將Java從Java應用程式和Java Applet之外,又有新的碩果,就是JSP,Java Server Page。JSP可以在Serverlet和JavaBean的支援下,完成功能強大的站點程式。

   三者都提供在 HTML代碼中混合某種程式代碼、由語言引擎解釋執行程式代碼的能力。但JSP代碼被編譯成 Servlet並由Java虛擬機解釋執行,這種編譯操作僅在對JSP頁面的第一次請求時發生。在ASP 、PHP、JSP環境下,HTML代碼主要負責描述資訊的顯示樣式,而程式代碼則用來描述處理邏輯。普通的 HTML頁面只依賴於Web伺服器,而ASP 、PHP、JSP頁面需要附加的語言引擎分析和執行程式代碼。程式代碼的執行結果被重新嵌入到HTML代碼中,然後一起發送給瀏覽器。ASP 、PHP、JSP三者都是面向Web伺服器的技術,用戶端瀏覽器不需要任何附加的軟體支援。

技術特點

ASP:

1. 使用VBScript 、 JScript等簡單易懂的腳本語言,結合HTML代碼,即可快速地完成網站的應用程式。

2. 無須compile編譯,容易編寫,可在伺服器端直接執行。

3. 使用普通的文本編輯器,如Windows的記事本,即可進行編輯設計。

4. 與瀏覽器無關(Browser Independence), 用戶端只要使用可執行HTML碼的瀏覽器,即可瀏覽Active Server Pages所設計的網頁內容。Active ServerPages 所使用的腳本語言(VBScript 、 Jscript)均在WEB伺服器端執行,用戶端的瀏覽器不需要能夠執行這些腳本語言。

5.Active Server Pages能與任何ActiveX scripting語言相容。除了可使用VB Script或JScript語言來設計外,還通過plug-in的方式,使用由第三方所提供的其他腳本語言,譬如REXX 、Perl 、Tcl等。腳本引擎是處理腳本程式的COM(Component Object Model) 物件。

6. 可使用伺服器端的腳本來產生用戶端的腳本。

7. ActiveX Server Components(ActiveX 伺服器元件 )具有無限可擴充性。可以使用Visual Basic 、Java 、Visual C++ 、COBOL等程式設計語言來編寫你所需要的ActiveX Server Component 。

PHP:

1·資料庫連接

PHP 可以編譯成具有與許多資料庫相連接的函數。PHP與MySQL是現在絕佳的群組合。你還可以自己編寫外圍的函數去間接存取資料庫。通過這樣的途徑當你更換 使用的資料庫時,可以輕鬆地修改編碼以適應這樣的變化。PHPLIB就是最常用的可以提供一般事務需要的一系列基庫。但PHP提供的資料庫接口支援彼此不 統一,比如對Oracle, MySQL,Sybase的接口,彼此都不一樣。這也是PHP的一個弱點。
 

JSP:

1·將內容的產生和顯示進行分離

使 用JSP技術,Web頁面開發人員可以使用HTML或者XML標識來設計和格式化最終頁面。使用JSP標識或者小腳本來產生頁面上的動態內容。產生內容的 邏輯被封裝在標識和JavaBeans群組件中,並且綑綁在小腳本中,所有的腳本在伺服器端執行。如果核心邏輯被封裝在標識和Beans中,那麼其他人, 如Web管理人員和頁面設計者,能夠編輯和使用JSP頁面,而不影響內容的產生。在伺服器端,JSP引擎解釋JSP標識,產生所請求的內容(例如,通過存 取JavaBeans群組件,使用JDBC技術存取資料庫),並且將結果以HTML(或者XML)頁面的形式發送回瀏覽器。這有助於作者保護自己的代碼, 而又保證任何基於HTML的Web瀏覽器的完全可用性。

2·強調可重用的群組件

絕大多數JSP頁面依賴於 可重用且跨平台的元件(如:JavaBeans或者Enterprise JavaBeans)來執行應用程式所要求的更為複雜的處理。開發人員能夠共享和交換執行普通操作的元件,或者使得這些元件為更多的使用者或者用戶團體所 使用。基於元件的方法加速了總體開發過程,並且使得各種群組織在他們現有的技能和優化結果的開發努力中得到平衡。

3·採用標識簡化頁面開發


Web 頁面開發人員不會都是熟悉腳本語言的程式設計人員。JavaServer Page技術封裝了許多功能,這些功能是在易用的、與JSP相關的XML標識中進行動態內容產生所需要的。標準的JSP標識能夠存取和實例化 JavaBeans元件,設定或者檢索群組件屬性,下載Applet,以及執行用其他方法更難於編碼和耗時的功能。
通過開發定制化標識庫,JSP技術是可以擴展的。今後,第三方開發人員和其他人員可以為常用功能建立自己的標識庫。這使得Web頁面開發人員能夠使用熟悉的工具和如同標識一樣的執行特定功能的構件來工作。

JSP技術很容易整合到多種應用體系結構中,以利用現存的工具和技巧,並且擴展到能夠支援企業級的分散式應用。作為採用Java技術家族的一部分,以及Java 2EE的一個成員,JSP技術能夠支援高度複雜的基於Web的應用。

由於JSP頁面的內置腳本語言是基於Java程式設計語言的,而且所有的JSP頁面都被編譯成為Java Servlet,JSP頁面就具有Java技術的所有好處,包括健壯的存儲管理和安全性。

作為Java平台的一部分,JSP擁有Java程式設計語言“一次編寫,各處執行”的特點。隨著越來越多的供應商將JSP支援加入到他們的產品中,您可以使用自己所選擇的伺服器和工具,修改工具或伺服器並不影響目前的應用。


應用範圍

ASP 是Microsoft開發的動態網頁語言,也繼承了微軟產品的一貫傳統,只能執行於微軟的伺服器產品,IIS(Internet Information Server) (windows NT)和PWS(Personal Web Server)(windows 98)上。Unix下也有ChiliSoft的元件來支援ASP,但是ASP本身的功能有限,必須通過ASP+COM的群組合來擴充,Unix下的COM 實現起來非常困難。

PHP3可在Windows,Unix,Linux的Web伺服器上正常執行,還支援IIS,Apache等一般的Web伺服器,用戶更換平台時,無需變換PHP3代碼,可即拿即用。

JSP 同PHP3類似,幾乎可以執行於所有平台。如Win NT,Linux,Unix。在NT下IIS通過一個外加伺服器,例如JRUN或者ServletExec,就能支援JSP。知名的Web伺服器 Apache已經能夠支援JSP。由於Apache廣泛應用在NT、Unix和Linux上,因此JSP有更廣泛的執行平台。雖然現在NT作業系統佔了很 大的市場份額,但是在伺服器方面Unix的優勢仍然很大,而新崛起的Linux更是來勢不小。從一個平台移植到另外一個平台,JSP和JavaBean甚 至不用重新編譯,因為Java位元組碼都是標準的與平台無關的。

性能比較

有人做過試驗,對這三種語言分別做回圈性能測試及存取Oracle資料庫測試。

在迴圈性能測試中,JSP只用了令人吃驚的四秒鐘就結束了20000*20000的回圈。而ASP、PHP測試的是2000*2000迴圈(少一個數量級),卻分別用了63秒和84秒。(參考PHPLIB)。

資料庫測試中,三者分別對 Oracle 8 進行 1000 次 Insert,Update,Select和Delete: JSP 需要 13 秒,PHP 需要 69 秒,ASP則 需要 73 秒。

前景分析   

目前在國內PHP與ASP應用最為廣泛。而JSP由於是一種較新的技術,國內採用的較少。但在國外,JSP已經是比較流行的一種技術,尤其是電子商務類的網站,多採用JSP。

採 用PHP的網站如新浪網(sina)、中國人(Chinaren)等,但由於PHP本身存在的一些缺點,使得它不適合應用於大型電子商務站點,而更適合一 些小型的商業站點。首先,PHP缺乏規模支援。其次,缺乏多層結構支援。對於大負荷站點,解決方法只有一個:分布計算。資料庫、應用邏輯層、表示邏輯層彼 此分開,而且同層也可以根據流量分開,群組成二維陣列。而PHP則缺乏這種支援。還有上面提到過的一點,PHP提供的資料庫接口支援不統一,這就使得它不 適合運用在電子商務中。

ASP和JSP則沒有以上缺陷,ASP可以通過Microsoft Windowsd的COM/DCOM獲得ActiveX規模支援,通過DCOM和Transcation Server獲得結構支援;JSP可以通過SUN Java的Java Class和EJB獲得規模支援,通過EJB/CORBA以及眾多廠商的Application Server獲得結構支援。

三者中, JSP應該是未來發展的趨勢。世界上一些大的電子商務解決方案提供商都採用JSP/Servlet。比較出名的如IBM的E-business,它的核心 是採用JSP/Servlet的Web Sphere。它們都是通過CGI來提供支援的。但去年10月後它推出了Enfinity,一個採用JSP/Servlet的電子商務 Application Server,而且聲言不再開發傳統軟體。

總之,ASP,PHP,JSP三者都有相當數量的支援者,由此也可以看出三者各有所長。正在學習或使用動態頁面的朋友可根據三者的特點選擇一種適合自己的語言。         (本文源自大陸作者王健 http://www.chinahightech.com/2000_7_19/jishuzhuanti/text1.htm ) "

「SQL警戒病毒」讓台灣進入「藍色警戒」戒備狀態

"趨勢科技在上週末(25日)針對「SQL 警戒病毒」WORM_SQLP1434.A.發佈高度風險警訊之後,今天再度對所有用戶提出叮嚀,請密切注意此病毒後續動向。上週末開始,世界各地包括美國、大陸、韓國、日本、台灣都陸續傳出災情,週一上班日,不論是ISP、大型企業、中小型企業,都紛紛展開救災行動,而據悉,國外災情也不輕,對此,中外政府都密切,嚴陣以待。
[@more@]繼前年2001年讓人餘悸猶存的紅色警戒病毒之後,上週末再度出現的這隻「SQL警戒病毒」,其危害行徑類似當時的紅色警戒,甚至有凌駕於其上之虞。一經趨勢科技TrendLabs 24小時病毒防治中心發現後,便立刻向全球發佈紅色警戒,提醒世界各地客戶密切注意此病毒動向。而台灣方面,此病毒動向目前甚至也已經引起國內政府機構的關注,國家資通會報昨日還特別發佈所謂「藍色警戒」,由資安會報技術服務中心隨即廿四小時待命,並與由行政院主計處成立的緊急應變中心聯繫,嚴密監控國內可能發生的災情。此外,「SQL警戒必病毒」同時也引起國內外各大媒體注意報導,其中包括美國CNN、日本朝日新聞等,都以大篇幅報導可見一般。全球一片如臨大敵,嚴陣以待。儘管如此,在此病毒的擾亂下,目前總計全球仍傳出已經有上萬台主機遭到毒手,進入停擺狀況。

  而台灣地區,雖然是週末假日期間,趨勢科技立刻全體動員,以最快的速度將病毒警戒訊息傳遞給所有客戶,雖然趨勢科技人員犧牲假期,但所幸病毒爆發於週末假日,所以多數大型客戶一來由於資料庫暫停運作,一來由於有專門處理IT事務人員,所以災情並未擴大。但今日週一上班後,仍舊有不少中小企業客戶由於多數沒有專職IT人員處理,所以有不少因為受到危害,發出求助訊息。在此趨勢科技再次呼籲客戶,不論是大型客戶或是中小企業主,請立即至微軟網站下載更新SQL 2000 Service Pack3。以避免伺服器成為此次病毒擴散的跳板。

  趨勢科技更進一步指出,由於此病毒專找SQL Server下手,所以建議用戶採用TMCM (Trend Micro Control Manager)下載OPP(Outbreak Prevention Policy)去封鎖Port 1434,並且立刻上微軟網站下列網址下載更新SQL 2000 Service Pack3。另外,雖然WORM_SQLP1434.A.「SQL警戒病毒」目前看起來並不會對個人用戶造成影響,但趨勢科技還是要提醒用戶,個人電腦仍有可能成為駭客中繼站,為避免成為駭客跳板,請大家立刻上雅虎奇摩、Seednet、Hinet 等網站使用HouseCall線上掃毒,確保個人電腦安全。

  根據趨勢科技TrendLabs指出,這隻病毒未來極有可能會有相關變種病毒出現,趨勢科技提醒用戶最好小心為是,請務必至微軟網站下載最新的病毒碼,並依以下解決途徑:

解決方法:
1.至微軟網站下載更新SQL 2000 Service Pack 3才能有效根除.
http://www.microsoft.com/sql/downloads/2000/sp3.asp
2.如果己經中這支病毒請下載趨勢科技最新清除程式System Cleaner Package以便清除此病毒.
http://www.trendmicro.com/download/tsc.asp
3.重新啟動電腦以便套用這些修正程式,即可清除此病毒.
4.建議採用TMCM (Trend Micro Control Manager)設定OPP(Outbreak Prevention Policy)去封鎖Port 1434可防止病毒擴散. 
5.建議由防火牆或趨勢科技的GateLock寬頻保全上封鎖UDP Port 1434,以防止由外部對SQL Server的攻擊.

相關網站:
趨勢科技 http://www.trendmicro.com.tw/

關於趨勢科技:
趨勢科技1988年成立於美國加州,成功跨入國際舞台,行銷全世界,提供企業資訊安全全方位解決方案。趨勢科技近來已成功轉型為服務顧問導向公司,積極提升客戶服務績效與素質,卓越的服務績效榮獲 2002 年由Accenture及天下雜誌主辦的「卓越服務獎」。趨勢科技針對企業安全更提出 EPS (Enterprise Protection Strategy)企業安全防趨勢護策略,帶領客戶進入不用等待病毒碼,也可以主動防禦的時代。趨勢科技目前全球有1800名員工,包含亞洲、美國、南美洲和歐洲皆設有據點,目前在美國Nasdaq(TMIC)及日本東京證交所第一部(4704)皆正式掛牌,且市值持續成長,為全球名列前茅的網際網路公司。

"

上網大調查

"

一份2004-2006年進行的調查,當中詢問民眾過去一個月的上網經驗,發現台灣10歲以上的上網人口,已在2005年突破5成,衝破千萬大關; 2006年高達1185.6萬,上網率接近6成59.1%。顯示網路媒體的使用已漸漸深入台灣民眾的生活當中。

[@more@]

進一步以網路使用程度進行分析,發現就整體而言,台灣的上網人口不但具有日漸普及的趨勢,過去一日曾經使用網路者比例也屢創新高。受訪民眾中表示過去一日曾經上網者,從2004年的36.1%已提升至42.5%。顯示台灣民眾網路依賴程度亦日漸提升。

隨著網路使用的普及,2004-2006年間,各年齡層之網路接觸率亦越顯提升。使用程度最高的年齡層為20-29歲以及10-19歲的族群;而30-39歲以及40-49歲之民眾上網率,成長幅度最高。在2006年的調查當中發現,10-39歲的台灣民眾上網率已超過75%。而40-49歲的族群則是首度超越五成,有55.3%的上網率。50歲以上的民眾亦有17.6%的上網率,相較於2004年有長足的成長,亦反映網路上的銀髮勢力正在崛起當中,而網路的使用正邁向全民化現象。

網路的快速發展以及各項條件的成熟,讓網路漸漸成為僅次於電視的第二大媒體。2006年的網路環境也隨著整併風潮以及Web2.0等創新服務的普及,而越來越受到矚目。創市際執行長江義宇表示,網路具有媒體與各項服務整合的特性,使得網友的依賴程度日深,具有成為第一大媒體的態勢。目前網路上的內容多針對較年輕之網友而設計,針對40代以上網友提供內容或服務,將會是各網站拓展觸及廣度或是目標區隔的重要方向。

Ipsos Taiwan總經理錢志遠也表示,從目前各種市場調查研究中發現,網路已經在公司與消費者之間的互動方面扮演重要的角色,且影響力將會隨著網路環境的整併風潮與創新服務的普及逐漸加深。50歲以下的上網率已接近六成,顯示利用網路協助消費者資訊收集的時機已經成熟。

這份調查是創市際於2004-2006年,與全球第三大市場研究機構Ipsos合作執行台灣上網行為基礎調查,以各年度內政部所公佈之台灣人口分布比例進行配額抽樣,透過電話訪問方式進行調查。研究對象為台灣地區10歲以上之民眾,研究內容為暸解台灣民眾上網使用率與連網行為 。

 來源:http://tw.news.yahoo.com/article/url/d/a/070102/17/8ump.html"

Servlet和JSP概述

"

Java Servlet及其特點

   Servlet是Java技術對CGI程式設計的回答。Servlet程式在伺服器端執行,動態地產生Web頁面。與傳統的CGI和許多其他類似CGI的技術相比,Java Servlet具有更高的效率,更容易使用,功能更強大,具有更好的可移植性,更節省成本(更重要的是, Servlet程式設計師收入要比Perl程式設計師高:-):

高效能:

在傳統的CGI中,每個請求都要啟動一個新的排程,如果CGI程式本身的執行時間較短,啟動排程所需要的開銷很可能反而超過實際執行時間。而在Servlet中,每個請求由一個輕量級的Java線程處理(而不是重量級的操作系統排程)。
在傳統CGI中,如果有N個並發的對同一CGI程式的請求,則該CGI程式的程式碼在內存中重複裝載了N次;而對於Servlet,處理請求的是N個線程,只需要一份Servlet類程式碼。在性能最佳化方面,Servlet也比CGI有著更多的選擇,比如緩衝以前的計算結果,保持資料庫連接的活動,等等。

方便:

Servlet提供了大量的實用工具例程,例如自動地解析和解碼HTML表單資料、讀取和設置HTTP頭、處理Cookie、跟蹤會話狀態等。

功能強大:

在Servlet中,許多使用傳統CGI程式很難完成的任務都可以輕鬆地完成。例如,Servlet能夠直接和Web伺服器交互運算,而普通的CGI程式不能。Servlet還能夠在各個程式之間共享資料,使得資料庫連接之類的功能很容易實現。

可移植性好:

Servlet用Java編寫,Servlet API具有完善的標準。因此,為I-Planet Enterprise Server寫的Servlet無需任何實質上的改動即可移植到Apache、Microsoft IIS或者WebStar。幾乎所有的主流伺服器都直接或通過插件支持Servlet。

節省成本:

不僅有許多廉價甚至免費的Web伺服器可供個人或小規模網站使用,而且對於現有的伺服器,如果它不支持Servlet的話,要加上這部分功能也往往是免費的(或只需要極少的成本)。

JSP及其特點

   JavaServer Pages(JSP)是一種實現普通靜態HTML和動態HTML混合編碼的技術。

   許多由CGI程式生成的頁面大部分仍舊是靜態HTML,動態內容只在頁面中有限的幾個部分出現。但是包括Servlet在內的大多數CGI技術及其變種,總是通過程式生成整個頁面。JSP使得我們可以分別建立這兩個部分。例如,下面就是一個簡單的JSP頁面:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD><TITLE>歡迎訪問網上商店</TITLE></HEAD>
<BODY>
<H1>歡迎</H1>
<SMALL>歡迎,
<!-- 首次訪問的帳號字為"New User" -->
<% out.println(Utils.getUserNameFromCookie(request)); %>
要設置帳號訊息,請點擊
<A HREF="Account-Settings.html">這裡</A></SMALL>
<P>
頁面的其餘內容。.
</BODY></HTML>

   下面是JSP和其他類似或相關技術的一個簡單比較:

JSP和Active Server Pages(ASP)相比

Microsoft的ASP是一種和JSP類似的技術。JSP和ASP相比具有兩方面的優點。首先,動態部分用Java編寫,而不是VB Script或其他Microsoft語言,不僅功能更強大而且更易於使用。第二,JSP應用可以移植到其他操作系統和非Microsoft的Web伺服器上。

JSP和純Servlet相比

JSP並沒有增加任何本質上不能用Servlet實現的功能。但是,在JSP中編寫靜態HTML更加方便,不必再用 println語句來輸出每一行HTML程式碼。更重要的是,借助內容和外觀的分離,頁面製作中不同性質的任務可以方便地分開:比如,由頁面設計專家進行HTML設計,同時留出供Servlet程式設計師插入動態內容的空間。

JSP和伺服器端包含(Server-Side Include,SSI)相比

SSI是一種受到廣泛支持的在靜態HTML中引入外部程式碼的技術。JSP在這方面的支持更為完善,因為它可以用Servlet而不是獨立的程式來生成動態內容。另外,SSI實際上只用於簡單的包含,而不是面向那些能夠處理表單資料、訪問資料庫的“真正的”程式。

JSP和JavaScript相比

JavaScript能夠在客戶端動態地生成HTML。雖然JavaScript很有用,但它只能處理以客戶端環境為基礎的動態訊息。除了Cookie之外,HTTP狀態和表單提交資料對JavaScript來說都是不可用的。另外,由於是在客戶端執行,JavaScript不能訪問伺服器端資源,比如資料庫、目錄訊息等等。 
參考資料:http://www.web-designer.com.tw/article/articlelist.asp?classid=3&subclassid=18&articleid=278

[@more@]"

Overview of Cookies

"Cookies are small bits of textual information that a Web server sends to a browser and that the browser returns unchanged when visiting the same Web site or domain later. By having the server read information it sent the client previously, the site can provide visitors with a number of conveniences:

  • Identifying a user during an e-commerce session. Many on-line stores use a "shopping cart" metaphor in which the user selects an item, adds it to his shopping cart, then continues shopping. Since the HTTP connection is closed after each page is sent, when the user selects a new item for his cart, how does the store know that he is the same user that put the previous item in his cart? Cookies are a good way of accomplishing this. In fact, this is so useful that servlets have an API specifically for this, and servlet authors don't need to manipulate cookies directly to make use of it. This is discussed in <A HREF = "http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/Servlet-Tutorial-Sess... tutorial section on Session Tracking.</A>
  • Avoiding username and password. Many large sites require you to register in order to use their services, but it is inconvenient to remember the username and password. Cookies are a good alternative for low-security sites. When a user registers, a cookie is sent with a unique user ID. When the client reconnects at a later date, the user ID is returned, the server looks it up, determines it belongs to a registered user, and doesn't require an explicit username and password.
  • Customizing a site. Many "portal" sites let you customize the look of the main page. They use cookies to remember what you wanted, so that you get that result initially next time. I'll give an example like this later in this section of the tutorial.
  • Focusing advertising. The search engines charge their customers much more for displaying "directed" ads than "random" ads. That is, if you do a search on "Java Servlets", a search site can charge much more for an ad for a servlet development environment than an ad for an on-line travel agent. On the other hand, if the search had been "Bali Hotels", the situation would be reversed. The problem is that they have to show a random ad when you first arrive and haven't yet performed a search, as well as when you search on something that doesn't match any ad categories. Cookies let them remember "Oh, that's the person who was searching for such and such previously" and display an appropriate (read "high priced") ad instead of a random (read "cheap") one.

Now, providing convenience to the user and added value to the site owner is the purpose behind cookies. And despite much misinformation, cookies are not a serious security threat. Cookies are never interpreted or executed in any way, and thus can't be used to insert viruses or attack your system in any way. Furthermore, since browsers generally only accept 20 cookies per site and 300 cookies total, and each cookie is limited to 4KB, cookies cannot be used to fill up someone's disk or launch other denial of service attacks. However, even though they don't present a serious security threat, they can preseent a significant threat to privacy. First, some people don't like the fact that search engines can remember that they're the person that usually does searches on such and such a topic. For example, they might search for job openings or health data, and don't want some banner ad tipping off their coworkers next time they do a search. Even worse, two search engines could share data on a user by both loading small images off a third party site, where that third party uses cookies and shares the data with both search engines. (Netscape, however, provides a nice feature that lets you refuse cookies from sites other than that to which you connected, but without disabling cookies altogether.) This trick can even be exploited via email if you use an HTML-enabled email reader that "supports" cookies, as Outlook Express does. Thus, people could send you email that loads images, attach cookies to those images, then later identify you (email address and all) when you went to their site. Or, a site that ought to have much higher security standards might let users skip user name and passwords via cookies. For example, some of the big on-line bookstores use cookies to remember users, and let you order without reentering much of your personal information. However, they don't actually display the full credit card number, and only let you send books to an address that was entered when you did enter the credit card in full or use the username and password. As a result, someone using the person's computer (or stealing their cookie file) could do no more harm than sending a big book order to the credit card owner's address, where it could be refused. However, smaller companies might not be so careful, and access to someone's computer or cookie file could result in loss of valuable personal information. Even worse, incompetent sites might embed credit card or other sensitive information directly in the cookies themselves, rather than using innocuous identifiers which are only linked to real users on the server. The point of all this is twofold. First, due to real and perceived privacy problems, some users turn off cookies. So, even when you use cookies to give added value to a site, your site shouldn't depend on them. Second, as the author of servlets that use cookies, you should be careful not to trust cookies for particularly sensitive information, since this would open the user up to risks if somebody accessed their computer or cookie files.  [@more@]"

What is Session Tracking?

"There are a number of problems that arise from the fact that HTTP is a "stateless" protocol. In particular, when you are doing on-line shopping, it is a real annoyance that the Web server can't easily remember previous transactions. This makes applications like shopping carts very problematic: when you add an entry to your cart, how does the server know what's already in your cart? Even if servers did retain contextual information, you'd still have problems with e-commerce. When you move from the page where you specify what you want to buy (hosted on the regular Web server) to the page that takes your credit card number and shipping address (hosted on the secure server that uses SSL), how does the server remember what you were buying? There are three typical solutions to this problem.

  1. Cookies. You can use HTTP cookies to store information about a shopping session, and each subsequent connection can look up the current session and then extract information about that session from some location on the server machine. This is an excellent alternative, and is the most widely used approach. However, even though servlets have a <a href=" http://www.apl.jhu.edu/~hall/java/Servlet- Tutorial/Servlet-Tutorial-Cookies.html "> high-level and easy-to-use interface to cookies</a> , there are still a number of relatively tedious details that need to be handled:
  • Extracting the cookie that stores the session identifier from the other cookies (there may be many, after all),
  • Setting an appropriate expiration time for the cookie (sessions interrupted by 24 hours probably should be reset), and
  • Associating information on the server with the session identifier (there may be far too much information to actually store it in the cookie, plus sensitive data like credit card numbers should never go in cookies).
  • URL Rewriting. You can append some extra data on the end of each URL that identifies the session, and the server can associate that session identifier with data it has stored about that session. This is also an excellent solution, and even has the advantage that it works with browsers that don't support cookies or where the user has disabled cookies. However, it has most of the same problems as cookies, namely that the server-side program has a lot of straightforward but tedious processing to do. In addition, you have to be very careful that every URL returned to the user (even via indirect means like Location fields in server redirects) has the extra information appended. And, if the user leaves the session and comes back via a bookmark or link, the session information can be lost.
  • Hidden form fields. HTML forms have an entry that looks like the following: <INPUT TYPE="HIDDEN" NAME="session" VALUE="...">. This means that, when the form is submitted, the specified name and value are included in the GET or POST data. This can be used to store information about the session. However, it has the major disadvantage that it only works if every page is dynamically generated, since the whole point is that each session has a unique identifier.
  • Servlets provide an outstanding technical solution: the HttpSession API. This is a high-level interface built on top of cookies or URL-rewriting. In fact, on many servers, they use cookies if the browser supports them, but automatically revert to URL-rewriting when cookies are unsupported or explicitly disabled. But the servlet author doesn't need to bother with many of the details, doesn't have to explicitly manipulate cookies or information appended to the URL, and is automatically given a convenient place to store data that is associated with each session.[@more@]"

    頁面