使用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创建私人和受保护的会员

回答

相关问题