Here are a couple of options I'm considering; 1.) When a page is being generated under an active session that contains a full screen Flex application (all interaction is with the Flex application), set the session lifetime to infinite. When a user leaves the Flex application page, restore the session lifetime to the pre-Flex setting. So, if a user leaves a page with a full screen Flex app and enters a non-Flex page, the session lifetime would be restored to a reason value (consistent for the entire site).
2.) Create a session/cookie with a token indicating that an application is in use. When the user leaves the application, unset the token. When validating a session, if it has expired, check for the token. If the token exists, generate a new session. This option may have security issues and assumes cookies are enabled. Both options allow the flex application to exist without concern for sessions. Between the two, I'm leaning toward option 1. This fits the need while not requiring a heartbeat from the application. Are there issues associated with either of these options that need to be addressed? Do you have other ideas? --- In [email protected], "wubac1" <wub...@...> wrote: > > I'm hoping someone can shed some light on a design issue I'm facing. If I > have a sign in form external to Flex, but it controls access to the Flex > application, what are the best practices for maintaining the session when the > user is interacting with the Flex application? I can provide the Flex > application the session ID, but what do I do with it to ensure that the > session does not expire while a user is working in the application? I'm > using web services, so I wonder if I should be checking the session at the > point. For example, if I have a PHP-based website hosting an adobe Flex > application, with a PHP sign in form, what should I be doing with regard to > Flex, if the application uses web services outside of PHP (such as gSOAP, > Axis2/C, or one of the various Java options)? > > I can see how this would work if the Flex application used PHP as the > back-end, since all communication would go though a single source that > manages the session. However, what I don't understand and have found little > with regard to answers on the subject, is how to integrate a Flex application > that utilizes an alternate back-end from the hosting website. I'm my case, > the alternate back-end is in the same domain, so I suspect there should be a > way to share the session information between PHP and other services such as > web services in gSOAP. Has anyone faced this design issue? Thoughts on an > appropriate solution? Is this approach worth the trouble or should I be > calling PHP that then routes requests to the web services (or implements the > service)? > > A visualization: > > PHP login --> PHP back-end --> database > | > | > Flex <-- (PHP returns page with Flex Application) > --> web service (non-PHP; but same domain) --> database >
