目前正在製作以WebService中介的資料庫存取服務，有一些問題，大家是不是可以給點意見。 如果採用這樣的架構 Client(AP) -> WebServices(IIS ISAPI) -> COM (ADO) -> Database(MSSQL) 首先，使用者在登入系統前，勢必要輸入帳號與密碼，我將帳號與密碼加密後送給Webservices，webservices會將這個帳號密碼解密之後再送給 COM 做認證，這些帳號與密碼也都是存在MSSQL裡，所以COM 元件中自然會需要擁有連接MSSQL的帳號與權限，使用者帳號數千，我當然不可能一個個開，所以使用一個獨立的帳號連結，讀取密碼檔，驗證使用者的身份之後，一路傳送回 AP ，AP 依據結果，會顯示適當的畫面。這個階段不知道大家有沒有什麼建議。 接著，如果使用著想要瀏覽或修改某些資料時，當然還是要呼叫相關的webservice來進行，但是，這些webservice要如何確認這個人是有權限的呢？對使用者來說，輸入過一次帳號密碼，就意味著他有權限可以進行以下的動作，可以對webserices而言則不然，以前Client/Server時，連線可以一直keep住，所以沒問題，可以現在webservice連接完畢後就斷線了，該如何保持認證？如果不理會，那任何一個知道你webservice interface宣告的人，理論上都能使用這些webservice功能，而不需要認證。或者，如果在每個webservice inteface method 宣告時都加上loginname 與 passwd的參數傳遞，哪進行一次動作就認證一次，覺得又太笨，請教大家有更好的方法嗎？ 謝謝您的回應。

您好, 關於第一個問題,使用者登入帳號的查驗動作,一般都會在系統裡依據整個系統的功能需求(商業邏輯)來設計權限控管的table與ap,讓系統管理者可以方便的維護每個使用者的權限,系統(COM＋ADO)依據這些資料來驗證id/pws 至於第二個問題,後續的動作是否有權限可以繼續執行的問題,一般都會有一個主程式(MainForm)去留住使用者ID等相關資料,只要後續的動作確認是由主程式呼叫過來的就可以執行. 另外,我比較好奇的是,為何Client(AP)會與IIS連接呢?一般不是都是Client(IE)與IIS連,或者Client(AP)與Application Servier連嗎?

在web server只要驗證一變數也可以,例如client一開啟後輸入帳號密碼 然後client程式根據權限來開放/限制功能...但對web server來說,他只負責 提供函式給client使用,所以只要從client傳一變數給他說他是"已認證的"可以繼續 這樣做也行,不該呼叫到的功能也不可能呼叫到(client就擋住了), 如果有人用自己寫的client偷連web server,也過不了關,因為沒傳變數過去... 不過..要是傳什麼樣的變數被知道..web server還是會被偷連... 如果你非常要求安全,那就每呼叫一次驗一次,就速度考量,只要驗一次即可 to change.jian, > 永遠追不上技術更新的速度

------
星期一,二...無窮迴圈＠＠

目前我的想法是，在呼叫每一個有安全顧慮 webservice function 時，都同時傳遞使用者的認證資訊，這個webservice在後端確認這個認證之後，再執行他應該做的事情。這樣的方法應該是可行，但是這樣的COST就提高了。 關於 pgdennis:就速度考量,只要驗一次即可 我也希望如此，如果AP只需要呼叫一個webservice的話，那應該沒問題，但是若需要呼叫多個webservice甚至是不同主機上的webservice我想應該就沒辦法克服吧。 其實我問這個問題，是在想，既然webservice是實做在http，難道在設計規格時沒有什麼機制可以像網頁瀏覽時紀錄像是cookie之類的嗎？把連線認證交給系統去處理(雖然也是要花時間認證)，省得自己撰寫這類機制。 謝謝你們的回應。

引言: to change.jian, > 永遠追不上技術更新的速度 < face="Verdana, Arial, Helvetica"> 了解.不過,若以Delphi而言,一般以Midas的技術去做3-rd的架構應是比較省力的吧.因我所接觸的案子都是這樣....

了解.不過,若以Delphi而言,一般以Midas的技術去做3-rd的架構應是比較省力的吧.因我所接觸的案子都是這樣.... ------------------------------------- 如果整個系統架構上，除了AP存取外，還有瀏覽器也可以讀取的話，用webservice應該反而是比較整合的作法。另外，做這樣選擇的一項原因是，可以不用管防火牆的的設定(除非連web port都關了)

引言: 了解.不過,若以Delphi而言,一般以Midas的技術去做3-rd的架構應是比較省力的吧.因我所接觸的案子都是這樣.... ------------------------------------- 如果整個系統架構上，除了AP存取外，還有瀏覽器也可以讀取的話，用webservice應該反而是比較整合的作法。另外，做這樣選擇的一項原因是，可以不用管防火牆的的設定(除非連web port都關了)

基本上如果一個系統有AP與WEB的話,那(1).AP與WEB的設計方式不同,所以應該無法共用IIS.(2).如果真的有共用的話,應該是把business rule架構在MTS上,AP去呼叫MTS,IIS上的程式也呼叫MTS.這樣共用應該比較合理吧.(這樣想對不對?)

你誤解我意思了,"但是若需要呼叫多個webservice甚至是不同主機上的webservice我想應該就沒辦法克服吧"-->>如果有client要呼叫到N個webservice,那每個webservice都傳一變數給他,讓他知道這個client是有權限執行的.... 就如同一般2 tier程式一樣,一開始登錄時輸入帳號密碼,就決定此使用者可執行的權限,例如本來有1.2.3功能模組,甲帳號只能執行1,2,當他登錄成功時,可用一變數紀錄,當他要執行1,2時,1,2這兩個webservice只要檢查這個變數即可,至於3模組在client登錄時就已限制住了,他根本不能呼叫3這個webservice... web service端不知道哪個帳號呼叫他,只靠變數判斷你可不可執行...這樣最快 至於web service有幾個,在哪邊...這跟驗證無關... 永遠追不上技術更新的速度

------
星期一,二...無窮迴圈＠＠

引言: 基本上如果一個系統有AP與WEB的話,那(1).AP與WEB的設計方式不同,所以應該無法共用IIS.(2).如果真的有共用的話,應該是把business rule架構在MTS上,AP去呼叫MTS,IIS上的程式也呼叫MTS.這樣共用應該比較合理吧.(這樣想對不對?)

網頁程式也一樣可以呼叫 sebservice 的服務，譬如說用asp.net撰寫一個網頁，並利用他去呼叫之前寫給AP呼叫的 function，這樣就可以少寫一些程式碼了，還能共用伺服器端的相關邏輯。

引言: 你誤解我意思了,"但是若需要呼叫多個webservice甚至是不同主機上的webservice我想應該就沒辦法克服吧"-->>如果有client要呼叫到N個webservice,那每個webservice都傳一變數給他,讓他知道這個client是有權限執行的.... 就如同一般2 tier程式一樣,一開始登錄時輸入帳號密碼,就決定此使用者可執行的權限,例如本來有1.2.3功能模組,甲帳號只能執行1,2,當他登錄成功時,可用一變數紀錄,當他要執行1,2時,1,2這兩個webservice只要檢查這個變數即可,至於3模組在client登錄時就已限制住了,他根本不能呼叫3這個webservice... web service端不知道哪個帳號呼叫他,只靠變數判斷你可不可執行...這樣最快 至於web service有幾個,在哪邊...這跟驗證無關...

沒錯，我們是利用第一次輸入的帳號密碼來決定 client 端 ap 可以提供使用者哪些模組，這個部分沒問題。 但是因為我們怕有人直接去call我們的webservices function，所以想在這部分加強，所以您所說的方是就是在每次呼叫 function 時，多傳遞一個參數，而這個參數就是讓function可以確認這是一個有權限的呼叫而提供服務，對吧。 我們也是想這樣做，但是我們覺得只傳遞一個變數來做判斷，萬一有人知道你傳的是什麼（譬如說傳一個字串"ok"表示有權），那整個系統還是任他呼叫。所以我們傳遞的參數就是使用者啟動client ap 時所輸入的帳號與密碼。不管如何，我想我們解法應該是非常接近的，都是再呼叫function時多傳一些參數來確認。 我覺得還要浪費資源去傳參數並判斷權限，覺得蠻笨的，不知道webservice有沒有更好的機制可以完成這樣的工作。

傳的變數傳長一點的,又經過加密的也可以阿..你說這樣會被知道QQ 那你用帳號密碼一樣會有被盜用的危險.... 不然就用認證吧..這我就沒搞過了...參考

------
星期一,二...無窮迴圈＠＠

沒錯，不管是傳一個參數或者是傳帳號密碼，都可能被解出來，不果如果是參數被解出來，整個系統中使用這個變數的function都任人使用，如果是帳號被解出來的話，應該是該使用者權限範圍內的資料會受到危害，感覺上傷害比較小（當然也可以設計多組參數）。不管是參數或帳號，加密應該是一定要的吧。只是覺得像webservice這種東西，傳輸完成就斷線，雖然有他的好處在，但是也帶來一些問題，您所提供的元件我等會兒研究一下，多謝。