Maintaining Login Data in Flex
Tagged Under : Flex
User specific login information is usually stored in session variables in any web application. However, Flex doesnt have anything called session variables in it. So how do we save this information across the whole application. Static classes come to the rescue here. This can also be achieved by use of shared objects and Singletons but I am going to focus on static classes for now.
A static class holds the information in it once declared and is very useful for such scenarios. Typically, after you are done with the username/password authentication in your Flex app, you would need to store the data in a static class to be able to access it from anywhere in your application.
Here is how we do it:-
Once you have the class ready, you can use it to set the values. First , import the class you wrote in your mxml file.
Then, after you are done with your authentication process, you can set the values :-
and you can read this information anywhere in your application this way :-
or you can use the getInstanceMemento() or setInstanceMemento() to do the above in one go!
Obviously, you can expand this class to include a lot of other informaion related to the user e.g. email, phone, fax etc and use it wherever required.
| Posted by Anuj Gakhar in Flex
I’m a newbie to Flex - but why would you set the values directly instead of using the set function?
Ray, you are right. You can use both getters and setters and also the getInstancememento and setInstancememento functions to set or get data. I choose to demonstrate the setting of variable directly though. Its upto the developer really.
Ray, you could use getInstanceMemento to get Object instance instead of class instance if you need to send it to Java RPC (and you don’t map classes with RemoteClass). In this case in Java you’ll get Hashmap. You can do the same with CF RPC and CF web service.
You would also use setInstanceMemento while sending data in opposite direction. So you’re sending Hashmap from Java and you need fill your class. Instead of asigning properties one by one you could use setInstanceMemento().
Makes sense guys - thanks for the comments.
Comment 1:
In Flex, using an MVC framework, you could point your user class (AKA, a model or a value object) through the model. If you import the UserInfoClass (really a value object/model), you’ll start to have classes that point to model data with 100s of references.
As such, you could do this:
Import and bind the model in all of your command classes.
In your Model, you’d need to bind and define a reference to your UserInfoModel
Then, you’re model is centralized and points to subclasses, but the ‘model’ as a whole is accessible from anywhere.
Ex:
LoginCommand:
model.UserInfoModel.userName = loginEventResponse..userName
UpdateUserCommand:
model.UserInfoModel.userName = updateUserResponse..userName
Comment 2:
var o:Object =
The problem with using a simple object name is that it makes Find & Replace a nightmare, should you need to add more flexibility later.
Best to use var obj:Object = new Object();
You’ll find as your project scales that you’ll be adding obj1 and obj2 quite regularly.
I would also add for newbies reading this blog posting that the session information can still be stored in a coldfusion session scope. There’s no need for anyone to return the password, for the sake of discussion, back to the client.
David: sending password back shouldn’t be a problem as the password has to be sent from client to server
about Object: that is a big problem of AS3, basically it shouldn’t let you use Object in the way as it is right now. If you have to use it then use it only when you have to send data out of the client.
David, what you mentioned can be done in CairnGorm which I personally find a bit messy to work with. But if I were using CairnGorm, I would have done the way you suggested. I am happy with simple plain Flex without any frameworks though
Flex is a framework itself
@Radek
I’m probably too brief in posts. Sending passwords back and forth from the client presents a security risk. Namely, you would need to be concerned with user-sensitive information being viewed over the wire, and you would need to be concerned with session hijacking. The endorsed approached for password changing, for example, is to never pass the password back to the client from the server, but rather, to have the user send his old password and new password to the server from the client, where the old password is validated against the current password. If you pass the password back to the client each login, you’re exposing the user’s security risk for each login-request, which is probably going to be 100x greater than the initial “Create Account” request.
regarding objects:
When I pass parameters to CF from Flex, I always bundle them up. Also, in my command’s request, I might do some formatting or cleaning, but I always pass a single object for brevity. If you’re really lazy, it’s pretty kosher to pass a model as an object, in my opinion. You could pass a value object, too, for the sake of pure MVC fans, but a model and its instances will cast as an object:
@Anuj
Cairngorm is a bit tricky to work with, but it’s useful on larger projects. For me, with a project that has 10+ commands, there’s a wonderful simplicity knowing that by binding sub-classed models to my main Model, all I have to do is type:
model.[and all of the model attributes and subclassed models along with their attributes] are two selections through a list away.
Conceptually, the benefits are *tremendous*.
You, and everyone else, should always know the Mapped path to the data-stores, even if they are sub-classed.
If you don’t like it, Model-Glue for Flex is more forgiving and is similar to the Model-Glue for CF approach :
http://www.model-glue.com/blog/index.cfm?mode=entry&entry=0FBD76D2-3048-55C9-43D34471520B4215
the benefits are definitely there David and one day I will try Cairngorm or Model-Glue
I am sure it must be worth the effort. However, this post of mine was to demonstrate the use of static classes and how they can be used…..I understand your concerns about username/password security but ideally, static classes can be used for any reason if not storing user data.
Gotcha
Best,
DB