The right way to do this is to establish
single sign-on at the J2EE container level between your two deployed
applications. Depending on the state being maintained, storing that data
on the client using a SharedObject could be the worst solution in the world for
security reasons. In Tomcat you can use the crossContext attribute on the
connector to allow session state for authenticated sessions to be shared among
all of the web applications deployed in that engine. Macromedia even provides
documentation of deploying CF and using the crossContext attribute I’m
suggesting (other containers have equivalents- check your container’s
docs for more details): http://www.macromedia.com/support/coldfusion/j2ee/cfmx7j2ee_tomcat_deploy.html If you already have the apps in a single J2EE
instance as you’ve described, this solution is the right choice if you have
any data that is remotely sensitive in the session. For example, on some
of the apps I’ve been involved with here at Cynergy Systems we leverage
single sign-on extensively. Our web services are in a different web
context then the main application. When web service calls are made from
the Flex client, we don’t transmit any user data whatsoever. Instead,
the web service receives the raw data and turns around and asks Tomcat “Hey
Tomcat, which authenticated user is making this request?” and then uses
their credentials as managed on the server by the server to fulfill the
request. In architecture like this one, if someone should manage to hack
their way into your web services they won’t be able to get at any real
data because retrieves and updates ask the container for the user details, not
the caller. The only way around this is to obtain compromised login
credentials. Jason __________ From: Have you looked into SharedObject, if
you’re hitting the same domain that should allow you to share data across
SWFs. From: Hi,
SPONSORED LINKS
YAHOO! GROUPS LINKS
|