While working on a small test case for this, I realized what was happening. The pages beyond the Login screen have a security check that looks for a user_id variable (stored in the application model). When the user leaves the Flex app and then returns, the model variables are lost and so trying to go directly back to the page results in the user being redirected to the Login page.
So, I'm now storing some session info in the database then passing the session id back into the Flex app and having that re-establish the necessary model variables so that the user ends up back on the correct page. --- In flexcoders@yahoogroups.com, "Alex Harui" <[EMAIL PROTECTED]> wrote: > > Flex should reload the saved state. Can you create a small test case? > > ________________________________ > > From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of byte.sensei > Sent: Wednesday, November 28, 2007 2:37 PM > To: flexcoders@yahoogroups.com > Subject: [flexcoders] Preserving History when leaving and returning to > Flex > > > > I have History Management working on a Flex app (ViewStack), but then > I've got a NavigateToURL() call that leaves the Flex app and opens an > external URL. The problem is, when you click "Back" after leaving > Flex, it looks like the History Manager no longer works and it just > returns you to the default/initial state instead of the saved/history > state. I noticed the URL still has the state URL variables/data in > it (e.g. #app=a1ce&eac2-selectedIndex=4) but Flex seems to be > ignoring this URL data and just loads the default/initial state. > > Is there a way to have Flex reload the saved state when returning > from an external URL? > > To say this another way, assume the following path of a User: > > 1) Login Page > 2) Main Menu Page > 3) Product Category Page > 4) Product Detail Page > 5) External Product Link [NOT Flex -- uses NavigateToURL()] > > The forward/back buttons work fine between #1 and #4, but once the > user navigates to #5, the "back" button returns them to #1 instead of > #4 -- but I want to take the user back to #4. > > Note: one workaround to this would be to open a new window by > using "_blank" for the target of NavigateToURL(), but in my scenario > this is undesirable. >
