This content has been marked as final. Show 8 replies
Clearly, the server is sending out an HTML login form. This sounds like the behavior of "basic" authentication in J2EE. Perhaps you need to configure the server to use "custom" authentication?
Or let the user log in with the html form, and then call the flex app?
This is well outside my experience so I don't know what to suggest. Sorry.
Thanks for the reply. The wierd thing is when I set it to basic auth (thats when just the login window pops up) it works fine. But when I set it for form on the web.xml file it doesnt work. I have read that when you use remote object services you need to specify what auth to use but this app is using httpservice which from what I can tell you don't need to do that.
ps thanks for you help on the data refresh problem i was having before!
The powerhouses at Cynergy monitor this forum, perhaps they will be able to help you some more. In the meantime, try searching the archive here for "basic" and "custom" and "authentication".
In your code, this is not alid in XML - action='j_security_check' . It's supposed to be
something about autentication :
When a destination is not public, you can restrict access to a privileged group of users by applying a security constraint in a destination definition in the Flex services configuration file. A security constraint ensures that a user is authenticated, by using custom or basic authentication, before accessing the destination. By default, Flex Data Services security constraints use custom authentication.
Basic authentication relies on standard J2EE basic authentication from the web application container. To use this form of authentication, you secure a resource, such as a URL, in the web application's web.xml file. When you use basic authentication to secure access to destinations, you usually secure the endpoints of the channels that the destinations use in the web.xml file.
The following example shows a configuration for a secured channel endpoint in a web.xml file:
As an alternative to basic authentication, you can use custom authentication and create a custom login form in MXML to match the appearance of your application.
For custom authentication, Flex uses a custom login adapter, known as a login command, to check a user's credentials and log a principal into the application server. A login command must implement the flex.messaging.security.LoginCommand API. You can register multiple login commands in the security section of the Flex services configuration file. The server attribute of the login-command element is used to perform a partial match against the value returned by the servletConfig.getServletContext().getServerInfo() method. The server value must be a case-insensitive match of an initial substring of this value or the entire string.
You can use a login command without roles for custom authentication only, but if you also want to use custom authorization, you must link the specified role references to roles that are defined in your application server's user store.
Flex Data Services includes login command implementations for Adobe JRun and Apache Tomcat, Oracle Application Server, BEA WebLogic, and IBM WebSphere, as the following example shows:
its like HTMLWrapper in Flex and SSL
PRB: Security Warning Message Occurs When You Browse to a Page That Contains an IFRAME Through SSL
This occurs when the page contains an IFRAME that does not specify a SRC attribute.
Anatomy of a Flex MXML Request
Note that these references pass through the flex-internal path, which is a servlet mapping provided by Flex. These three components that implement the History Management feature are built into Flex, and the developer need not worry about providing or modifying them.
A simple example is shown here. This mxml code provides a panel having three tabs, each with different content. The user can click through the tabs, and then use the back button to return to previous views of the tabbed panels. Also provided below is a summary of the HTTP traffic that occurs when navigating this rather trivial application. Note the 4 initial HTTP Request/Response pairs, followed by requests for history.html and action=swf, which continue to be trafficked when as the user navigates the application.
Also note that in ACTION 6 below, which represents the user clicking REFRESH or F5 in the browser, the primary SWF for the Flex application is not sent across the wire again, but rather the Flex server returns a 304 status code for Not Modified, which reduces load on the server. This behavior is occurs when Flex is configured for production mode=true. Production mode for Flex is similar to Trusted Cache in ColdFusion because Flex will not check to see if the mxml source has been modified, and rather just serve from the content cache. Dynamic behavior is maintained in the Flex application by HTTP Service, WebService, and Remote Object callbacks, as well as client-side ActionScript.
just check this link for the example:
i hope it would clear ur doubts.