In one of my current apps for a client, I have an activity based security system that determines what the user is allowed to do. The trick to this system is that all of the authorization checks happen on the server, but the functionality that is being secured runs on the client, in JavaScript.

This is a bit of a problem. If I send all of the JavaScript that is uses to run any part of the system to the browser, then it’s possible that a clever user could enable it and do things they aren’t supposed to do. Of course, when they send a request back to the server, the server will verify they can do what they requested and block it… but the user should not be able to even try to do things they aren’t authorized to do, in the first place.

The solution that I’ve come up with, at a very high “functional area of the application” level, is simply not to send JavaScript to the browser if the user is not allowed to use it. This keeps me from having to do extra security checks in the browser, keeps the download for the user smaller and generally makes the app appear snappier because there is less code to run. More importantly, though, it keeps the user from being able to try things they can’t do.

Modules To The Rescue

I’m facilitating this through the use of modules in my JavaScript – both “module” as in the JavaScript module pattern, and “module” as in a packaged functional area of an application.

It’s worth noting, though, that I’m not using AMD (asynchronous module definitions), RequireJS, or any other “module” framework for JavaScript. The debate about the “right way” to do modules can rage on all it wants. I’m content with simple immediate functions and logical groupings of files while the more intelligent and invested people in the JS community figure that all out.

Each of the functional areas of my application is built in it’s own set of files. Each area has multiple files that it is composed within, but the files are grouped together for easy identification of what makes up a module. I also have an HTML template for each module which provides the needed <script> tags to include the code for that module.

Only Render What Is Needed

When I need a functional area of my site to be sent down to the user, I tell my server side template language to include the correct HTML file. For example, I’m doing this in an ASP.NET MVC application:

@{var user = (CustomPrincipal)User;}


@if (user.Can("locations/manage"))
{
    @Html.LocationManagementScripts()
}


@if (user.Can("locations/search"))
{
    @Html.LocationSearchScripts()
}

In this code, I’m checking to see if the current user is allowed to manage locations. If they are, the extension method “LocationManagementScripts” is called. This in turn renders the “LocationManagementScript.html” file at this point in my HTML layout. That file contains all of the <script> tags for the location management JavaScript app. In the same way, I’m checking to see if the user can search through locations, and running the same basic process if they can.

Self-Initializing Modules

When a functional module is included after passing one of these checks, it needs a way to get itself spun up and started so that it can do it’s magic. It may need to render something on to the screen. It may need to register itself with the application’s event aggregator, or any of a number of other things. This is where my Backbone.Marionette add-on comes in to play for my Backbone apps.

Marionette has an explicit concept of an “initializer” tied to it’s Application objects. When you create an instance of an Application object, you can call “app.addInitializer” and pass a callback function. The callback function represents everything that your module needs to do, to get itself up and running. All of these initializer functions – no matter how many you add – get fired when you call “app.start()”.

myApp = new Backbone.Marionette.Application();


myApp.addInitializer(function(options){
  var myView = new MyView({
    model: options.someModel
  });
  MyApp.mainRegion.show(myView);
});


myApp.addInitializer(function(options){
  new MyRouter();
  new SomeOtherView().render();
});


myApp.start();

Each functional area of my application has it’s own initializer function. When a functional area has been included in the rendered <script> tags, the initializer gets added and when the “start” method is called, the modules for that functional area are fired up and they do there thing.

A Composite App, And Sub-Apps

One of the tricks to making all of this work, is that I need to have a primary “app” object that all of my modules know about. In the above example, the “myApp” object is this. Each of the modules for each of the functional areas has direct knowledge of this object and can call public APIs on it – including the “addInitializer” method.

A better example of what a module definition and initializer might look like, would be this:

// --------------------
// app.js


myApp = new Backbone.Marionette.Application();


myApp.addRegions({
  mainRegion: "#main"
});




// --------------------
// locationSearch.js


(function(myApp, Backbone){
  var SearchView = Backbone.View.extend({
    // ...
  });


  myApp.addRegions({
    searchRegion: "#search"
  });


  myApp.addInitializer(function(){
    var view = new SearchView();
    view.render();
    myApp.searchRegion.show(view);
  });
})(myApp, Backbone);




// --------------------
// index.html


<script language="javascript">
  myApp.start();
</script>

In this example, I’m using the simple JavaScript module pattern to encapsulate my search functionality. I’m also providing an initializer for the module that instantiates a search view and shows it to the user using a region manager.

Each of these functional areas is basically a sub-application. Many sub-applications are used to compose a larger application and overall experience for the user. The composition of a larger application through various modules that are included / excluded based on some criteria are what really make this a composite application.

I also included the final call to “myApp.start()”, showing that I do this from my main HTML page and not from my JavaScript files. This provides a single point of entry for all of the registered modules, no matter which modules are registered. The “myApp” object really doesn’t care which modules are registered, honestly. It doesn’t need to care. It only needs to execute the initializers that happen to be present. If none are present because the user didn’t have permission to do anything, then nothing happens when this method is called and the user won’t see anything.

Security: Don’t Let Them See It If They Can’t Do It

If the security check to see if the user is allowed to use the location search feature fails, the rendered HTML won’t include the <script> tags for the “locationSearch.js” file. If this file is not sent down to the browser, then it will never register itself. If a module has not registered itself for initialization, it’s views won’t show up on the screen and the user won’t be able to try and use the feature. Further, the user won’t be able to “view source” on the page and find any stray JavaScript that they shouldn’t be able to use.

It’s Not Always That Easy

Of course there are other security concerns that are not this simple. When a functional area is closed off by authorization, it’s easy to keep things clean like this. We can compose the application at run time simply by including the right files and letting the code in those files register themselves for initialization. But when we have a functional area of the system that has finer grained authorization and permissions associated with it, things get a little more tricky.

I’m still learning and exploring this space. I have some ideas and am going to be implementing some of them soon. If anyone out there has any experience in handling finer grained security needs in JavaScript apps, I’d love to hear about it. Post links to your favorite resources for this, in the comments.

Los Techies

In my previous post on Composite JavaScript Apps, I introduced a few of the high level design ideas and implementation details that I have been using in an application that I’m building. Since then, the requirements for that app have grown significantly and I’ve made more progress toward a better composite application design.

Content Swapping

My simple item management application started out with nothing more than these three regions on the screen:

Once this was in place, though, a new requirement came along… a complex search with search results. To implement this, I needed to modify the application’s interface to swap the grid and add/edit form out and put in a search results screen instead. The idea is that when the user does a search, the main content area will show the search results. The user can then go back to the location management aspect of the app whenever they need to. After a bit of searching, I found a high level pattern that made this easy, and also realized that I had previously implemented the core of this pattern without knowing it.

Microsoft Prism: Regions and Region Managers

Several years ago, Microsoft released a framework for it’s WPF and Silverlight runtimes, called Prism. This was essentially the big composite app framework that people used to build well structured and decoupled apps in XAML. I never had a chance to use this framework directly, but I worked with a team of developers that did use it.

One of the things that I liked about what I saw in Prism was the way it used the idea of “regions” and “region managers” to compose the user interface. The gist of it is that you could define a visible area of the screen and build out the most basic layout for it without knowing what content was going to be displayed in it at runtime. Then at runtime, your application modules could register themselves to have content displayed in the various regions of the screen.

This pattern fits perfectly with the direction that my Backbone app is heading, so I decided to borrow the names and build my own version in JavaScript.

A Simple Region Manager

In Prism, a region is defined in the XAML markup. In web applications, it’s defined in HTML markup. Similarly, in XAML a region manager is code that you write in C# or other .NET languages, while a region manager in a web app is going to be JavaScript. Backbone.js provides a good separation between the markup and the code to run that markup through it’s Views, so I initially thought about going down this path for my region manager. After a bit of thinking, though, I realized that I didn’t necessarily need a Backbone view. What I really need, at the very core, is a JavaScript object that do the following:

• Represent an existing DOM node
• Change out the contents of that DOM node
• Call any required rendering and initialization for content views that will be displayed
• Call any required cleanup for content views when they are removed

What I came up with as an initial pass at handling these needs, is the following (hard coded specifically to use a “#mainregion” element from the DOM):

RegionManager = (function (Backbone, $) {
    var currentView;
    var el = "#mainregion";
    var region = {};


    var closeView = function (view) {
        if (view && view.close) {
            view.close();
        }
    };


    var openView = function (view) {
        view.render();
        $(el).html(view.el);
        if (view.onShow) {
            view.onShow();
        }
    };


    region.show = function (view) {
        closeView(currentView);
        currentView = view;
        openView(currentView);
    };


    return region;
})(Backbone, jQuery);

Does that look familiar? It certainly does to me. I’ve written this same code dozens of times and blogged about it in my Zombies! RUN! post. So, it turns out that I’ve been using what I’m now calling a “region manager” for a while – I just didn’t realize it, previously. Oh, happy day! I’m just formalizing a concept I had introduced somewhere else, instead of having to create something new and unknown.

Using The Region Manager

An in-depth use of the region manager has been covered in my Zombies post already. As a refresher, though, you only need to provide a Backbone view to the `show` method and the region manager will take over from there.

MyView = Backbone.View.extend({
  render: function(){
    $(this.el).html("some html contents");
    $(this.el).hide();
  },


  close: function(){
    this.remove();
    this.unbind();
  },


  onShow: function(){
    $(this.el).show(500);
  }
});


RegionManager.show(new MyView());

The usual `close` method exists so we can handle our zombie problems. I’ve also added a bit more to the API that the region manager can handle, making it more robust and allowing it to handle more complex UI needs. Specifically, an `onShow` method fires on your view if you’ve provided one, just after the view’s `el` has been added to the DOM. This method will let you call into code that expects the DOM elements to exist, to manipulate them.

In this simple example, I’m using the `onShow` to fade the contents of the view in to view, using jQuery’s `.show` method and giving it a 500 milliseconds (1/2 of 1 second) time to do the fade. It’s a simple idea, but one that I’ve found is needed when using some libraries, such as the jQuery layout plugin. Again, this isn’t an idea that I came up with, either. I took this directly from my experience in working with WinForms applications. `onShow` is a standard event in the lifecycle of a Windows form, in .NET. It works well there, and it works well here in JavaScript, too.

But Wait! There’s More!

Well, maybe there isn’t anything more at this point in time. But there will be soon. As I’m traveling down the composite application path, I’m starting to extract the useful bits into a library so that I don’t have to rebuild the same things over and over again. If you’re interested in watching this grow over time, checkout my Backbone.Marionette repository on Github. It’s nearly empty at the time of writing this blog post, as it’s a work in progress. I plan on making a large announcement about it when I have more to share, sometime in the future.

Los Techies

Gamasutra Google's Native Client Makes Web Apps More DesktoppyTechNewsWorldGoogle (Nasdaq: GOOG) showed off the results of its Native Client SDK at an in-house event recently, highlighting some…



The Web Buyer Guide is a comprehensive directory used by today’s teach and business savvy Web buyers. Web buyers can make and educated and informed purchasing decisions by utilizing a Web Buyers Guide resource to search for companies and products by category, name, keyword, operating system, software requirements, type of product or price.
Web Buyers Guide

I’ve noticed a pattern in Backbone sample apps, requests for help via StackOverflow and the Google group, etc, where people realize that they have a need for an object that coordinates various parts of the application. This is a great realization and something that you should do when you see the need. However, most of the examples and sample that I see end up using a Backbone construct to handle this coordination – even when there is no direct benefit.

I don’t blame the people that are posting these example and questions, though. I think the problem stems from the learning curve of something new, and wanting to build something the way you see it being done in examples. I’ve seen this problem a number of times in my career and I’ve do the same thing when I’m learning something.

Here are a few of the examples that I think are causing problems for people, when learning.

The To-Do List’s AppView

A lot of people look at the simple to-do list example from Backbone, including me. It’s a great place to start if you want to see one way of building a small application with backbone. Unfortunately, when people see the AppView portion of the code, they often think that this is “the backbone way”. I thought this when I saw it at first, but I didn’t understand why it was this way. It didn’t seem right to me, but I didn’t question it as I was just learning backbone for the first time.

I built my first app with an AppView and it looked something like this (though honestly, it looked much much worse than this):

AppView = Backbone.View.extend({


  initialize: function(){
   this.router = new AppRouter();
   this.collection = new MyCollection();
   this.someView = new SomeView();
   this.someView.render();
   Backbone.history.start(); 
  }


});

Sure, this was worked for my simple app – it got things started up and running when i called `new AppView()`. It’s even better than putting all of that code right out in the middle of nowhere-land, where it would all become part of the global object. I was proud of myself for not pollution the global object! … but code like this shouldn’t exist in a view.

The Truth About AppView

If you look at the AppView in the to-do list example, and really read through the sample code, you’ll notice that it really is a backbone view. It registers events through the `events: { … }` attribute. It uses `this.$(…)` to do element selection within the view. It renders things into the DOM for display, too.

The AppView in the to-do list is a legitimate backbone view. It also happens to be the place that the to-do list starts up. This isn’t because AppView is the “the backbone way” of starting up an app, though. It’s only because there is no need for anything more complex in this example application. Nothing more.

Not Just Views

Its not just backbone views that get abused like this, though. I’ve seen examples where people build “controller” objects (which is a good idea, again) using a backbone model as the base class. In one particular example, the developer was using the events built into the model. The idea was good, but it was unnecessary to use a backbone model as a base class when backbone provides an event system that can be used anywhere.

You Have All Of Javascript Available. Use It.

This is the crux of what I’m trying to get at, really. When you recognize the need for an object that does not appear to fit within the constructs that backbone provides, don’t force it into one.

The next time you see a need for an application object that you can kick-start the app with, build your own object to do exactly that:

function MyApp(){
  var router = new MyRouter();
  var myCollection = new MyCollection();
  var someView = new SomeView({collection: myCollection});
  
  this.start = function(initialModels){
    myCollection.reset(initialModels);
    someView.render();
    Backbone.history.start();
  }
}


var someModels = [...];


new MyApp().start(someModels);

And when you want to take advantage of backbone’s events, just use backbone’s events:

// simple, object literal event thingy
var myThingy = _.extend({}, Backbone.Events);


// or a full object
function MyThingy(){
  _.extend(MyThingy.prototype, Backbone.Events);


  // other stuff here
}
var myThingy = new myThingy();


// use events!
myThingy.trigger("some:event");

You’ll find your code is much more understandable, less prone to strange behavioral bugs, and generally much cleaner and easier to work with if you remember that you can use all of javascript and not just the constructs that backbone gives you.

Los Techies

OpenSocial 2.0: Will key new additions make it a prime time player in social apps?ZDNet (blog)Dion Hinchcliffe is founder and chief technology officer for the Enterprise Web 2.0 advisory and…



The Web Buyer Guide is a comprehensive directory used by today’s teach and business savvy Web buyers. Web buyers can make and educated and informed purchasing decisions by utilizing a Web Buyers Guide resource to search for companies and products by category, name, keyword, operating system, software requirements, type of product or price.
Web Buyers Guide

8 Essential Developer Apps for Multiple PlatformsMashableFor any web developer, making sure your workflow stays streamlined and efficient is essential. Even small projects can grow quickly in size…



The Web Buyer Guide is a comprehensive directory used by today’s teach and business savvy Web buyers. Web buyers can make and educated and informed purchasing decisions by utilizing a Web Buyers Guide resource to search for companies and products by category, name, keyword, operating system, software requirements, type of product or price.
Web Buyers Guide

In the current sprint of the project I’m working on, we are deploying Office Web Apps to support an enterprise collaboration platform based on SharePoint Server 2010.

While creating the installation guide for this sprint, I used the following TechNet article as a reference for the section on installing and configuring Office Web Apps:

While the above article includes most of the steps you need to perform when deploying Office Web Apps on SharePoint 2010, it currently seems to be lacking a few important pieces (at least based upon my experience):

• Configure Excel Services Application trusted location (if you are using both HTTP and HTTPS)
• Configure the Office Web Apps cache
• Grant access to the Web application content database for Office Web Apps

These steps are performed after completing the deployment steps in the above TechNet article.

For the remainder of this post, imagine that we are installing Office Web Apps on the extranet site for Fabrikam Technologies (http://extranet.fabrikam.com) and we want to provide the ability for Fabrikam employees and its partners to collaborate on documents created in Microsoft Word, Excel, and PowerPoint.

Assume we have created a new Web application, configured it for claims-based authentication, and deployed Office Web Apps by following the steps in the aforementioned TechNet article.

The relevant service accounts for the Fabrikam extranet site are listed in the following table.

In order to resolve a few issues with the deployment and ensure it conforms to recommended best practices, we need to perform some additional configuration steps.

Configure Excel Services Application trusted location

When the Excel Services Application is created, a default trusted location is automatically configured (http://) for all content on the SharePoint farm. This default trusted location enables any file to be loaded from the SharePoint farm into Excel Services. However, this default trusted location does not support HTTPS (https://) and therefore results in the following error when attempting to access an Excel workbook using a secured connection:

This workbook cannot be opened because it is not stored in an Excel Services Application trusted location.

Use the following procedure to change the default trusted location to support HTTPS.

Important

Skip this section for environments that are not configured with SSL certificates (e.g. development environments).

To configure the Excel Services Application trusted location for HTTPS instead of HTTP:

1. On the Central Administration home page, in the Application Management section, click Manage service applications.
2. On the Service Applications tab, click Excel Services Application (where the Type column is Excel Services Application Web Service Application).
3. On the Manage Excel Services Application page, click Trusted File Locations.
4. On the Excel Services Application Trusted File Locations page, click the default trusted file location (http://) to edit the corresponding settings.
5. On the Excel Services Application Edit Trusted File Location page, in the Location section, change the Address from http:// to https:// and then click OK.
   

   Note

   Since users of the Fabrikam extranet site are automatically redirected from http:// to https:// during sign in (via the Claims Login Form Web Part), it is not expected that Excel Services will be used over HTTP (only HTTPS). If it is necessary to support both HTTP and HTTPS, then a separate trusted file location will need to be configured.

Configure the Office Web Apps cache

By default, when you install Office Web Apps, the cache available to render documents is 100 GB and the cache expiration period is 30 days. The cached content for Office Web Apps is stored in a SharePoint content database.

It is recommended to isolate the content database used for the Office Web Apps cache, so that cached files do not contribute to size of the “main” content database(s) for the Web application. Also note that anytime you create a new SharePoint content database, it is recommended to expand the initial database files (at least in a production environment).

Important

You must start a new instance of the SharePoint 2010 Management Shell after installing the Office Web Apps in order to use the new PowerShell cmdlets (e.g. Set-SPOfficeWebAppsCache).

Also note that you may need to wait a few minutes (after installing Office Web Apps or rebuilding the Web application) before performing the following procedure (for the SharePoint timer job to configure the cache on the site collection before moving it to a separate content database).

The following procedures are used to reduce the Office Web Apps cache size to 30 GB, move the cache to a new content database, and expand the corresponding database files.

To configure the Office Web Apps cache and create a separate content database for caching:

1. On the Start menu, click All Programs, click Microsoft SharePoint 2010 Products, right-click SharePoint 2010 Management Shell, and then click Run as administrator. If prompted by User Account Control to allow the program to make changes to the computer, click Yes.
2. From the Windows PowerShell command prompt, run the following script:

   $ErrorActionPreference = "Stop"
   
   Add-PSSnapin Microsoft.SharePoint.PowerShell -EA 0
   
   function ConfigureOfficeWebAppsCache(
       [string] $webAppUrl,
       [int] $cacheSizeInGigabytes,
       [int] $expirationPeriodInDays,
       [string] $cacheDatabaseName)
   {
       Write-Host ("Configuring Office Web Apps cache for Web application" `
           + " ($webAppUrl)...")
   
       Write-Debug "cacheSizeInGigabytes: $cacheSizeInGigabytes"
       Write-Debug "expirationPeriodInDays: $expirationPeriodInDays"
       Write-Debug "cacheDatabaseName: $cacheDatabaseName"
   
       $cacheSizeInBytes = $cacheSizeInGigabytes * 1024 * 1024 * 1024
       $webApp = Get-SPWebApplication –Identity $webAppUrl -Debug:$false
       $webApp | Set-SPOfficeWebAppsCache `
           -ExpirationPeriodInDays $expirationPeriodInDays `
           -MaxSizeInBytes $cacheSizeInBytes -Debug:$false
   
       $cacheDatabase = Get-SPContentDatabase $cacheDatabaseName -Debug:$false -EA 0
   
       if ($cacheDatabase -eq $null)
       {
           $cacheDatabase = New-SPContentDatabase -Name $cacheDatabaseName `
               -WebApplication $webApp -Debug:$false
       }
   
       Get-SPOfficeWebAppsCache -WebApplication $webapp -Debug:$false |
           Move-SPSite -DestinationDatabase $cacheDatabase -Confirm:$false `
           -Debug:$false
   
       Write-Host "Restricting the cache database to a single site collection..."
   
       $database = Get-SPContentDatabase $cacheDatabase
   
       $database.MaximumSiteCount = 1
       $database.WarningSiteCount = 0
       $database.Update()
   
       Write-Host -Fore Green ("Successfully configured Office Web Apps cache for" `
           + " Web application ($webAppUrl).")
   }
   
   function Main()
   {
       $webAppUrl = "http://extranet.fabrikam.com"
       $cacheSizeInGigabytes = 20
       $expirationPeriodInDays = 30
       $cacheDatabaseName = "OfficeWebAppsCache"
   
       ConfigureOfficeWebAppsCache $webAppUrl $cacheSizeInGigabytes `
           $expirationPeriodInDays $cacheDatabaseName
   }
   
   Main
   

3. Wait for the script to complete and verify that no errors occurred during the process.
4. Reset Internet Information Services (IIS) in order for the change to take effect:
   iisreset

To increase the size of the database files for the Office Web Apps cache:

1. Start SQL Server Management Studio and connect to the appropriate server.
2. In the Object Explorer, expand the Databases folder.
3. Right-click the OfficeWebAppsCache database and then click Properties.
4. In the Database Properties dialog, in the Select a page area on the left, click Files.
5. Using the settings specified in the following table, specify the new values for Initial Size and Autogrowth.
   

   Table 2 – Initial data and log file sizes

   Database	Logical Name	File Type	Filegroup	Initial Size [MB]	Autogrowth
   OfficeWebAppsCache	OfficeWebAppsCache	Data	PRIMARY	10,000	By 500 MB, unrestricted gerowth
   	OfficeWebAppsCache	Log	N/A	400	By 10 percent, restricted growth: 4,000 MB

6. Click OK.

The following SQL statements can be used as an alternative to setting the sizes through the Database Properties dialog:

USE [master]
GO
ALTER DATABASE [OfficeWebAppsCache]
MODIFY FILE(
    NAME = N'OfficeWebAppsCache'
    , SIZE = 10240000KB
    , FILEGROWTH = 512000KB)
GO
ALTER DATABASE [OfficeWebAppsCache]
MODIFY FILE(
    NAME = N'OfficeWebAppsCache_log'
    , SIZE = 409600KB
    , MAXSIZE = 4096000KB)
GO

Grant access to the Web application content database for Office Web Apps

Since the service account used to run the Office Web Apps service applications is different from the account used to run the application pool for the Web application, it is necessary to explicitly grant access to all of the content databases used by the Web application.

To grant the Office Web Apps service account access to the content databases:

1. On the Start menu, click All Programs, click Microsoft SharePoint 2010 Products, right-click SharePoint 2010 Management Shell, and then click Run as administrator. If prompted by User Account Control to allow the program to make changes to the computer, click Yes.
2. From the Windows PowerShell command prompt, type the following commands:

   $webApp = Get-SPWebApplication "http://extranet.fabrikam.com"
   
   $webApp.GrantAccessToProcessIdentity("EXTRANET\svc-spserviceapp")

Random Musings of Jeremy Jameson

.NET Info