Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-14 Thread li wenzhi
thanks for you guide, i have connected the socket, by using adobe official 
tutorial's sample policy file, yes, flashplayer need a Master policy file, NOT 
just a normal crossdomain.xml:
http://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html

 --
lwz7512
Ultrapower Flex Team Leader
OpenRIA -- A Window You Exploring RIA World
http://www.openria.cn



- Original Message 
From: EECOLOR <[EMAIL PROTECTED]>
To: flexcoders@yahoogroups.com
Sent: Saturday, June 14, 2008 9:36:45 PM
Subject: Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after 
Response is sent


This piece of information states it quite good:

"If Flash Player 9,0,124,0 cannot retrieve a master policy file from port 843, 
then it requests a socket policy file on the port where it is trying to 
connect. However, if a policy file is available from a service on TCP port 843, 
then Flash Player considers that to be the authoritative set of permissions for 
that system."


Greetz Erik



On 6/14/08, li wenzhi <[EMAIL PROTECTED] com> wrote:
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




  

Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-14 Thread EECOLOR
This piece of information states it quite good:

"If Flash Player 9,0,124,0 cannot retrieve a master policy file from port
843, then it requests a socket policy file on the port where it is trying to
connect. However, if a policy file is available from a service on TCP port
843, then Flash Player considers that to be the authoritative set of
permissions for that system."


Greetz Erik


On 6/14/08, li wenzhi <[EMAIL PROTECTED]> wrote:
>
> 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
>


Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-14 Thread li wenzhi
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: flexcoders@yahoogroups.com
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.
> >
> > 
> >  > "http://www.adobe. com/xml/dtds/ cross-domain- policy.dtd">
> > 
> > 
> > 
> > 
> >
> >
> > --- In [EMAIL PROTECTED] ups.com ,
"Josh
> > McDonald"  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  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
 > 40yahoogroups. com>,
> >
> > "Josh
> > > > McDonald"  wrote:
> > 

Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-12 Thread Josh McDonald
That seems reasonable to me, besides not being able to do it by hand with
loadPolicyFile(). If you've already got a web server, and you're trying to
connect from flash to something on port > 1024, you should be able to tell
it to get the policy file from another port or from the web server. As long
as it's coming from the same IP address, what reason is there to not allow
this? I can see plenty of situations where you've got a socket listening on
a high port number, and you have access to web space on that server, but no
root access to bind to port 843 :(

Also, can somebody explain the DNS rebind thing to me? If I'm abusing my own
DNS server for nefarious purposes, why do I need the Flash player as an
attack vector? You can't bind to a different class c without a root server
can you?

-Josh

On Fri, Jun 13, 2008 at 2:06 PM, e_baggg <[EMAIL PROTECTED]> wrote:

>   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.loadPolicyFile(). 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 flexcoders@yahoogroups.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.
> > >
> > > 
> > >  > > "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd";>
> > > 
> > > 
> > > 
> > > 
> > >
> > >
> > > --- In flexcoders@yahoogroups.com 
> > >  40yahoogroups.com>,
> "Josh
> > > McDonald"  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  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 HttpServicebut
> 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 
> 
> > > 40yahoogroups.com>,
> > >
> > > "Josh
> > > > > McDonald"  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  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

[flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-12 Thread e_baggg
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.loadPolicyFile(). 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 flexcoders@yahoogroups.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.
> >
> > 
> >  > "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd";>
> > 
> > 
> > 
> > 
> >
> >
> > --- In flexcoders@yahoogroups.com ,
"Josh
> > McDonald"  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  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 HttpServicebut
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
 > 40yahoogroups.com>,
> >
> > "Josh
> > > > McDonald"  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  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  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 ver

Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-12 Thread ZHOU Zhen-yu

Is it possible to config the apache server like this?
Let it return the policy-file if the received-request is not http protocol?

So we can load the socket policy via port 80

Security.loadPolicyFile("*xmlsocket*://foo.com:80");


Josh McDonald 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.


http://www.adobe.com/xml/dtds/cross-domain-policy.dtd
">







--- 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 HttpServicebut
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

http://40yahoogroups.com>>,

"Josh
> > McDonald"  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  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  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,
> > > >> 

Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-12 Thread Josh McDonald
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.
>
> 
>  "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd";>
> 
> 
> 
> 
>
>
> --- 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 HttpServicebut 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 
> > >  40yahoogroups.com>,
>
> "Josh
> > > McDonald"  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  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  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 so

[flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-12 Thread e_baggg
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.


http://www.adobe.com/xml/dtds/cross-domain-policy.dtd";>






--- 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 HttpServicebut 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 ,
"Josh
> > McDonald"  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  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  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 

Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-11 Thread Josh McDonald
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 HttpServicebut 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 , "Josh
> McDonald" <[EMAIL PROTECTED]> 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 <[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 
> > >>  40yahoogroups.com>,
> > >> "e_baggg"  wrote:
> > >> >
> > >> > Actually, I stand corrected. Once I added in my port # to the
> > >> > cross-domain...it worked. Thanks again gang! Big help!
> > >> >
> > >> >
> > >> > 
> > >> > 
> > >> > 
> > >> >
> > >> >
> > >> >
> > >> > --- In flexcoders@yahoogroups.com 
> > >> >  40yahoogroups.com>,
> > >> "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...
> > >> > >
> > >> > > 
> > >> > > 
> > >> > > 
> > >> > >
> > >> > > --- In flexcoders@yah

[flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-11 Thread e_baggg
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 HttpServicebut 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, "Josh McDonald" <[EMAIL PROTECTED]> 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 <[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 ,
> >> "e_baggg"  wrote:
> >> >
> >> > Actually, I stand corrected. Once I added in my port # to the
> >> > cross-domain...it worked. Thanks again gang! Big help!
> >> >
> >> >
> >> > 
> >> > 
> >> > 
> >> >
> >> >
> >> >
> >> > --- In flexcoders@yahoogroups.com ,
> >> "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...
> >> > >
> >> > > 
> >> > > 
> >> > > 
> >> > >
> >> > > --- In flexcoders@yahoogroups.com ,
> >> å`¨æŒ¯å(R)‡  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

Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-11 Thread ZHOU Zhen-yu
The official explanation is:
/Flash Player 9,0,115,0 introduces several changes to the way socket 
policy files work. These changes are primarily to support the goal of 
DNS hardening 
,
 
helping to ensure that ActionScript cannot be used as a means for a DNS 
rebinding attack that results in an unauthorized socket connection./

I still have no idea on what is DNS hardening. It's too complicated for me.

Josh McDonald wrote:
>
> Makes sense, I just assumed it'd go in over http to look for the 
> policy file. Thanks for clearing that up though.
>
>
> -Josh
>
> On Thu, Jun 12, 2008 at 11:38 AM, ZHOU Zhen-yu 
> <[EMAIL PROTECTED] 
> > wrote:
>
> I'm using Socket, not XMLSocket.
> But I think it doesn't matter.
>
> It depends on the browser and the version of flashplayer.
> And I found those C++ codes are the only way to make it work in
> all the
> browsers.
>
> You can still make an AIR mail client.
> But if you want to make an online client. The owner of that mail
> server
> will have the right to ban it.
> That's the reason they did that, I guess.
>
> Josh McDonald wrote:
> >
> > Really? Wow, that doesn't smell right to me, why on earth did
> they do
> > that? That'd make it impossible to connect to mail servers and such
> > unless they support looking for a policyfile request.
> >
> >
> > You're not using an xmlSocket? That shouldn't work for http requests
> > as the data packets are supposed to be all XML afaik.
> >
> > Unfortunately while I know a fair bit about http protocol, I'm a
> > little out of my depth on Flex sockets still. Getting there
> though :)
> >
> > -Josh
> >
> > On Thu, Jun 12, 2008 at 10:47 AM, ZHOU Zhen-yu
> > <[EMAIL PROTECTED]
> 
> >  >> wrote:
> >
> > I think the policy-requet for an socket connection is different
> > from http.
> > What the server will receive is not an http protocol, but an xml
> > string.
> >
> > So when I tried to make a online whiteboard program last week.
> > I had to write these in the server side( in C++ ).
> >
> > --
> > socket->Read(buf, BUFSIZE);
> > if( strcmp( buf, "" ) == 0 )
> > {
> >  const char response[] =
> > "\
> >  \
> >  ";
> >  socket->Write(response, sizeof(response) );
> >  socket->Destroy();
> >  return NULL;
> > }
> > --
> >
> > Josh McDonald 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
> > <[EMAIL PROTECTED] 
> >
> > > 
>  > >
> > > 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] 

Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-11 Thread ZHOU Zhen-yu
I'm using Socket, not XMLSocket.
But I think it doesn't matter.

It depends on the browser and the version of flashplayer.
And I found those C++ codes are the only way to make it work in all the 
browsers.

You can still make an AIR mail client.
But if you want to make an online client. The owner of that mail server 
will have the right to ban it.
That's the reason they did that, I guess.

Josh McDonald wrote:
>
> Really? Wow, that doesn't smell right to me, why on earth did they do 
> that? That'd make it impossible to connect to mail servers and such 
> unless they support looking for a policyfile request.
>
>
> You're not using an xmlSocket? That shouldn't work for http requests 
> as the data packets are supposed to be all XML afaik.
>
> Unfortunately while I know a fair bit about http protocol, I'm a 
> little out of my depth on Flex sockets still. Getting there though :)
>
> -Josh
>
> On Thu, Jun 12, 2008 at 10:47 AM, ZHOU Zhen-yu 
> <[EMAIL PROTECTED] 
> > wrote:
>
> I think the policy-requet for an socket connection is different
> from http.
> What the server will receive is not an http protocol, but an xml
> string.
>
> So when I tried to make a online whiteboard program last week.
> I had to write these in the server side( in C++ ).
>
> --
> socket->Read(buf, BUFSIZE);
> if( strcmp( buf, "" ) == 0 )
> {
>  const char response[] =
> "\
>  \
>  ";
>  socket->Write(response, sizeof(response) );
>  socket->Destroy();
>  return NULL;
> }
> --
>
> Josh McDonald 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
> <[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
> >

Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-11 Thread Josh McDonald
Really? Wow, that doesn't smell right to me, why on earth did they do that?
That'd make it impossible to connect to mail servers and such unless they
support looking for a policyfile request.
You're not using an xmlSocket? That shouldn't work for http requests as the
data packets are supposed to be all XML afaik.

Unfortunately while I know a fair bit about http protocol, I'm a little out
of my depth on Flex sockets still. Getting there though :)

-Josh

On Thu, Jun 12, 2008 at 10:47 AM, ZHOU Zhen-yu <
[EMAIL PROTECTED]> wrote:

> I think the policy-requet for an socket connection is different from http.
> What the server will receive is not an http protocol, but an xml string.
>
> So when I tried to make a online whiteboard program last week.
> I had to write these in the server side( in C++ ).
>
> --
> socket->Read(buf, BUFSIZE);
> if( strcmp( buf, "" ) == 0 )
> {
>  const char response[] =
> "\
>  \
>  ";
>  socket->Write(response, sizeof(response) );
>  socket->Destroy();
>  return NULL;
> }
> --
>
> Josh McDonald 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 <[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
> > 

Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-11 Thread ZHOU Zhen-yu
I think the policy-requet for an socket connection is different from http.
What the server will receive is not an http protocol, but an xml string.

So when I tried to make a online whiteboard program last week.
I had to write these in the server side( in C++ ).

--
socket->Read(buf, BUFSIZE);
if( strcmp( buf, "" ) == 0 )
{
 const char response[] =
"\
  \
 ";
 socket->Write(response, sizeof(response) );
 socket->Destroy();
 return NULL;
}
--

Josh McDonald 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 <[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
> , "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!
> >
> >
> > 
> > 
> > 
> >
> >
> >
> > --- In flexcoders@yahoogroups.com
> , "e_baggg"  wrote:
> > >
> > > Thanks for your response...I have a full access cross
> domain on my
> > > server and loading it via Security.lo

Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-11 Thread Josh McDonald
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 ,
>> "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!
>> >
>> >
>> > 
>> > 
>> > 
>> >
>> >
>> >
>> > --- In flexcoders@yahoogroups.com ,
>> "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...
>> > >
>> > > 
>> > > 
>> > > 
>> > >
>> > > --- In flexcoders@yahoogroups.com ,
>> å`¨æŒ¯å(R)‡  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 > > > > > > 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 anyo

Re: [flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-11 Thread Josh McDonald
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 ,
> "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!
> >
> >
> > 
> > 
> > 
> >
> >
> >
> > --- In flexcoders@yahoogroups.com ,
> "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...
> > >
> > > 
> > > 
> > > 
> > >
> > > --- In flexcoders@yahoogroups.com ,
> å`¨æŒ¯å(R)‡  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  > > > > > 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 soc

[flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-11 Thread e_baggg
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, "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!
> 
> 
> 
>   
> 
> 
> 
> 
> --- In flexcoders@yahoogroups.com, "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...
> > 
> > 
> > 
> > 
> > 
> > --- In flexcoders@yahoogroups.com, å`¨æŒ¯å®‡  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  > > > > 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 \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="1175bbe7d5840a0d

[flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-11 Thread e_baggg
Actually, I stand corrected. Once I added in my port # to the
cross-domain...it worked. Thanks again gang! Big help!



  




--- In flexcoders@yahoogroups.com, "e_baggg" <[EMAIL PROTECTED]> 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...
> 
> 
> 
> 
> 
> --- In flexcoders@yahoogroups.com, å`¨æŒ¯å®‡  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  > > > 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 \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@ 
> > >
> >
>




[flexcoders] Re: Socket HTTP/1.1 connection not closed even after Response is sent

2008-06-11 Thread e_baggg
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...





--- In flexcoders@yahoogroups.com, å`¨æŒ¯å®‡ <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] 
> > > 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 \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 :: [EMAIL PROTECTED] 
> >
>