A small update: when the first amf request is kicked off the response status is 200 OK but there is a Set-Cookie header set with new session id. Any ideas why it happens?
Thanks, Bartek --- In [email protected], "baardos" <[EMAIL PROTECTED]> wrote: > > Hi Dimitrios, > > I've checked it and the JSESSION cookie's name remains the same and > the path is '/' so theoreticly it should work fine... > > Thanks, > Bartek > > > --- In [email protected], "Dimitrios Gianninas" > <dimitrios.gianninas@> wrote: > > > > Your understanding is correct. My app works that way too... we have: > > > > https://someurl/falcon/login.jsp > > https://someurl/billing/billing.swf > > > > So user logs in and then at some point goes to the billing.swf and > everything works. If you try to access the swf directly all RO calls > fail. This is on Weblogic 8.1SP3. The login page uses j_security_check > as well. So same in your case... one thing to be careful of is that if > your login page and swf are under different contexts then you have to > make sure they have the same cookie name, or it wont work. Is that > your case? > > > > Dimitrios Gianninas > > RIA Developer > > Optimal Payments Inc. > > > > > > ________________________________ > > > > From: [email protected] [mailto:[EMAIL PROTECTED] > On Behalf Of baardos > > Sent: Thursday, December 14, 2006 9:03 AM > > To: [email protected] > > Subject: [flexcoders] Re: Form-based auth on Websphere > > > > > > > > Hi Dimitrios, > > > > Thanks for you anwser. Here I go with explanation. > > 1. I gave it a try and it works however Tomcat does not require this. > > 2. The login SWF could be just a HTML page with a form submitting > > credentials for j_security_check. The idea is to protect the core app > > in web.xml. In that way all resources are prottected: channels and > > the app itself. > > 3. My assumtion is that if a user is athenticated via container it > > should maintain its credentials and should associate them with its > > session. For a workaround in point 1, username and password can be > > stored in a SharedObject and than retrieved in the core app. > > > > It seems to me that when the user submits its credentials to the > > j_security_check they are not propagated to Flex. I've decompiled the > > WebsphereLoginCommand and by debugging it I can see that > > doAuthenticate method is invoked only if the setCredetials method is > > set explicitly. Is it the way it should work? How then Tomcat's > > behaviour should be explained - is it just a side effect? > > > > Cheers, > > Bartek > > > > --- In [email protected] > <mailto:flexcoders%40yahoogroups.com> , "Dimitrios Gianninas" > > <dimitrios.gianninas@> wrote: > > > > > > Things to try: > > > > > > 1) set the remote credentials on the ro in the core app for test to > > see if it works > > > > > > 2) why have two SWFs? > > > > > > 3) the second swf doesnt have a credential info to pass to the > > server and since you locked down the RO it is failing > > > > > > Dimitrios Gianninas > > > RIA Developer > > > Optimal Payments Inc. > > > > > > > > > ________________________________ > > > > > > From: [email protected] > <mailto:flexcoders%40yahoogroups.com> > [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> ] > > On Behalf Of baardos > > > Sent: Tuesday, December 12, 2006 9:28 AM > > > To: [email protected] <mailto:flexcoders%40yahoogroups.com> > > > Subject: [flexcoders] Form-based auth on Websphere > > > > > > > > > > > > Hi, > > > > > > I have a problem with FORM based auth on Websphere or rather what > > > happens afterwards when I a remote object calls a destination. > > > > > > To give some background: > > > The app is splitted in two applications (separate .swf files): > > > 1. login screen > > > 2. core app > > > > > > The core app is in protected area. When a user enters valid > > > credentials in the login app it is forwarded to the core app. Then > > > when a call to a remote object is made I am getting > > > Client.Authentication error saying "Login required before > > > authorization can proceed". > > > > > > I've noticed that if prior to sending a request user credentails are > > > set on the remote object (with setUserCredentials method) everything > > > works fine, however I think that it should not be necessary since the > > > server should maintain the credentials - at least it appers to work > > > that way when the app is deployed to Tomcat. > > > > > > I would be grateful for help. > > > > > > Best regards, > > > Bartek Doszczak > > > > > > > > > > > > > > > > > > -- > > > WARNING > > > ------- > > > This electronic message and its attachments may contain > > confidential, proprietary or legally privileged information, which is > > solely for the use of the intended recipient. No privilege or other > > rights are waived by any unintended transmission or unauthorized > > retransmission of this message. If you are not the intended recipient > > of this message, or if you have received it in error, you should > > immediately stop reading this message and delete it and all > > attachments from your system. The reading, distribution, copying or > > other use of this message or its attachments by unintended recipients > > is unauthorized and may be unlawful. If you have received this e-mail > > in error, please notify the sender. > > > > > > AVIS IMPORTANT > > > -------------- > > > Ce message électronique et ses pièces jointes peuvent contenir des > > renseignements confidentiels, exclusifs ou légalement privilégiés > > destinés au seul usage du destinataire visé. L'expéditeur original ne > > renonce à aucun privilège ou à aucun autre droit si le présent message > > a été transmis involontairement ou s'il est retransmis sans son > > autorisation. Si vous n'êtes pas le destinataire visé du présent > > message ou si vous l'avez reçu par erreur, veuillez cesser > > immédiatement de le lire et le supprimer, ainsi que toutes ses pièces > > jointes, de votre système. La lecture, la distribution, la copie ou > > tout autre usage du présent message ou de ses pièces jointes par des > > personnes autres que le destinataire visé ne sont pas autorisés et > > pourraient être illégaux. Si vous avez reçu ce courrier électronique > > par erreur, veuillez en aviser l'expéditeur. > > > > > >
