My Thanksgiving Flex Homework

This post is more than 2 years old.

So far my Flex apps have been very simple - a bunch of forms with remoting calls. Flex makes this very easy. I typically end up with just small problems of getting my layout just right, or making the format exactly right, but I honestly feel like I "get" Flex in terms of layout and controls.

In order to go a bit further in my skill set, I now want to figure out how to do the following:

  • On loading the Flex app, pop up a login screen. I know how to do something on load (I did this with my lemonade stand game). I also know that the remoting calls will be simple. Would this be better using states? States is something else I need more experience with.
  • Once logged in, I want my Flex app to work with my CFCs in an authenticated manner. Hopefully I can do this without using roles-based security in my CFCs, but I may start off with that approach to keep it easier.

I'll post as I work on this and share my findings. Hopefully I won't screw it up too badly, but I definitely welcome feedback on the code I end up using.

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by Teddy R Payne posted on 11/21/2006 at 9:05 PM

I need to research this as well. Though, I am curious about your approach to accessing your CFCs in a security model. Do you only want certain roles to execute certain CFCs or do you want to use Flex to prevent executing certain options based upon your role?

Comment 2 by todd sharp posted on 11/21/2006 at 9:10 PM

Are you looking for a login similar to JamJar ( Maybe one of the folks who created that could share the code? I'd be interested to see what you come up with either way.

Comment 3 by Raymond Camden posted on 11/21/2006 at 9:10 PM

The idea for security is - Flex is invoking a remote process, lets say AddUser. I don't want anyone to be able to do that - just authenticated users. Normal, simple, application security I'd call it.

Comment 4 by todd sharp posted on 11/21/2006 at 9:12 PM

Here's a very interesting article: http://livedocs.macromedia....

Comment 5 by todd sharp posted on 11/21/2006 at 9:14 PM

As far as security, I've been puzzled with that same issue in my applications. Is it enough to simply disable or hide the controls which would invoke the "addUser" method based on the authenticated role?

Comment 6 by Raymond Camden posted on 11/21/2006 at 9:16 PM

To be clear - I don't want someone to TELL me how to do it. I want to find this out on my own and share my bumbling results with others. :) In other words, this is a learning exercise I want to share. At the _end_ I want folks to go crazy on the code though.

Comment 7 by Raymond Camden posted on 11/21/2006 at 9:18 PM

Todd - that is an excellent question. For this experiment, I am not going to worry about roles. I basically just want a login screen on the front end, and a back end that ensures the calls are authenticated.

For now - I want it to be nice and simple. But your question definitely needs to be addressed.

Comment 8 by Mike McConnell posted on 11/21/2006 at 9:56 PM

I wrote a VERY crude and basic administrative interface to your blog software several weeks ago, coincidentally, to experiment with precisely these two application areas (login and security/authentication verification once logged in). I think you'll find it as easy as other areas of Flex you've learned thus far. I'm convinced you can do virtually anything you like in Flex if you're willing to do a little research and experimentation.

Have fun!

Comment 9 by Raymond Camden posted on 11/21/2006 at 10:09 PM

When I post, please compare and let me know.

Comment 10 by Teddy R Payne posted on 11/21/2006 at 10:17 PM

Say you have a button that fires "AddUser," do you want to prompt for the login when you click the event or do you make the button available after you login? I would be curious to see the opinion on that questions. To pre or post authenticate Flex and what is the advantage of one over the other.

Comment 11 by Mike McConnell posted on 11/21/2006 at 10:40 PM


My opinion on your question is formed by experience with the typical application user. We have several conventional 32 bit client-server applications in our enterprise environment. All require an initial login and some require additional levels of login based on the function you're trying to access. The latter scenario represents a true pain in the butt for the user. I think an application should be smart enough to take the initial login and apply it as necessary throughout an application. Users HATE (and that is not too strong a word to use in this context) to log-in to anything. Exceptions to the single login model might be where extremely sensitive financial or personnel data are being accessed. You might want, or need in the presence of government regulation, a secondary authentication scheme to serve as an electronic PIN or e-signature (since user name and password combos in the typical business environment are generally not that hard to guess).

M. McConnell

Comment 12 by Teddy R Payne posted on 11/21/2006 at 11:31 PM

I agree that users dislike logging in. Also, I was not thinking of multiple post-authenticating event. Hell, that would seriously upset me as the developer to enforce it. I was more playing to activating a post authentication process after you hit a private method. Once you authenticate the private method, you would not have to log in again after that.

I was just curious if anyone has seen any success with a lazy login idea. Login when you need to and not up front.

It was just my curious mind spitting out the abnormal.


Comment 13 by Mike Rankin posted on 11/22/2006 at 12:24 AM

I've definitely gone the states route. My simple login has grown to include registration, password retrieval, token entry (to reset a forgotten password) and password changing.

It works great and feels really natural in terms of user interface.

Comment 14 by Michael posted on 11/22/2006 at 12:35 AM

I too will be working on security in Flex this weekend. I need to go a bit more complex though as I have 2-4 different roles I need to code for. It was nice to read some ideas, and I am looking forward to see what Ray comes up with.

Comment 15 by Raymond Camden posted on 11/22/2006 at 12:39 AM

I have the first part done - the just "show logon make it go away" crap using states. It was my first time really using states and well.... read the blog entry tonight. :)

Comment 16 by todd sharp posted on 11/22/2006 at 12:59 AM

The example apps using states that I've seen confuse the hell out of my feeble mind. Seems too complicated for such a simple task.

The concept seems similar to a ViewStack (which seems easier to implement) - can anyone clarify the diff?

Comment 17 by Mike Rankin posted on 11/22/2006 at 1:13 AM

I think the viewStack and states are very similar. The transitions between states are a bit easier in my opinion. I think the biggest difference, is one of how you think about the application. I tend to think of states as being variations of a single custom component. When I think of the view stack, I think more in terms of web pages.

Also, the wysiwyg portion of fb2 comes in real handy with view states. I'm sure there are lots of other differences that I can't think of at the moment.

Comment 18 by Nick Kwiatkowski posted on 11/22/2006 at 6:27 PM

States are the way to go -- just remember, each component you have can have it's own states too... so you can have components that have states within states themselfs.

Comment 19 by Douglas Knudsen posted on 11/26/2006 at 11:38 PM

coming in late here...several ways to skin this cat. First time I did this was using Java on the back end, easy to invoke JAAS this way. 1.5 days then :) anyhoo, remoting calls are over http and act just like any .cfm call with respect to sessions. On the Flex side, one approach is to take advantage of binding. Set a 'global' var isAuthed then simply bind to it. Note that decisions can be made in the binding.