2008-10-15

Going to MAX 2008 in San Francisco

Well good news today from my manager, I am going to MAX 2008 in San Francisco! Already registered, just have to pick my sessions now, which I will do in the coming days and hopefully I can book a trip to Alcatraz as well :)

2008-10-14

Single Sign On (SSO) with Flex in J2EE container

I've saw this question asked a couple times about a month ago and I tried to answer the question but thought it best to create an example. The question is, how do you prevent a Flex application from showing the login page after the user hit F5 in the browser (or refresh for that matter), after he/she just logged in.

So the main question here is how do you know someone has logged in successfully and don't need to present them with a login view. This is also how to handle the Single Sign On (SSO) case, where you know the user has authenticated himself successfully under host.com/app1 context but is now at your Flex application under the host.com/app2 context and you don't want him to have to re-authenticate himself. Of course we talking here about a Java back-end, so either using BlazeDS or LiveCycle Data Services.

So in my example I used BlazeDS and assuming you configured the security properly, a typical Flex application will display a login view to the user before they can do anything. But if the user has already been authenticated in this web context or another context on the same server, how do we prevent this default behavior? Here is how I do it in some simple words.

When the LoginView initializes, call the server to load the user's information (you will most likely need it at some point anyways). If you get a success response, you have the data and it means the user is already authenticated, so broadcast the LoginSuccessEvent event and you are done! The application will now display its main content. If you get an error response, the most likely cause is that the user is not authenticated and you should remain at the LoginView. It could also mean there is some server-side error (like config issue) which your technical department will have to look into.

If you do have to present the user with the LoginView, then once they click on the Login button, call the setCredentials() method of your RemoteObject and then make the same call to load the user's information.

But there is no better way to see this than to look at an example. So I recommend you download my example using the link below and take a look at the LoginView.mxml file where most of the work is done. The example deploys easily into Tomcat, so I recommend reading the readme.txt file contained within the archive for some installation details. The complete source is included as well.

You can download my example from here. Enjoy!

2008-10-12

AIR error 3122 and 3125

Was just working earlier this week on a little AIR application for my own use and I got stumped at one point while using it. The AIR application makes use of the local database and I was unable to update a record; I was repeatedly getting error 3122 during the save operation. After looking up the error description I figured out it was because the database file was read-only. It was because the file was in the application directory, also note this is on Windows Vista (I don't need to tell you about UAC!). I made the file modifiable, but now was getting error 3125. Error 3125 states that the OS simply won't let you update the DB in any way, and I figured it was Vista not letting me do the update. So I moved the file to my documents directory and it worked fine.

So be careful during an installation of a mission critical AIR application, make sure you place your database file somewhere where it can be worked with; either in the user's document directory or in the application storage directory. Especially important on Windows Vista.