Hi, Did you successfully conntect the policy server with flash? I connected the policy server in Flex builder3 debug mode, but when i move the swf (include in html page) into tomcat(8080 port), and visit the page, the flash debugger saying "Errot 2044: unhandled SecurityErrorEvent. security sand box conflict , http://localhost:8080/xmlsocket/XmlSocketCon.swf can not load data from localhost:843 "
initially i started the socket server and the debugger saying these, then, i stop the socket server, the error is the same.why? any suggestion will be greate appreatiate! -------------------------------------------------- lwz7512 Ultrapower Flex Team Leader OpenRIA -- A Window You Exploring RIA World http://www.openria.cn ----- Original Message ---- From: e_baggg <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, June 13, 2008 12:06:55 PM Subject: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent I finally got it working. No matter what, the Flash player makes a request to port 843 asking for the cross-domain. ..even if you call Security.loadPolicy File(). I found a source example where a Java socket (which I kicked off in a shell script) listens on port 843 and returns the policy file. So, I therefore never need to call Security.loadPolicy (). Here's the link to that library. You need to make sure this port is open on your firewall which is easily testable with a telnet call. This port 843 method is actually the recommended way to do it according to Adobe. http://www.flash- resources. net/ --- In [EMAIL PROTECTED] ups.com, "Josh McDonald" <[EMAIL PROTECTED]> wrote: > > Let us know how it works. It's really a painful process really, there's got > to be a better way to secure the player against attacks without requiring > funky custom sockets needing being opened :( > > -Josh > > On Fri, Jun 13, 2008 at 3:08 AM, e_baggg <[EMAIL PROTECTED] > wrote: > > > 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 [EMAIL PROTECTED] ups.com <flexcoders% 40yahoogroups. com>, "Josh > > McDonald" <dznuts@> 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 <e_baggg@> 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 [EMAIL PROTECTED] ups.com <flexcoders% 40yahoogroups. 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.loadPolicy File() 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 [EMAIL PROTECTED] ups.com <flexcoders% 40yahoogroups. 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 [EMAIL PROTECTED] ups.com<flexcoders% 40yahoogroups. 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.loadPolicy File() does > > > > nothing as > > > > > >> > > well. Hmm... > > > > > >> > > > > > > > >> > > <cross-domain- policy> > > > > > >> > > <allow-access- from domain="*"/> > > > > > >> > > </cross-domain- policy> > > > > > >> > > > > > > > >> > > --- In [EMAIL PROTECTED] ups.com<flexcoders% 40yahoogroups. 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.loadPolicy File() 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=8CCB32BB EDB875F082709FE1 7AA93679; \r\n > > > > > >> > > > > Authorization: Digest username="user1" , realm="MYAPP" , > > > > > >> > > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > nonce="MTIxMzEyODYw OTE0MDo1Njg5NTll YTUxMDYyN2VmNGNm MjViMTA4MDFiMDRj MA==", > > > > > >> > > > > uri="/myapp/ mydata.xml" , > > > > > >> > > response="1175bbe7d 5840a0d94fb5de3e f16a2a3", > > > > > >> > > > > 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 :: josh@ > > > > > > > > > > > > > -- > "Therefore, send not to know For whom the bell tolls. It tolls for thee." > > :: Josh 'G-Funk' McDonald > :: 0437 221 380 :: [EMAIL PROTECTED] >
