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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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>, >> "e_baggg" <[EMAIL PROTECTED]> 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>, >> "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>, >> å`¨æŒ¯å(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 :: [EMAIL PROTECTED] > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
