I'm still looking for a solution on this. Paul, or anyone else... is there any further information?
My users are reporting that, even if they enter their login information again, sometimes the file upload just sits and hangs... so this seems to be a larger problem than I thought. I *need* the file upload request to be seen as authenticated from the get-go so there is no second authentication challenge. Thanks again, -Carl --- In flexcoders@yahoogroups.com, "carl_steinhilber" <[EMAIL PROTECTED]> wrote: > > Thanks Paul, that's GREAT information. > If URL-rewriting is "a pain" and only works "in some cases"... I'm not > really sold on it, especially since I believe it would take an act of > congress for our IT folk to set it up on the server. > > Sending a token seems to me to be a much more manageable idea, since I > could set it all up myself and I'd be in charge of my own destiny. > > But I am a little confused. You mention having another request to grab > a token. How does *that* request get authenticated? And once the token > is acquired, doesn't it need to be sent in the upload request in a > specific header to establish that it's authenticated? How is that > possible? > > Any further insight would be greatly appreciated. > > Thanks again, > -Carl > > > --- In flexcoders@yahoogroups.com, Paul deCoursey <paul@> wrote: > > > > This is a bug that I have reported before. The upload request does not > > share the session with the other requests on the system. ie, cookies > > are not sent that have not been set by any other upload requests. In > > some cases I've been able to use URL-Rewriting to share the session, > but > > it's a pain. My solution has been to allow unsecured uploads by > > supplying a token to the request. What I do it have another request > > that is on the authenticated session request a token, we use a UUID > > generated by the server. We pass that in as a parameter on the upload > > request and that server side handler will then map that request to the > > correct session. We use tokens because we can expire them after a > > single use. We had trouble with url-rewriting because by default all > > the servers we were deploying on did not have that enabled by default > > and some clients just didn't want to support that. > > > > Really url-rewriting for session management should do it for you. > > > > Paul > > > > > > carl_steinhilber wrote: > > > I have a Flex2 app that sits on a secure intranet running IIS. > > > One of the functions uploads a file from client-side to the server. > > > I create the URLRequest to an .asp page receiver, set up params, and > > > execute a .upload on a FileReference using that URLRequest. > > > > > > But for some reason, even though I've authenticated against the server > > > to access the app, I get a second authentication challenge/response > > > when I hit the upload button. > > > > > > I've added a cross-domain.xml with > > > <cross-domain-policy> > > > <allow-access-from domain="*" /> > > > </cross-domain-policy> > > > even though I don't think I should have to since the .asp page is on > > > the exact same domain as the app. I've even modified the index > > > template for the Flex project to use allowScriptAccess="always". But I > > > still get this second IIS login prompt. > > > > > > If I authenticate again via this second dialog, the upload executes > > > properly, so I know the logic and architecture is correct. > > > > > > Is there a way to pass the user's authenticated info with the > > > URLRequest/FileReference.upload()? I've poured through the docs and > > > can't find anything. Or is there something else I'm missing? > > > > > > > > > Thanks in advance, > > > -Carl > > > > > >
