如何使用Ext JS的基于角色的应用 [英] How to use Ext JS for role based application

问题描述

 我计划使用Ext JS的一个大的应用程序。该应用程序的功能是基于角色的。当用户登录时，他们只看到与他们相关的菜单和屏幕的功能。我的服务器端技术将是Java的＆放大器; JSP。

要解决这个问题，我有两个想法..
    1.使用服务器端技术，在用户登录后创建的Ext JS相关的JavaScript动态。该servlet / JSP将根据用户角色创建必要的EST JS code。

    将被用来确保在视图的JSP设置2.有无的js变量只有正确的功能提供给用户。

什么是保证安全性，并提供基于角色的用户界面中的Ext JS应用程序的最佳途径。
在此先感谢您的想法。

·阿卜杜勒·Olakara

解决方案

我要解决类似的问题在一个应用程序，我目前正在开发，但权限基于用户的国家。

我知道你已经有，但只是为了重申任何人阅读的好处，的权限应该总是在服务器端执行，JavaScript安全始终是次要。这是因为任何人动动脑子可以使用一个书签或萤火虫执行任意JavaScript和绕过您的客户端安全性。

我发现，有几种方法可以做到这一点，但有两种做法，特别是最理智的。不管使用哪种方法，有两件事需要考虑：1）什么样的JavaScript到服务器，以及如何避免不必要的服务逻辑，以及2）如何避免执行的逻辑，是不是提供给用户

。

延迟加载和权限配置：

1. 在我的应用程序的所有部件都懒通过 dojo.require 加载，所以没有必要担心不必要的包容的JavaScript，这是不适用给用户。我没有深入了解ExtJS的库，但据我所看到的，它并没有提供一个比较的方法;但是，它是必不可少的一个同步Ajax调用后跟一个eval。在任何情况下，在该方法中，重要的是组件功能不横切通过不同的文件（也，这通常是良好的设计）。每个文件应该是其自己的类控制某一特定的小工具或其他UI元素。

2. 然后我在生成服务器的JavaScript配置类设置权限。这个类就可以在整个应用程序是什么，什么是不允许的引用。

例如，以大多数人可从全局控制器的部件的下面的方法控制的访问。

  com.project.frontController.prototype.init =功能（部件）{
   VAR的权限= com.project.config.permissions;

   //对于在控制器每个插件
   对于（VAR I = 0,1 = widgets.length; I＆LT;升; + I）{
       //如果访问被限制在小部件（按id），然后将其禁用。
       如果（！许可[控件[I] .ID] {
           com.project.util.disable（部件[I] .btnAccessNode）;
       }
       //否则，离开它启用，连接必要的事件处理。
       其他 {
           //连接一个onclick处理程序或任何需要的小工具
       }
   }
};
 

和的配置看起来是这样的：

  com.project.config.permissions = {
    widgetAbc：{
        btnAccessNode：＃一些，CSS选择器，
        otherWidgetConfig：等等
    }，
    widgetXyz：{
        btnAccessNode：div.some-CSS选择器
    }
};
 

编译和功能检查：

1. 有些应用程序会编译所有的JavaScript到一个文件，然后将其提供给客户机。如果您的应用程序做这样的事情，你可以管理动态地做到这一点，所有必要的JS可以在服务器端被确定在送达之前。当然，这会累积一些开销;但是，您可以高速缓存编译通过角色的版本。如果角色是少数，那么这个缓存可以很容易地催芽，它的其中一个特定的脚本只是早晚的问题。

2. 由于只有允许的JavaScript将可用，只需检测，如果需要的类/函数可用试图执行它是所有你需要为你的权限，然后检查一下。

例如，您的脚本包含可能看起来是这样的：

 ＆LT;脚本类型=文/ JavaScript的SRC =/ JS / compiler.php作用=主持人？＆GT;＆LT; / SCRIPT＆GT;
 

和您的功能性检查会是这样的：

  com.project.frontController.prototype.init =功能（部件）{
   //对于在控制器每个插件
   对于（VAR I = 0,1 = widgets.length; I＆LT;升; + I）{
       //如果小部件控制器不存在，禁用它。
       如果（！com.project.util.widgetExists [控件[I] .ID] {
           com.project.util.disable（部件[I] .btnAccessNode）;
       }
       //否则，离开它启用，连接必要的事件处理。
       其他 {
           //连接一个onclick处理程序或任何需要的小工具
       }
   }
};
 

或

  com.project.someWidget.prototype.launchOtherWidget =功能（）{
    如果（typeof运算otherWidget！=未定义）{
        （新otherWidget（））开（）。
    }
};
 

请注意，这两种方法都在执行非常相似。我想说，使两者之间的决心的最好办法就是要考虑你的codeBase的大小，提供给您的编制在飞行，并缓存这些工具基于角色的，编制包。对于我的项目，不仅是一个编译器不能在环境中可用，但code碱基很大（1.3MB充气/ 296KB拖欠加上Dojo库），这是不能接受的客户更感兴趣的是保持小应用程序加载时间。

I am planning to use Ext JS for a large application. The application's features are role based. When user login, they only see menu and screen features related to them. My server side technology will be Java & JSP.

To solve this I have two ideas..
1. Create Ext JS related javascript dynamically after the user login using server side technology. The servlet / JSP will create the necessary est js code according to user roles.

2. Have Js variables that are set in view JSPs that will be used to ensure only the right features are available to users.

What is the best way to ensure security and provide role based UI in Ext Js application.
Thanks in advance for you ideas..

Abdel Olakara

解决方案

I had to solve a similar problem in an application that I currently developed, but permissions are based on user country.

I know you already are, but just to reiterate for the benefit of anyone reading, permissions should always be implemented on the server side and JavaScript security is always secondary. This is because anyone with half a brain can use either a bookmarklet or Firebug to execute arbitrary JavaScript and circumvent your client-side security.

I've found that there are several ways to do this, but there are two approaches in particular that are the most sane. Regardless of the approach, there are two things to consider: 1) what JavaScript to server and how to avoid serving unnecessary logic, and 2) how to avoid executing logic that is not available to the user.

Lazy loading and permissions configuration:

1. All widgets in my application are lazy loaded via dojo.require, so there was no need to worry about the unnecessary inclusion of JavaScript that wasn't applicable to the user. I am not deeply familiar with the ExtJs library, but as far as I have seen, it doesn't supply a comparable method; however, it is essential a synchronous ajax call followed by an eval. In any case, in this method it is important that component functionality doesn't cross-cut through different files (also, this is generally good design). Each file should be its own class that controls a specific widget or other UI element.

2. I then set permissions in a server generated JavaScript config class. This class can then be referenced throughout the application for what is and what is not allowed.

For example, the following method controlled access to most of the widgets that were available from global controls.

com.project.frontController.prototype.init = function(widgets) {
   var permissions = com.project.config.permissions;

   // For each widget in the controller
   for ( var i=0, l=widgets.length; i<l; ++i ) {
       // If access is restricted to the widget (by id), then disable it.
       if ( !permissions[ widgets[i].id ] {
           com.project.util.disable(widgets[i].btnAccessNode);
       }
       // Otherwise, leave it enabled and connect the necessary event handlers.
       else {
           // connect an onclick handler or whatever is required for the widget
       }
   }
};

And the config looked something like:

com.project.config.permissions = {
    "widgetAbc": {
        btnAccessNode:     "#some-css-selector",
        otherWidgetConfig: "etc"
    },
    "widgetXyz": {
        btnAccessNode:     "div.some-css-selector"
    }
};

Compile and functionality check:

1. Some applications will compile all of its JavaScript into one file, and then serve it to the client. If your application does such a thing, and you can manage to do this dynamically, all necessary JS can be determined on the server-side before it is served. Of course, this will accrue some overhead; however, you can cache compiled versions by role. If the roles are few, then this cache can be easily primed and it's just a matter of including one specific script.

2. Since only the allowed JavaScript will be available, simply detecting if the required class/function is available before attempting to execute it is all you need to do for your permissions check.

For example, you script inclusion may look like this:

<script type="text/javascript" src="/js/compiler.php?role=moderator"></script>

And your functionality check would be something like this:

com.project.frontController.prototype.init = function(widgets) {
   // For each widget in the controller
   for ( var i=0, l=widgets.length; i<l; ++i ) {
       // If the widget controller doesn't exist, disable it.
       if ( !com.project.util.widgetExists[ widgets[i].id ] {
           com.project.util.disable(widgets[i].btnAccessNode);
       }
       // Otherwise, leave it enabled and connect the necessary event handlers.
       else {
           // connect an onclick handler or whatever is required for the widget
       }
   }
};

or

com.project.someWidget.prototype.launchOtherWidget = function() {
    if ( typeof otherWidget != "undefined" ) {
        (new otherWidget()).open();
    }
};

Notice that both methods are very similar in implementation. I would say the best way to make a determination between the two is to consider the size of your codebase, the tools available to you for compiling on the fly, and caching those role-based, compiled packages. For my project, not only was a compiler not available in the environment, but the code base was large (1.3mb inflated/296kb defaulted plus the dojo library), which wasn't acceptable as the client was more interested in maintaining low application load times.

这篇关于如何使用Ext JS的基于角色的应用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！