My Thanksgiving Flex Homework
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.
Comments
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?
# Posted By Teddy R Payne
| 11/21/06 10:05 AM
Are you looking for a login similar to JamJar (http://labs.adobe.com/technologies/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.
# Posted By todd sharp
| 11/21/06 10:10 AM
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.
# Posted By Raymond Camden
| 11/21/06 10:10 AM
# Posted By todd sharp
| 11/21/06 10:12 AM
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?
# Posted By todd sharp
| 11/21/06 10:14 AM
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.
# Posted By Raymond Camden
| 11/21/06 10:16 AM
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.
# Posted By Raymond Camden
| 11/21/06 10:18 AM
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!
# Posted By Mike McConnell
| 11/21/06 10:56 AM
When I post, please compare and let me know.
# Posted By Raymond Camden
| 11/21/06 11:09 AM
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.
# Posted By Teddy R Payne
| 11/21/06 11:17 AM
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
# Posted By Mike McConnell
| 11/21/06 11:40 AM
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
# Posted By Teddy R Payne
| 11/21/06 12:31 PM
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.
# Posted By Mike Rankin
| 11/21/06 1:24 PM
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. :)
# Posted By Raymond Camden
| 11/21/06 1:39 PM
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?
# Posted By todd sharp
| 11/21/06 1:59 PM
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.
# Posted By Mike Rankin
| 11/21/06 2:13 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.
# Posted By Nick Kwiatkowski
| 11/22/06 7:27 AM
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
# Posted By Douglas Knudsen
| 11/26/06 12:38 PM