After thoroughly reading the Adobe socket policy docs, it looks like I'm going to have to open up port 843 and serve the new crossdomain.xml that way. Even though I have it on my root and call Security.loadPolicy() on it (and I see in the logger that it accepts it), it still calls 843, hangs, (b/c it doesn't exist there), than the Flash player throws a security error. Rather frustrating. So it goes. I'm on the debug FP version: WIN 9,0,124,0
This crossdomain below is on my root webserver and my app is on port 9080. Even if I move my html and swf to the main root (port 80)..it still fails. <?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd";> <cross-domain-policy> <site-control permitted-cross-domain-policies="master-only"/> <allow-access-from domain="*" to-ports="8080-9080"/> </cross-domain-policy> --- In flexcoders@yahoogroups.com, "Josh McDonald" <[EMAIL PROTECTED]> wrote: > > You can set any headers you like so long as they're specified in your > crossdomain.xml, and they're not on the "banned" list. > > Details: > > http://www.adobe.com/devnet/flashplayer/articles/flash_player9_security_update.html#policy_file > > Baninanted headers: > > http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403030&sliceId=1 > > AFAIK jsessionid is a cookie and the browser should be putting it in to any > request made from Flex via HttpService. You may have the one Flash Player > version (apparently 9.0.115.0) that blocks Authorization header info. > > -Josh > > On Thu, Jun 12, 2008 at 2:20 PM, e_baggg <[EMAIL PROTECTED]> wrote: > > > I am doing hand-rolled GETs because Flex (HttpService) cannot pass > > headers (ie jessionid). Thus, I need to open my own flash.net.Socket > > and write/read the request/response manually. It works great with > > Digest authorization except for this policy issue. I suppose I can get > > around this making the login page a JSP and make the redirect go to > > the swf html page...and from there use HttpService....but still I hate > > hacks. Such a shame this policy stuff is such a nightmare. I followed > > the Adobe docs exactly and I still have issues. I'll work on this more > > and report back anything I find. > > > > > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, "Josh > > McDonald" <dznuts@> wrote: > > > > > > Also, maybe we should look at the root of the problem - what is it > > you're > > > actually trying to do via sockets and hand-rolled GETs that you can't do > > > with httpService? > > > -Josh > > > > > > On Thu, Jun 12, 2008 at 9:51 AM, Josh McDonald <josh@> wrote: > > > > > > > You'll have to use something like Charles to listen to what Flash > > player is > > > > doing behind your back for the policy file to be sure, but if you > > try and > > > > open a socket to somedomain.com:9080, I believe Flash is going to > > look for > > > > somedomain.com:80/crossdomain.xml - Flash doesn't know that the socket > > > > you're connecting to is a http server, so it only knows to look in the > > > > default location, and it's not going to get your crossdomain file > > if it's on > > > > the server listening on 9080. > > > > Like I said, check with Charles to be sure, but it would make > > sense to me > > > > at least. > > > > > > > > -Josh > > > > > > > > > > > > On Thu, Jun 12, 2008 at 8:35 AM, e_baggg <e_baggg@> wrote: > > > > > > > >> I spoke too soon. The 3 second delay still exists and when I set up > > > >> the Swf policy file debugger for Windows...the Flash player outputs > > > >> this. My concern is that first warning. According to the docs, > > calling > > > >> Security.loadPolicyFile() to the domain and port (which line 2 says > > > >> happened ok) should fix everything. I just updated my Windows XP, > > > >> which I read somewhere upgrades the flash player. I still have the > > > >> debug version though. This is all a mess to me. > > > >> > > > >> OK: Root-level SWF loaded: http://my.domain.com:9080/xms-app/xms.swf > > > >> OK: Policy file accepted: http://my.domain.com:9080/crossdomain.xml > > > >> Warning: Timeout on xmlsocket://my.domain.com:843 (at 3 seconds) > > while > > > >> waiting for socket policy file. This should not cause any problems, > > > >> but see http://www.adobe.com/go/strict_policy_files for an > > explanation. > > > >> Warning: [strict] Requesting socket policy file from > > > >> xmlsocket://my.domain.com:9080 due to socket connection request from > > > >> SWF at http://my.domain.com:9080/xms-app/xms.swf. See > > > >> http://www.adobe.com/go/strict_policy_files if this causes problems. > > > >> Warning: Timeout on xmlsocket://my.domain.com:9080 (at 3 seconds) > > > >> while waiting for socket policy file. This should not cause any > > > >> problems, but see http://www.adobe.com/go/strict_policy_files for an > > > >> explanation. > > > >> Warning: SWF from http://my.domain.com:9080/xms-app/xms.swf will be > > > >> permitted to connect to a socket in its own domain without a policy > > > >> file. This configuration is deprecated. See > > > >> http://www.adobe.com/go/strict_policy_files to fix this problem. > > > >> Warning: SWF from http://my.domain.com:9080/xms-app/xms.swf will be > > > >> permitted to connect to a socket in its own domain without a policy > > > >> file. This configuration is deprecated. See > > > >> http://www.adobe.com/go/strict_policy_files to fix this problem. > > > >> > > > >> --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com><flexcoders% > > 40yahoogroups.com>, > > > >> "e_baggg" <e_baggg@> wrote: > > > >> > > > > >> > Actually, I stand corrected. Once I added in my port # to the > > > >> > cross-domain...it worked. Thanks again gang! Big help! > > > >> > > > > >> > > > > >> > <cross-domain-policy> > > > >> > <allow-access-from domain="*" to-ports="9080,8080"/> > > > >> > </cross-domain-policy> > > > >> > > > > >> > > > > >> > > > > >> > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com><flexcoders% > > 40yahoogroups.com>, > > > >> "e_baggg" <e_baggg@> wrote: > > > >> > > > > > >> > > Thanks for your response...I have a full access cross domain > > on my > > > >> > > server and loading it via Security.loadPolicyFile() does > > nothing as > > > >> > > well. Hmm... > > > >> > > > > > >> > > <cross-domain-policy> > > > >> > > <allow-access-from domain="*"/> > > > >> > > </cross-domain-policy> > > > >> > > > > > >> > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com><flexcoders% > > 40yahoogroups.com>, > > > > > >> å`¨æ¯å(R) <zhenyu.zhou@> wrote: > > > >> > > > > > > >> > > > When you use a socket or xmlsocket in a remote swf file, > > > >> > > > flashplayer would send a policy-request to the server. > > > >> > > > Check > > > >> > > > > > > >> > > > > > >> > > > > >> > > http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_04.html > > > >> > > > > > > >> > > > When you run it locally, flashplayer won't do this. > > > >> > > > > > > >> > > > I'm not sure if this is the reason. > > > >> > > > Maybe you should call Security.loadPolicyFile() yourself > > and let > > > >> the > > > >> > > > server give it a correct respond. > > > >> > > > > > > >> > > > > > > >> > > > Josh McDonald wrote: > > > >> > > > > > > > >> > > > > It sounds to me like your server is simply holding the > > > >> > connection for > > > >> > > > > a few seconds in order to prevent brute-force password > > attacks. > > > >> > > > > > > > >> > > > > -Josh > > > >> > > > > > > > >> > > > > On Wed, Jun 11, 2008 at 6:23 AM, e_baggg <e_baggg@ > > > >> > > > > <mailto:e_baggg@>> wrote: > > > >> > > > > > > > >> > > > > This is baffling me. For authentication reasons, I am doing > > > >> > all my > > > >> > > > > HTTP traffic via a custom flash.net.Socket where I create and > > > >> > > parse > > > >> > > > > the HTTP request/response myself (using Digest > > authorization). > > > >> > > > > Everything works fine when I run the generated html/swf files > > > >> > > locally, > > > >> > > > > but once I deploy them to the unprotected part of a > > > >> > webserver, the > > > >> > > > > response connection is not dropped by the server for several > > > >> > > seconds. > > > >> > > > > I do a GET and receive the 401 immediately...send the > > same GET > > > >> > > request > > > >> > > > > again with the Digest info. I receive the correct response > > > >> > > from the > > > >> > > > > server immediately but the socket is not closed for 4 seconds > > > >> > > by the > > > >> > > > > server. Has anyone seen this? > > > >> > > > > > > > >> > > > > I have "Connection: close" in my request but the socket is > > > >> > > still kept > > > >> > > > > open. If I access this URI via browser URL bar, the delay > > > >> is not > > > >> > > > > there. I sniffed the packets and even if I mimic the request > > > >> > > String > > > >> > > > > exactly, the socket still hangs for 4 seconds. I suspect I > > > >> > am not > > > >> > > > > closing the socket request, though '\r\n\r\n' seems to be the > > > >> > > standard > > > >> > > > > (and it works when it runs locally). Any ideas??? > > > >> > > > > > > > >> > > > > Here is my exact request that hangs though the 200 > > response is > > > >> > > > > received immediately: > > > >> > > > > > > > >> > > > > GET /myapp/mydata.xml HTTP/1.1\r\n > > > >> > > > > Host: www.mydomain.com <http://www.mydomain.com>\r\n > > > >> > > > > Content-Type: application/x-www-form-urlencoded\r\n > > > >> > > > > Keep-Alive: 1\r\n > > > >> > > > > Connection: close\r\n > > > >> > > > > Cookie: JSESSIONID=8CCB32BBEDB875F082709FE17AA93679;\r\n > > > >> > > > > Authorization: Digest username="user1", realm="MYAPP", > > > >> > > > > > > > >> > > > > > >> > > > > >> > > nonce="MTIxMzEyODYwOTE0MDo1Njg5NTllYTUxMDYyN2VmNGNmMjViMTA4MDFiMDRjMA==", > > > >> > > > > uri="/myapp/mydata.xml", > > > >> > > response="1175bbe7d5840a0d94fb5de3ef16a2a3", > > > >> > > > > qop=auth, nc=1, cnonce="0a4f113b"\r\n\r\n > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > -- > > > >> > > > > "Therefore, send not to know For whom the bell tolls. It > > tolls for > > > >> > > thee." > > > >> > > > > > > > >> > > > > :: Josh 'G-Funk' McDonald > > > >> > > > > :: 0437 221 380 :: josh@ <mailto:josh@> > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > -- > > > > "Therefore, send not to know For whom the bell tolls. It tolls for > > thee." > > > > > > > > :: Josh 'G-Funk' McDonald > > > > :: 0437 221 380 :: josh@ > > > > > > > > > > > > > > > > -- > > > "Therefore, send not to know For whom the bell tolls. It tolls for > > thee." > > > > > > :: Josh 'G-Funk' McDonald > > > :: 0437 221 380 :: josh@ > > > > > > > > > > > > > -- > "Therefore, send not to know For whom the bell tolls. It tolls for thee." > > :: Josh 'G-Funk' McDonald > :: 0437 221 380 :: [EMAIL PROTECTED] >
