Mark Barton

Jake has been work hard on building some excellent Flex components which play nice with Domino.

One issue he has hit is with a bug in the Flash Player which means for non IE browsers session authentication is not sent with the fileupload HTTP Post.  This means currently only anonymous individuals can upload attachments on non IE browsers.  This of course could be a real problem for applications which require users to sign in – is there any that don’t?

To get around this I have been brainstorming an idea which hopefully gets around this problem.

My original suggestion was just to allow the post to go to a design element which allows Write Public access and have an agent do the actual attaching – a proxy service.  The problem is this HTTP Post could then be executed by anyone who could see the HTTP traffic – though the actual agent would expect a valid UNID and discard anything else, this in turn with the fact that this would only work for documents which an originally authenticated user could see (to get the UNID) mitigates the risk quite allot.

Still…

The following flowchart describes a process which should mitigate even that issue. 

It basically shows that the initial request to Domino is to a restricted agent to create a stub document which in turn returns the UNID of this stub document.  This stub document UNID is then used to post the attachment via the public access agent – this agent will then look for the stub document to complete the request.   No stub document then no attachment.

As a new stub document is created for each request (and then discarded) it shouldn’t be possible for anonymous user to reuse the HTTP Post.

Unobtrusive notifications are all the rage now in web apps (check out Google Chromes method for asking to remember passwords).  Rather than have an alert dialog which forces the user to lose context and actually click something to clear it, its sometimes better to have a notification which clears itself after a short amount of time.

The Mac has the Growl framework and Windows has the system tray.

For the web – JQuery has a plugin which seems to work well.

For Adobe Flex, though there are a couple of options kicking around, there was nothing which really suited my needs.  I therefore modified this one – http://afoucal.free.fr/index.php/2009/07/06/flex-notification/ – I wanted to simplify it so I stripped out the extra bits but left the core logic but the original author did all the hide work

The notification has the following features:

• Can be position top left, top middle, top right, middle left, middle,middle right, bottom left, bottom and bottom right.
• The message will display for 2.5 seconds (can be changed for each call) before clearing.
• Hovering the mouse over the message will force it to pause, clicking on it will clear it.
• You can optionally stack the notifications – on the demo try clicking the button more than once.
• The notification icon can be set for each notification call.

The result can be seen here on a demo page. – view source is enabled so you can download it.  The source consists of a CSS page, an example notification icon, 1 Actionscript class, 1 MXML component with some static methods (which means you do not have to instantiate the object first) and the calling demo MXML page.

In my example I have a showAlert method which in turn calls the static Notification.show method.  The properties for the show method are:

• The message to display
• The title
• Duration in ms – default(2500)
• Position of Notification – there are constants defined within the Notification component (default is NOTIFICATION_POSITION_TOP_CENTER)
• The NotificationIcon class – the demo has an example on how you might define this, remember you can define several and change the icon for each call to the Notification.
• Stackable – whether the notifications should stack – the default is true.

Finally took all of the advice given and took the leap to a Mac Book Pro.

Currently creating this weblog from MarsEdit – not as good as Windows Live Writer though.

Theres some odd stuff but so far loving it – I am basing my setup on Ben Poole with whom I have the pleasure to be working with.

Will try and give an objective view of the pros and cons once I have used it a bit more in anger.

Looks like Adobe has not waited for Apple to allow the Flash plugin on the iPhone.

This page describes a new feature in CS5 Flash Professional which allows any Flash game / application to be targeted at the iPhone.  NB Its actually created as a native application and published through the app store.

In conjunction with a new mobile Flex framework which is due 2010 it looks like it will not be long before our Flex apps are available on the iPhone and nearly every other mobile device.

Ferdy’s request for a decent video creation tool made me remember about Animoto. 

Animoto is one of those hip web 2.0 sites that does one thing very well.  It allows you to upload a series of your photos, add some text and either select a soundtrack or upload your own.   The result is a powerpoint / slideshow on steriods.

There is a charge if you want longer videos or to be able to download a DVD quality version but have a play with the free version and see what it comes up with.

Heres one I prepared earlier:

Just drop me a comment below and I will forward on the invite.

Its only open to US people at the moment so no good to me.

Invite now taken.

Got my invite to the Wave Sandbox and APIs.

Lets see how this bad boy plays with Notes – really interested to see if its possible to integrate Notes email / documents etc with Google Wave.

If you can’t beat them, join them!

There is some debate at the moment that suggest that over the shoulder password copying is not the problem it used to be and by obscuring the password using * actually deters people from using more complex passwords in the first place, it also goes against usability guidelines.

I recently had to create a login dialog for a Flex application – to log into Domino using Session based authentication and wondered if there was a better way.

I liked the look of this idea – allow the password to be entered in the clear but replace with * when the focus is lost.  This way if for any reason the dialog is left on the screen the password is obscured when your not actually entering it.

Heres a Demo. (a little slow to load but view source enabled)

Watch how the password is masked when focus is lost.  Out of interest if you attempt to login you will see the error message a user will see.

Another method might be to implement the iphone method – here as each password character is entered its displayed in the clear for a couple of seconds and then masked.

The timing couldn’t be better.  With Google trying to migrate Notes shops away with their automated tool, an employee of Twitter gets her Google Applications account hacked which results in lots of embarrassing documents getting published.

If you are serious about your data and email don’t use a cloud based system which allows anyone in the world to get your password via an online password recovery system.  Use a client server application like Lotus Notes

At the very least password / authentication issues should be managed by an in-house administrator.

Here’s an ideal opportunity for IBM to go after Google Apps and really push the security angle – I am sure they can come up with some great tongue in cheek adverts to do with Twitter, Google and lack of security.

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.

Basic Authentication

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.
• Jake
• Declan

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.

Form

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.

OnSubmit

When the submit button is clicked we use Actionscript to create a HTTPService which posts the username & password to names.nsf?login

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.

OnResult

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.

OnFailure

If Domino returns HTML -  because of a login failure we simply display an error message.

Session Timeouts

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.

The way round it would be to use the ExternalInterface to talk to Javascript and get it to check the cookies but for now we will just use an Actionscript timer to periodically call a Domino URL to keep the session alive.