使用Javascript創建私人和受保護的會員

-4

我的意思是真正的保護不僅僅像道格拉斯克羅克福德說的那樣。

請勿使用_（underbar）作爲名稱的第一個字符。它有時用於表示隱私，但實際上並不提供隱私。如果隱私很重要，請使用提供私人成員的表單。避免表現出缺乏競爭力的慣例。

 "use strict"; 

     function MyMain(){ 
      this.checkauth=false; 
     } 

     MyMain.prototype.init=function(){ 
      return Object.create(this); 
     } 

     MyMain.prototype.authenticate=function(key){ 

//resp is server response hold true for the given key. here validate method will interact with server and get concerned response 
      var resp=validate(key); 
      if(resp){ 
       this.checkauth=true; 
       return true; 
      } 
      return false; 
     } 

     MyMain.prototype.test=function(){ 
      if(this.checkauth==true){ 
      console.log("this is working") 
      }else{ 
       console.log("Not authorized") 
      } 
     }

那麼我沒有解釋看到我編輯的編輯。

我無意在客戶端進行授權。我做了它在服務器上，並讓私人成員真正說服務器已驗證用戶，我的問題是如何使這個安全。

和有權訪問我的Javascript文件的用戶可以讀取所有內容並進行身份驗證。

var main=new MyMain(); 
main.checkauth=true; 
main.test();

尋找通過javascript創建安全認證的幫助。

來源

2015-09-04 saikiran

永遠不要信任客戶端代碼。 _一直驗證用戶輸入服務器端。 – Cerbrus

「尋找通過javascript創建安全認證的幫助。」我想你會得到的最好的幫助是：不要。 –

您是否認爲「受保護的成員」根本無法檢查或訪問？恐怕我不得不解除你的這個想法。「傳統」隱私在實際安全性方面並不比其他任何方面更安全。它仍然只是在瀏覽器中運行的JavaScript。成員封裝和訪問保護只是爲了幫助開發人員交流預期的用法，沒有什麼更多的。就此而言，下劃線與範圍變量相同。 – deceze

雖然有各種方法來屏蔽變量並使訪問變得非常棘手，但這些技術的主要優點是，它們阻止您偶然訪問它們。

瀏覽器的所有者訪問所有代碼和所有你發送到瀏覽器中的數據的。

您無法阻止他們訪問它。

如果你想做安全身份驗證，那麼你必須做到這一點在服務器上。

我無意在客戶端進行授權。

如果你不是在做authz客戶端，那麼設置main.checkauth=true;的用戶對你來說不會是個問題。

您需要不發送數據和JavaScript應只可供授權用戶使用，如果用戶未被授權。目前你似乎在服務器上進行授權，但無論如何，只要有一點客戶端代碼說「請不要看這個」，就將所有授權用戶的數據/ JS發送給客戶端。

來源

2015-09-04 09:37:16 Quentin

順便說一句，也許它是NodeJS，它已經在服務器端 –

也許他在某種程度上在他的ASP.net服務器上運行JavaScript代碼片段。如果OP使用node.js，他會標記它，並且他不會擔心用戶訪問JS文件。 – Cerbrus

編輯我的問題 – saikiran

使用Javascript創建私人和受保護的會員

回答

相關問題