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?

Are you looking for a login similar to JamJar (http://labs.adobe.com/techn... 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.

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.

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

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?

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.

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.

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!

When I post, please compare and let me know.

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.

Teddy,

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

Mike,
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.

Cheers,
Teddy

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.

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.

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. :)

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?

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.

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.

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.

DK