Home Tutorials Forums Articles Blogs Movies Library Employment Press

Go Back   ActionScript.org Forums > Flex > Flex 2, 3 & 4

Reply
 
Thread Tools Rate Thread Display Modes
Old 01-19-2010, 04:27 PM   #1
scripter73
Registered User
 
Join Date: Apr 2009
Posts: 10
Default Trying to Understand Login and State Management

Hi,

I'm relatively new to Flex 3. I'm using the builder.

Here's my core problem. I'm coming from a ColdFusion background, where users run to the server for any type of authentication and sessions rule until they're timed out.

My goal is to understand how ColdFusion (with a SQL Server backend) and Flex work together to help a user login and helps that same user maintain it's state.

I understand so far that Flex can use a RemoteObject to go back and use ColdFusion services to authenticate a user. I'd like to go this route.

My problem is understanding how does Flex maintains information about the particular logged in user. Am I correct in thinking that once I return information from ColdFusion about the user, I create a global object in Flex that keeps the user's information that I can refer to as I transition between the View States (states) in my Flex application? And I can just refer to that local user object if I need to make sure I'm still dealing with the same user?

Is it really that simple? Also, I've had been trying to review COUNTLESS articles on the Login/Authentication process. One that I came across suggested placing a UUID on the server for a particular logged in user, and then I just return that back to Flex. Does anyone recommend that? I know that when I used sessions in ColdFusion, the server did this, so I'm not sure which routes to take.

By the way, I'm designing an Intranet that's only accessible from our internal network, but I want my colleagues to be able to login securely. And like I said before, I'm using ColdFusion (and CF services), SQL Server, and Flex 3.

I'm teaching myself Flex, but if someone could provide a good outline of the Best Practices to Login, Authenticate, and Maintain Session State throughout a Flex Application (using a ColdFusion and SQL Server backend), I'd be highly appreciative. Thanks!

scripter73
scripter73 is offline   Reply With Quote
Old 01-20-2010, 04:12 PM   #2
NoobsArePeople2
Gamefun Engineer
 
Join Date: Nov 2009
Posts: 233
Default

There's a couple ways to go as far as maintaining state.

If you're using something like Cairngorm you could just keep state on the ModelLocator for your app.

Probably a better solution would be to used a SharedObject, basically the Flash version of a cookie.

As for an actual session management system, I cannot really offer any advice.
NoobsArePeople2 is offline   Reply With Quote
Old 01-20-2010, 04:27 PM   #3
Barna Biro
Senior Member
 
Barna Biro's Avatar
 
Join Date: Nov 2009
Location: LU, Switzerland
Posts: 1,410
Default

I don't really see why you want to handle any state on the client side. The client shouldn't really care or know about sessions... the server should be responsible for keeping a session alive or closing it if requested / expires.

For example: you have an application that allows logged in users to upload photos. The user logs in, a session is created ( let's say it expires after 1 min ) for him and a "success" response is sent back to the client ( it can also contain some info that you can display about the user... like First Name, Last Name, Username and so on ). Ok, now, the user attempts to upload a photo... he chooses the file, and hits the Upload button... A request is sent to the server... The server catches the request, checks if a session is still open for the user that made the request ( checking the username maybe, or whatever else you want ). If a session is open, the upload is made.

Now, if the user sits still for more than 1 minute, the session will expire ( the server handles the expiring ). If he'll now attempt to upload a new file, then once the server catches the request, it sees that no session are open for user X... as response, the server throws a warning message ( or any other type of message ) to signal that the user is not logged in and that the operation can not be executed.

You obviously catch the response from the server on the client and display a warning.

Maybe I'm missing out on something, but I don't see why you'd want to keep track of an authentication state on both the client and the server. IMHO, the server should be responsible for such things.

PS: If the server tells the client that the user is not authenticated anymore, you can simply clear the object holding the previously loaded user information and force the user to login if he wishes to continue.
__________________
Titus M. Plautus - Not by age but by capacity is wisdom acquired.
Barna Biro is offline   Reply With Quote
Old 01-20-2010, 04:59 PM   #4
NoobsArePeople2
Gamefun Engineer
 
Join Date: Nov 2009
Posts: 233
Default

I read it as keeping track of user info not authentication state. In your example the client would need to keep track of the user's name so he could be authenticated at the server. So he'll need to keep something on the client to connect the user to a session.

I agree, let the server handle sessions and authentication, just keep whatever user info is need to authenticate on the client.
NoobsArePeople2 is offline   Reply With Quote
Old 01-20-2010, 06:30 PM   #5
scripter73
Registered User
 
Join Date: Apr 2009
Posts: 10
Default Implementation of Server State Management

Hi Noobs and Barna,

Thanks for the information.

Ok. I get your point. I think it's fairly simple enough to handle the session on the ColdFusion side, but will I really be able to send a flag to the client after that session times out? I thought the Flex app was independent of the server. I guess I'm having a hard time understanding how CF will know if there's no user activity, etc.

For example, let's say my timeout is 1 min and the CF server hasn't received any requests, etc. Since this is an intranet, my user may just be looking around the site, etc., but how would CF know that.

Oh, by the way, I'm working my way through Bruce Phillips' code and logic in his tutorial:
http://www.brucephillips.name/blog/i...Backend-Part-1

So that's where I was getting the CreateUUID().

I guess I have alot more reading to do.

Thanks for your help.
scripter73 is offline   Reply With Quote
Old 01-20-2010, 06:35 PM   #6
Barna Biro
Senior Member
 
Barna Biro's Avatar
 
Join Date: Nov 2009
Location: LU, Switzerland
Posts: 1,410
Default

@NoobsArePeople2: Sorry, I didn't read your reply correctly then. Well, if you only want to keep user information, then simply store it in a variable and that's it. In case you are using an ApplicationManager type class, or something similar, you can keep the info there and access it whenever needed.

I see no point in complicating this with SharedObjects and who knows what else. Just store the information you need in an object and that's it. The way you will access that object is totally up to you.
__________________
Titus M. Plautus - Not by age but by capacity is wisdom acquired.
Barna Biro is offline   Reply With Quote
Old 01-20-2010, 06:49 PM   #7
Barna Biro
Senior Member
 
Barna Biro's Avatar
 
Join Date: Nov 2009
Location: LU, Switzerland
Posts: 1,410
Default

Quote:
but will I really be able to send a flag to the client after that session times out
I'd only see a need for the server to force some sort of operations if this would have been a collaboration type application ( "real-time" ). Where multiple users can interact with each other and everyone would see the same screen, no matter who changes something.

Quote:
For example, let's say my timeout is 1 min and the CF server hasn't received any requests, etc. Since this is an intranet, my user may just be looking around the site, etc., but how would CF know that.
This is totally up to how you plan and build the application. To be honest, I don't see why you'd want to limit someone from all actions, even if he's session expired. I'd only warn people about the session expiry if he'd want to access a section of the site that needs to read data from the server that would require the user to be authenticated.

If you build the application in manner so that most of it's parts ( even the "just looking around" part ) would read the content / data dynamically but this data access would required that the user is logged in, then I don't see why you'd want to explicitly warn the client in the exact moment when the session expired on the server... The user could simply just start the application, go buy coffee and come back after 20 minutes... Why would you want him come back to a screen with warnings popped up everywhere saying that his session expired? Maybe he'd close the application anyway because he has better things to do... Personally, I'd only warn him once he starts to interact with the application and the data he is trying to access requires that the user is authenticated ( you could have tools / widgets that might be helpful to the user but wouldn't require any communication to the server... like a "calculator"... why warn him that his session expired when he'd only want to calculate how much money he has left after buying a coffee < an operation that I don't see why would require the user to be authenticated >? ).

I hope I was somewhat clear in my explanations I don't have too much experience with CF ( I usually work with Spring + BlazeDS ), so I can't say for sure if CF can force calls to the client ( warn the client without the client actually asking for something... I'm guessing that it has some support for this, but that's just a guess )... but again, I don't see any reason why you'd want to complicate things and do something like that.

But in the end, it's your application, so it's your decision to take

EDIT:

Quote:
I thought the Flex app was independent of the server.
Totally depends on how you build it. In "real life" no client is "independent" of the server it works with. Because, well, without the server, it's not likely for it to remain functional... so it can't be independent if it's functionality depends on the existence of a specific server. But yeah, you could build "independent applications" that don't communicate with servers and store all the data within... like a static website.
__________________
Titus M. Plautus - Not by age but by capacity is wisdom acquired.

Last edited by Barna Biro; 01-20-2010 at 07:08 PM.
Barna Biro is offline   Reply With Quote
Old 01-20-2010, 08:05 PM   #8
scripter73
Registered User
 
Join Date: Apr 2009
Posts: 10
Default Thanks Barna

Thanks for the additional information, Barna. I really appreciate it.

I'm going to take your advice and use just the object for now, until I get my feet wet. This will be my first App.

Really, most of my intranet is not secured, but this additional piece will allow my colleagues to login to see their hourly information, which is sensitive. So I'm not going to worry about timeouts, etc. I'll just check the application variable on the client side to see if they're data is there. If it is, great, I'll show them their info. If not, they'll have to login again. And I'm not going to worry about sending UUIDs back to my SQL Server database through CF. I was just wondering because I saw it in Bruce Phillips' tutorial.

Thanks for everything.

Best regards,
scripter73
scripter73 is offline   Reply With Quote
Old 01-20-2010, 08:27 PM   #9
Barna Biro
Senior Member
 
Barna Biro's Avatar
 
Join Date: Nov 2009
Location: LU, Switzerland
Posts: 1,410
Default

If you want an UID to identify the user ( which, frankly is a bit better then using the username ) then simply use the primary key of the user table. Whenever you'll add a user, the primary key will auto-increment... so each user will have a unique ID. If you want to find a user in the DB, simply use it's ID to find it ( it's a common practice ).

I didn't take a close look at the link you have posted ( too tired for that now ) but from what I saw, the tutorial did not talk about security. Since you'll be working with sensitive data, it would be nice to spend some time on learning about security issue too. Storing passwords as they are is definitely not cool... you should store the password as a hash.

Also, I didn't say you should leave out timeouts if you think they'll come in handy. Timeouts are totally ok, what I was trying to say is that don't waste time trying to find a way to warn the client immediately once the session expires... instead, just wait until the client asks for some info from the server that is more "sensitive" and that would require the user to be authenticated ( or any kind of info that requires that the user is authenticated ). Once he makes the call, you can verify if he is still authenticated on the server ( by checking if a session exists for that user )... if he's not authenticated, you warn him, else you continue with the operation and give him the needed information.

Best wishes,
Barni
__________________
Titus M. Plautus - Not by age but by capacity is wisdom acquired.

Last edited by Barna Biro; 01-20-2010 at 08:29 PM.
Barna Biro is offline   Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 06:50 PM.

///
Follow actionscriptorg on Twitter

 


Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Ad Management plugin by RedTyger
Copyright 2000-2013 ActionScript.org. All Rights Reserved.
Your use of this site is subject to our Privacy Policy and Terms of Use.