Policy based security in Flex – part II
10.07.08Filed Under: Flex with 3 Comments
Since writing my first article about Implementing Policy Based Security In Action Script 3 I have had the opportunity to create a live demo with source code available for viewing/downloading. This is to give you a better notion of how implementing policy based security for user interface components can make sense. No more of those monster data binding expressions which determine whether a user has access or not.
Having this kind of logic seperated into Simple ActionScript Objects, SASO‘s, (I’m sorry I could not resist to reuse the POJO catch phrase) which are simple to both understand and unit test. Unit testing and indeed understanding complex binding expressions or functions inline in MXML-code is hard when your application grows. Therefor making this kind of separation makes perfect sense.
In my previous posting I outlined how you could have stand alone classes for handling security. However the posting did not include a running sample as to how you would best implement the principles outlined. This posting comes with a more detailed description and a running sample with source code.
The Design
The implementation of the policy based security consists of three interfaces and an implementation class. Security policies are created in stand alone classes which are easily unit tested and gives you better control of what policies applies to performing certain operations in your applications.
The Policy interface has one method apply, which takes a criteria as parameter. Classes implementing this interface can be set on a class implementing the PolicyHandler interface. In the policy handler class all the “magic” happens. Based on the composed criteria, policies and targets.
Ease of use is important when writing library style components and the policy handler is design with this in mind. All you need to do in your application is to instanciate a policy handler class and then configure it with the required properties. Thanks to Flex’s data binding features the policies get applied whenever the criteria changes.
Using the policy handler
The implementation class, PolicyHanlderImpl of the PolicyHandler interface does all the heavy lifting and all you need to do is to pass it a callback function which gets called with the result of all the applied policies. In your callback method you can do make components appear/dissapear or enable/disable depending on the policy result.
public function applyToTargets(policyApplies:Boolean):void {
componentA.visible = componentA.includeInLayout = b;
}
...
<policyHandlers:PolicyHandlerImpl id="handler"
policies="{[AdminWidgetAccessPolicy]}"
criteria="{currentUser}"
callback="{applyToTargets}"
/>
The Sample
In order to make it a bit easier to review this way of securing access to parts of your application I have created a really horrible looking sample (can’t have a security sample which looks nice, that just does not seem secure enough) which shows the design in practice.
Pressing the button in the sample makes you change the current user between user A and user B. The policy in the sample ensures that only users with the role administrator sees the admin widgets. When looking at the source code, do not pay much attention to the lack of comments and nice coding. This is a quick and dirty sample code, not a best practice type sample.
In order to view this sample you must install the Adobe Flash Player.
View the sample in new window
View the source code
I appreciate all questions/comments, whether you think this is terrible or brilliant, just leave them over on the right.
UPDATE: Last night I detected an obvious flaw in my design, originally I had an abstract class which you had to extend in order to implement a new policy handler. In order to make using this design even easier I decided to have the PolicyHandler/ have a new method for setting a callback function which gets called after application of all the policies.
Test dirving user interface development
27.06.08Filed Under: work with 2 Comments
The other day I read an interesting posting on the Object Mentor blog called Observations on Test-Driving User Interfaces by Dean Wampler. He makes quite a few good points as to why applying TDD to rich internett application user interfaces is very hard. There are two reasons why TDD is not being performed when building user interfaces:
- a wrong perspecktive on the purpose of testing
- lack of good tool support with the correct perspecktive on testing
The purpose of testing
Most developers and test tool makers have a perspective of testing as an exercise where the object is to find defects. This is a perspective on things which led us to where we where a couple of years ago. With the introduction og eXtreme Programming and agile methods the perspective developers had on testing changed. Testing became an exercise which purpose was to prevent defects from entering your code base.
Testing as a way of preventing defects is a view shared by Lean Software Development and Mary Popendieck goes into details about this in her book Implementing Lean Software Development: From Concept To Cash. If you fail to convince your developers that this is the purpose of testing, I think you are going to fail at successfully working test driven. Testing to prevent defects is something which comes natural for interface developers as we have always been forced to continuously test our applications in numerous browsers while writing code. If this comes natural, how come test driven interface development is so hard?
The Tools
I agree with some of Dean Wampler’s points and I do think that lack of good tools might be part of the reason why test driving user interface development is hard. However I think the reason why the tool are inadequate is that they are created by people who don’t know enough or care enough about their target audience (to all of you who have written tools I apologize, but this is what it looks like from my point of view. If you are offended, just let me know and we can settle it off line). The tools for testing user interfaces tend to be intrusive, expensive and just too complicated to use.
Monster tools like Quick Test Pro are so complex (just installing this monster is a pain) that they exclude some users. Not to mention the ridiculous price tag on this software. However these things aside the tool itself is just not good enough to make it worth while for the people actually implementing the user interface. They do not want a tool where you write some code in some macro- or script language. They do not want a 3 GB tool to install with a limited number of licenses.
What they do want is a simple, free and easy tool to help them work faster and with better quality. A testing tool which not only helps in finding defects, but a tool which prevent defects from entering their code. A tool which is none intrusive and can be used while writing code.
This is where most tools get it wrong too. They are tools created to finding defects and errors in an application. Usually you record a test script and then run that script later on in order to find defects. What these kinds of tools fails to do is to give developers a way of working which prevent defects from entering their application.
One shining star
During my time as an interface developer I have only found one tool which actually allow you to work Test Driven and which enables the developer to work with preventing defects. The tool in question in is the free tool Selenium.
What makes Selenium so great is that it through it’s Selenium IDE provides developers with an actual tool which enables you to work test driven. By using the default view you can easily create simple test fixtures up front before coding and then run the test until the test passes. The Selenium IDE is a Firefox add on and hence fits naturaly into a user interface developers portfolio of tools. It’s small, portable and available on all platforms.
The way forward
I think the future for test driven interface development is very promising. Iterating and continuously testing is something which is in the blood of all experienced interface developers and I am certain that tool vendors will be capable of building tools which encourage test driven interface development.
The same small man. The same big mouth, but in a different tounge
13.06.08Filed Under: Misc with 0 Comments
If you’ve read anything on this blog you would probably have noticed that Enligh is not my native language. This is why I have always had two blogs in order not to have a confusing mix of English and Norwegian content on my blog. My Norwegian blog has been unavailable for some time due to the dallokken.com domain switching hosting provider to Media Temple, but it is finally back on line. It does not have a lot of new content on it unfortunately, but I am working on that and I will publish some things there. It will be a blog which is a bit more local to Oslo, Norway and most of the topics will be related to the Norwegian marketplace.
Those of you who speak Norwegian can enjoy my blog “her er mitt arbeid” and for those of you who do not speak Norwegian you can check out the Google translation.
Unit-testing and how little things have changed
12.06.08Filed Under: work with 0 Comments
This is actually a very old article which I wrote back in December 2006 over on my Norwegian blog. In an attempt to make that blog a bit less schizophrenic I thought I would move the English content over here. While looking at some of the old posts I think this one actually is quite good and I actually agree with my earlier statements from 2006 (which is quite unusual for me). Without further nonsense I here by present the old posting entitled:
Why Unit-testing has “nothing” to do with testing
I do not claim to be the master of testdriven developmen, but I have used a testdrvien approach for about two years now. What I have come to realize is that, for me as a programmer, my unit-tests are not most valueable as a way of testing.
Sound stoopid, right? Hold on! Do not stop reading, theres an explaination to this somewhat bizzare statement. What I mean is that my unit-tests help me in a lot of other ways which are actulay more benefical for me as a programmer.
New approach to an old technique
A few years ago I read the first edition of “Code Complete”, which is a great book. I picked up a few tips which helped me improve my speed and accuracy while coding. One of the things was first document what the method should do before the signature, and then “code” the method by writing comments for what you want it to do. By doing this you can more easily see if what you wrote in the method body corresponds to the documentation in the header for the method. You will notice if you need to refactor you method and you can detect logic errors before writing a single line of code. I found this technique to be very useful and it helped me improve the quality of the code and I produced fewer errors in my code.
Unit-testing introduced a more extreme approach which is somewhat simular. Testdriven development evangelists says “You must write you tests first”. This is a new spin to the method mentioned in “Code Complete” by Steve McConnel. By writing the test first you can see if your component meet the requirements, and you will also be able to detect design errors early. In addition you will also write better code for the actual method since it will only meet the requirements in the unit-test.
If you are not writing your tests first, you might as well just skip writing unit-tests. They will pretty much just test that the code you wrote runs, not if your component actualy does what it is supposed to. But, this topic has pretty much been covered by other people so I will leave it at that.
To recap: writing tests first helps me trap design and requirements errors early and improves code quality.
Having the courage to implement change
Refactoring is a word that some people love, and some people think is just a word used by consultants to make money off of their mistakes. Either way, we all know that we somewhere down the line will have to change our code. Nobody writes perfect code that never needs change, that is just a fact.
When the time comes for your component to change, what do you do?
Do you start to sweat and suddenly develop a spiritual conciousness, or do you smile and see this as an opportunity to make the changes you have been dying to do for some time? If you have been a good boy or girl and written your unit-tests you will be in the latter category. This is one of the reasons why I have come to embrace unit-testing. It gives me the confidence to perform required changes. My unit-tests gives me the sound foundation to perform every required change in my application. No more prayers like, “please please let this change be a good one” to the allmight “Runtime God”.
Going fast by never going back
I have seen people estimating more hours because they are doing unit-testing. This is in my opinion dead wrong. This would be equivalent of saying “I will use the IntelliJ debugger, and that will take me 4 hours”. Writing unit-tests should be a natural part of the craft of writing code, therefor it makes no sense to add hours to a budget “because we are gonna unit-test”.
By applying unit-tests in the way I have discussed earlier you will never use mour hours by adding unit-tests. That is because you will detect errors and trap design flaws earlier when writing tests up-front. You might spend an hour our two writing the tests, but you will also spend less time debugging your component. In other word you will go fast, by writing better code that you will not have to back and debug.
Again, this is actualy nothing new. Writing tests first is just a new spin to an old software developement “truth”: you will go faster by trapping errors early.
Summary
Unit-testing has more to do with writing code than testing in a traditional way. I see unit-testing as a tool for:
- Trapping errors in code and design early
- A safetynet when improving application designs by refactoring
- Better understanding of the problem domain at an earlier stage in the development process
2008 Update
Having lived and learned a little more over the past two years I think an update is required to what I wrote back when. Testing has another very important purpose which I did not see as clearly then. Which is that tests, if written in a good way, also acts as the best possible documentation about your problem domain and application. Allistar Cockburn mentions in his excellent book Agile Software Development: The Cooperative Game something that was originally written by XXX back in YYY about how documentation of projects is really difficult and the most important things are never put on paper. The most important thing is the “mental model” of those who developed the system. Without a knowledge of that model you will have a hard time taking over an existing project or adding new features to it.
I whole heartedly agree with this point and I think one of the places the model of the developers could be exposed is in the tests. By building a decent test harness you document how you want the system to work and you in turn expose some of the things you had to do when creating the application.
One example is lets say you had a bug which made you have to change your architecture a bit. Following the practice of TDD you would first write a test for this and in the documentation for the test method you would write a small entry about what this test does. Then you would make the architectural change until the test passes. This would expose to people coming in later reading your test code what the reasons for the test and what it solved.
Besides the fact that tests help document the mental model of the developers I think I would not change much in the original article.
throw new RuntimeException(“Blog post blog post”);
11.06.08Filed Under: Flex with 0 Comments
I don’t usually write about other people’s articles or write blog posts saying “read this great article”, but now I do. Read this great article called “ActionScript Collections and Functional Programming” by Bruce Eckel. It dives into details about, well you guessed it, collections and functional programming and how it relates to Action Script. Having done a bit of AS coding in the past few months I greatly appreciate this article as it dives into details about an essential part of any programming language, lists.
When you write code you are using collections of items probably without giving it much thought. This is why I think this article is great because it makes you think about how small things in something as simple as collections can have a big impact on your code. When working with Flex the small things do have a tendency to get forgotten while working with monster components like the DataGrid or by wresteling with frameworks such as Cairngorm. While we get caught up in all the hassel with these larger parts of Flex the small things tends to be forgotten and as a result we get more problems. I’d like to thank Mr Eckel for writing this article and reminding me that the little things do actually count and now I can not wait to get started on one of the latest books I purchased: Beautiful Code.
Reducing waste with poll based project communication
05.05.08Filed Under: work with 1 Comment
I learned about the Last F.M. developer setup when the two founders Matt Ogle and Anill Bawa Cavia when they talked at the Future Of Web Applications conference in London in 2007. In order to communicate with a distributed and ever increasing development team they used IRC as the basis of their communication. The IRCcat bot is a smart little guy who lets everyone know what is going on. By writing some smart pieces of code they where able to integrate information from Trac, Nagios and other tools used in development to enable everyone to have all information available when they wanted. I thought this was a very sweet setup back when I worked at Ezmo so I decided to try and use it in my next job. Therefor I decided to check it out on my Windows machine first.
Reducing waste and polling information
One important aspect of Lean Software Development is reducing waste and I think that reducing waste in project communication is very important. By removing the need for a lot of manual communication about server status or events occurring in the different development environments you remove a lot of waste. Another principle is that you should poll information when you need it instead of pushing it onto people. By using IRC you enable developers to poll information when they are actually developing by allowing them to connect to IRC when they are actually developing or giving them access to IRC logs if they need to see what went on while they where in a meeting. If you where to use IM software for this you would push information and it will feel a lot more intrusive for developers.
Installing IRCcat
- Download a Java JDK 1.5 or later, and point JAVA_HOME to this directory
- Download Ant and make it available in your PATH
- Download IRCcat
- Download the attached configuration file
- Run the command: ant -Dirccat-howto.xml run
- Viola! You should now see something similar to this:
Uhm, so what did I just do? Well, IRCcat is a service which basically dispatches commands to an IRC server. You can “talk” to IRCcat and then have it communicate to the IRC channel and all it’s listeners. This samples uses the IRCnet IRC network and connects to the channel #TWA-IRCcat-howto. Now connect to an IRCnet server with a regular IRC client (mIRC, Pidgin, etc) and join the channel #TWA-IRCcat-howto. In this channel there should be a bot called TWAcat.
What we now need to do is to send some messages using IRCcat. Doing this is most easily done by downloading a tool called netcat (more on netcat at Wikipedia) available on Unix and Windows. Unfortunately some virus protection software thinks netcat is a dangerous program and will prevent you from executing it, so you might have to stop any such applications when trying this out.
Having downloaded netcat and added it to your path you can now write the following command:
echo Hola el Mundo|nc -w1 localhost 9999
In your IRC client you should now see TWAcat say: “Hola el mundo”
Where to go from here?
What is cool about IRCcat is that it is very easy to write your own piece of code which reports statuses, errors, etc to your development team. This is really cool and I’m very much looking forward to see how this works out. Keep a lookout for upgrades by reading the journal on Last F.M and let me know if you have any problems with this sample.
