One of the strengths of Lotus Notes is its excellent security model and therefore when developing an Adobe Flex front end you want to leverage the inbuilt security but theres a few things to consider.
Flash Player Security
An important aspect of a Flex application (compiled to a Flash movie) is its ability to be hosted on any web server, this makes it ideal for integrating into an existing corporate intranet whether its running Apache, Domino or IIS. The drawback is the Flash Player has a sandboxed security model which prevents it from accessing data outside the domain which hosts the flash movie, in fact by default this is the same issue an AJAX based application would face.
To get around this it is possible to deploy a crossdomain policy file to root of the Domino Server – the HTTP sever root. This is normally Data\domino\html.
You can restrict this policy to specific domains or wild card it. Though we are not using Domino to serve the SWF file you still need to have the HTTP task running on the Domino server to allow communication between Flex and Domino.
If your writing an intranet application and either your Domino Server is already set to Basic Authentication or you can change it then this the easiest option. When your Adobe Flex application calls a secure URL on the Domino Server i.e. a URL which requires a higher level of access that anonymous has in the ACL, Domino responds with a standard challenge which Adobe Flex passes on and this in turn causes the browser to present its standard dialog. The IE8 one looks more fancy than previous versions.
Once authenticated with Domino the challenge will not be presented again unless:
- A higher level of access is required
- The URL called on the Domino Server is in a higher realm e.g. you call http://server/folder/db.nsf/view?openview first and then call http://server/db.nsf/view?openview
- You close the browser
So Basic Authentication gives you an automatic method for managing authentication and unlike session based authentication there is no timeout.
Basic Authentication Drawbacks
- Not a secure way of sending credentials to the server – if the HTTP traffic is sniffed you can read the username & password in the clear but for a ‘normal’ corporate application this might be enough. Unless your HR of course
- If you cancel the dialog or fail to authenticate its not easy to tell the difference between a normal HTTP error and an authentication error which results in a nasty error message.
- If your accessing multiple applications then ideally they need to be on the same server in the same folder.
In fact all the reasons why session based authentication was brought into Domino.
Session Based Authentication
For session based authentication we need to utilise the same techniques as we would for an AJAX based embedded login form. Calling a Domino URL which is protected by a session based authentication scheme would result in an error in Adobe Flex. We need to authenticate first.
There are already several tutorials around on the web on how to do this:
- Jerry Carter – shameless plug as I did this one with Jerry – its old and there are better techniques now.
What we need to do is produce an Actionscript version.
You can view the source here.
The example will not work as the Domino server it refers to its not accessible via the internet but it will give you the required code.
First we create a simple form which will capture the username and password. You could use this form either as an embedded login form or more likely as a popup window.
NB This form has no validation.
When the submit button is clicked we use Actionscript to create a HTTPService which posts the username & password to
Nathan pointed out that on Public facing servers the names.nsf would not be accessible to most users and therefore I have updated the code to perform a ?login on the application where your business logic would sit which makes sense.
– just like the AJAX examples, we also pass a redirect value to an XML page within our Domino application. This XML page will list all of the properties we want to capture about the current user e.g. Name, Role(s), Email…. etc.
We check the returned the result and because we specified the result format to be e4x it is straightforward to check the returned information is formed correctly – Domino will return HTTP information if there is a problem and not XML. If it is XML we pass the result object to a custom Actionscript class *CurrentUser *which uses the XML data to instantiate a CurrentUser Object. The Object is created as a global object within the Application.application scope so we can access it anywhere.
If Domino returns HTML - because of a login failure we simply display an error message.
Sessions will timeout if dormant– default is 30 minutes which means we have to keep the session alive if we don’t want any nasty errors occurring if the user leaves the app open for a long time without using it.
Ideally we would check for the existence of either a DomAuthSessID or LtpaToken cookie when a HTTPService object fails – if these don’t exist we would represent the login box. Unfortantly I can’t seem to be able to get to the HTTP Header to check for these cookies.