O grupo no qual você está postando é um grupo da Usenet. As mensagens postadas neste grupo farão com que o seu e-mail fique visível para qualquer pessoa na internet.
em princípio nenhuma diferença, o mesmo código funciona nos dois
ambientes.
onde pode haver diferença é no 'security sandbox' do Flash Player, que
bloqueia acessos cruzados, isto é se teu .swf é servido a partir de um
domínio, o FP não deixa vc acessar outros domínios. é preciso tem um
crossdomain.xml no destino com propriedas que permitam o teu acesso.
julio
On 2 jul, 13:47, Vinicius <vinu...@gmail.com> wrote:
> em princípio nenhuma diferença, o mesmo código funciona nos dois
> ambientes.
> onde pode haver diferença é no 'security sandbox' do Flash Player, que
> bloqueia acessos cruzados, isto é se teu .swf é servido a partir de um
> domínio, o FP não deixa vc acessar outros domínios. é preciso tem um
> crossdomain.xml no destino com propriedas que permitam o teu acesso.
o crossdomain.xml fica no servidor onde você vai acessar, ou seja,
no servidor onde está disponibilizado o serviço, XML, url, WebService
que você quer acessar diretamente pela sua aplicação Flex/Flash
lá no servidor onde está o que você quer acessar, deve ter uma regra no
crossdomain.xml
com uma regra que diz que requisições vindas do teu host (
http://seudominio.ext) pode acessar lá
se tiver isso lá no crossdomain.xml do servidor de onde você quer acessar
ai sim, você conseguirá acessar diretamente do Flex/Flash as coisas que
estiverem lá
em outras palavras, isto vai além do que você pode fazer,
a grande confusão do assunto crossdomain.xml é que não é você que vai
configurar esse arquivo para acessar algo, mas este arquivo deve estar
lá no servidor onde você quer acessar algo e ainda, deve conter uma regra
que possibilite que sua aplicação Flex/Flash recupere conteudo de lá
você, só e somente só irá configurar esse aquivo no teu servidor...
digamos que você tem lá seu domínio (http://seudominio.ext) e nele
você tem XML, WebServices e outras coisas, se você quizer limitar o acesso
de outras aplicações Flex/Flash a seu conteúdo você irá configurar este
arquivo e
colocar no diretorio raiz que responde ao seu dominio
por padrão, se não me engano se este arquivo não existir lá, já bloqueia por
padrão
qualquer recuperação de conteúdo do dominio, este arquivo deve ser definido
para dizer que conexões vindas de domínios A, B, sei lá qual outro, podem
recuperar conteúdo do seu domínio
>> em princípio nenhuma diferença, o mesmo código funciona nos dois
>> ambientes.
>> onde pode haver diferença é no 'security sandbox' do Flash Player, que
>> bloqueia acessos cruzados, isto é se teu .swf é servido a partir de um
>> domínio, o FP não deixa vc acessar outros domínios. é preciso tem um
>> crossdomain.xml no destino com propriedas que permitam o teu acesso.
por isso que nesses assuntos você sempre vai achar referência a palavra : * proxy* que é quem irá fazer o meio de campo da comunicação para você
mas eu ainda acho mais facil fazer o acesso a conteudo externo (WebServices, XMLs e coisas do genero) através do back-end (Java, PHP, Ruby, etc)
que lá no servidor, não tem essa limitação de acesso
*obs.:* até hoje eu não entendo porque de existir do crossdomain, para mim só justifica para os desesperados por segurança... mas é tão facil burlar essa limitação do crossdomain do FP que para mim eu removeria ele do FP que mais atrapalha dq ajuda *a meu ver*
> por isso que nesses assuntos você sempre vai achar referência a palavra :
> *proxy*
> que é quem irá fazer o meio de campo da comunicação para você
> mas eu ainda acho mais facil fazer o acesso a conteudo externo
> (WebServices, XMLs e coisas do genero)
> através do back-end (Java, PHP, Ruby, etc)
> que lá no servidor, não tem essa limitação de acesso
> *obs.:* até hoje eu não entendo porque de existir do crossdomain, para mim
> só justifica para os
> desesperados por segurança... mas é tão facil burlar essa limitação do
> crossdomain do FP
> que para mim eu removeria ele do FP que mais atrapalha dq ajuda *a meu ver
> *
> Esse WebServices eu que controlo também. Estou usando Axis2 e com Axis2 eu
> gero um arquivo *.aar e coloco na pasta services.
> Durante o deploy não é gerada uma pasta específica dessa aplicação, então
> estou copiando o crossdomain.xml na pasta raiz do Axis2 e na pasta services.
> 2009/7/3 Erko Bridee de Almeida Cabrera <erko.bri...@gmail.com>
> só complementando algo que esqueci
>> por isso que nesses assuntos você sempre vai achar referência a palavra :
>> *proxy*
>> que é quem irá fazer o meio de campo da comunicação para você
>> mas eu ainda acho mais facil fazer o acesso a conteudo externo
>> (WebServices, XMLs e coisas do genero)
>> através do back-end (Java, PHP, Ruby, etc)
>> que lá no servidor, não tem essa limitação de acesso
>> *obs.:* até hoje eu não entendo porque de existir do crossdomain, para
>> mim só justifica para os
>> desesperados por segurança... mas é tão facil burlar essa limitação do
>> crossdomain do FP
>> que para mim eu removeria ele do FP que mais atrapalha dq ajuda *a meu
>> ver*
E coloquei na pasta Webapps do Tomcat onde o WebServices está rodando,
coloquei na pasta webapps/axis2 também e na pasta
webapps/axis2/WEB-INF/services.
Mas continua dando o erro no showErrorDialog, segue a parte webservices:
>> Esse WebServices eu que controlo também. Estou usando Axis2 e com Axis2 eu
>> gero um arquivo *.aar e coloco na pasta services.
>> Durante o deploy não é gerada uma pasta específica dessa aplicação, então
>> estou copiando o crossdomain.xml na pasta raiz do Axis2 e na pasta services.
>> 2009/7/3 Erko Bridee de Almeida Cabrera <erko.bri...@gmail.com>
>> só complementando algo que esqueci
>>> por isso que nesses assuntos você sempre vai achar referência a palavra :
>>> *proxy*
>>> que é quem irá fazer o meio de campo da comunicação para você
>>> mas eu ainda acho mais facil fazer o acesso a conteudo externo
>>> (WebServices, XMLs e coisas do genero)
>>> através do back-end (Java, PHP, Ruby, etc)
>>> que lá no servidor, não tem essa limitação de acesso
>>> *obs.:* até hoje eu não entendo porque de existir do crossdomain, para
>>> mim só justifica para os
>>> desesperados por segurança... mas é tão facil burlar essa limitação do
>>> crossdomain do FP
>>> que para mim eu removeria ele do FP que mais atrapalha dq ajuda *a meu
>>> ver*
> E coloquei na pasta Webapps do Tomcat onde o WebServices está rodando,
> coloquei na pasta webapps/axis2 também e na pasta
> webapps/axis2/WEB-INF/services.
> Mas continua dando o erro no showErrorDialog, segue a parte webservices:
>>> Esse WebServices eu que controlo também. Estou usando Axis2 e com Axis2
>>> eu gero um arquivo *.aar e coloco na pasta services.
>>> Durante o deploy não é gerada uma pasta específica dessa aplicação, então
>>> estou copiando o crossdomain.xml na pasta raiz do Axis2 e na pasta services.
>>> 2009/7/3 Erko Bridee de Almeida Cabrera <erko.bri...@gmail.com>
>>> só complementando algo que esqueci
>>>> por isso que nesses assuntos você sempre vai achar referência a palavra
>>>> : *proxy*
>>>> que é quem irá fazer o meio de campo da comunicação para você
>>>> mas eu ainda acho mais facil fazer o acesso a conteudo externo
>>>> (WebServices, XMLs e coisas do genero)
>>>> através do back-end (Java, PHP, Ruby, etc)
>>>> que lá no servidor, não tem essa limitação de acesso
>>>> *obs.:* até hoje eu não entendo porque de existir do crossdomain, para
>>>> mim só justifica para os
>>>> desesperados por segurança... mas é tão facil burlar essa limitação do
>>>> crossdomain do FP
>>>> que para mim eu removeria ele do FP que mais atrapalha dq ajuda *a meu
>>>> ver*
Mas eu tive que alterar meu xml e ficou assim:
<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*" to-ports="*"/>
<allow-http-request-headers-from domain="*" headers="SOAPAction"/>
</cross-domain-policy>
Outra coisa, a resposta do meu serviço vem dessa forma:
private function resultHandler1(event:ResultEvent):void{
var result:String = event.result as String;
Alert.show(event.message.toString(), "resultHandler1");
}
Obrigado,
Vinicius.
2009/7/3 Erko Bridee de Almeida Cabrera <erko.bri...@gmail.com>
>> E coloquei na pasta Webapps do Tomcat onde o WebServices está rodando,
>> coloquei na pasta webapps/axis2 também e na pasta
>> webapps/axis2/WEB-INF/services.
>> Mas continua dando o erro no showErrorDialog, segue a parte webservices:
>>>> Esse WebServices eu que controlo também. Estou usando Axis2 e com Axis2
>>>> eu gero um arquivo *.aar e coloco na pasta services.
>>>> Durante o deploy não é gerada uma pasta específica dessa aplicação,
>>>> então estou copiando o crossdomain.xml na pasta raiz do Axis2 e na pasta
>>>> services.
>>>> 2009/7/3 Erko Bridee de Almeida Cabrera <erko.bri...@gmail.com>
>>>> só complementando algo que esqueci
>>>>> por isso que nesses assuntos você sempre vai achar referência a palavra
>>>>> : *proxy*
>>>>> que é quem irá fazer o meio de campo da comunicação para você
>>>>> mas eu ainda acho mais facil fazer o acesso a conteudo externo
>>>>> (WebServices, XMLs e coisas do genero)
>>>>> através do back-end (Java, PHP, Ruby, etc)
>>>>> que lá no servidor, não tem essa limitação de acesso
>>>>> *obs.:* até hoje eu não entendo porque de existir do crossdomain, para
>>>>> mim só justifica para os
>>>>> desesperados por segurança... mas é tão facil burlar essa limitação do
>>>>> crossdomain do FP
>>>>> que para mim eu removeria ele do FP que mais atrapalha dq ajuda *a meu
>>>>> ver*
> Mas eu tive que alterar meu xml e ficou assim:
> <?xml version="1.0"?>
> <cross-domain-policy>
> <site-control permitted-cross-domain-policies="master-only"/>
> <allow-access-from domain="*" to-ports="*"/>
> <allow-http-request-headers-from domain="*" headers="SOAPAction"/>
> </cross-domain-policy>
> Outra coisa, a resposta do meu serviço vem dessa forma:
> private function resultHandler1(event:ResultEvent):void{
> var result:String = event.result as String;
> Alert.show(event.message.toString(), "resultHandler1");
> }
> Obrigado,
> Vinicius.
> 2009/7/3 Erko Bridee de Almeida Cabrera <erko.bri...@gmail.com>
>>> E coloquei na pasta Webapps do Tomcat onde o WebServices está rodando,
>>> coloquei na pasta webapps/axis2 também e na pasta
>>> webapps/axis2/WEB-INF/services.
>>> Mas continua dando o erro no showErrorDialog, segue a parte webservices:
>>>>> Esse WebServices eu que controlo também. Estou usando Axis2 e com Axis2
>>>>> eu gero um arquivo *.aar e coloco na pasta services.
>>>>> Durante o deploy não é gerada uma pasta específica dessa aplicação,
>>>>> então estou copiando o crossdomain.xml na pasta raiz do Axis2 e na pasta
>>>>> services.
>>>>> 2009/7/3 Erko Bridee de Almeida Cabrera <erko.bri...@gmail.com>
>>>>> só complementando algo que esqueci
>>>>>> por isso que nesses assuntos você sempre vai achar referência a
>>>>>> palavra : *proxy*
>>>>>> que é quem irá fazer o meio de campo da comunicação para você
>>>>>> mas eu ainda acho mais facil fazer o acesso a conteudo externo
>>>>>> (WebServices, XMLs e coisas do genero)
>>>>>> através do back-end (Java, PHP, Ruby, etc)
>>>>>> que lá no servidor, não tem essa limitação de acesso
>>>>>> *obs.:* até hoje eu não entendo porque de existir do crossdomain,
>>>>>> para mim só justifica para os
>>>>>> desesperados por segurança... mas é tão facil burlar essa limitação do
>>>>>> crossdomain do FP
>>>>>> que para mim eu removeria ele do FP que mais atrapalha dq ajuda *a
>>>>>> meu ver*
> Mas eu tive que alterar meu xml e ficou assim:
> <?xml version="1.0"?>
> <cross-domain-policy>
> <site-control permitted-cross-domain-policies="master-only"/>
> <allow-access-from domain="*" to-ports="*"/>
> <allow-http-request-headers-from domain="*" headers="SOAPAction"/>
> </cross-domain-policy>
> Outra coisa, a resposta do meu serviço vem dessa forma:
> >> E coloquei na pasta Webapps do Tomcat onde o WebServices está rodando,
> >> coloquei na pasta webapps/axis2 também e na pasta
> >> webapps/axis2/WEB-INF/services.
> >> Mas continua dando o erro no showErrorDialog, segue a parte webservices:
> >>>> Esse WebServices eu que controlo também. Estou usando Axis2 e com Axis2
> >>>> eu gero um arquivo *.aar e coloco na pasta services.
> >>>> Durante o deploy não é gerada uma pasta específica dessa aplicação,
> >>>> então estou copiando o crossdomain.xml na pasta raiz do Axis2 e na pasta
> >>>> services.
> >>>> 2009/7/3 Erko Bridee de Almeida Cabrera <erko.bri...@gmail.com>
> >>>> só complementando algo que esqueci
> >>>>> por isso que nesses assuntos você sempre vai achar referência a palavra
> >>>>> : *proxy*
> >>>>> que é quem irá fazer o meio de campo da comunicação para você
> >>>>> mas eu ainda acho mais facil fazer o acesso a conteudo externo
> >>>>> (WebServices, XMLs e coisas do genero)
> >>>>> através do back-end (Java, PHP, Ruby, etc)
> >>>>> que lá no servidor, não tem essa limitação de acesso
> >>>>> *obs.:* até hoje eu não entendo porque de existir do crossdomain, para
> >>>>> mim só justifica para os
> >>>>> desesperados por segurança... mas é tão facil burlar essa limitação do
> >>>>> crossdomain do FP
> >>>>> que para mim eu removeria ele do FP que mais atrapalha dq ajuda *a meu
> >>>>> ver*
private function resultHandler1(event:ResultEvent):void{
var result:Array = event.result as Array;
Alert.show("aqui resultHandler1");
Alert.show(result[0], "resultHandler1");
Alert.show(result[1], "resultHandler1");
> Com este crossdomain vc aceita chamadas de qualquer site, isto é,
> elimina qualquer proteção de segurança.... mas na verdade é como muita
> gente faz :-)
> Concordo com o Erko, é mais uma dessas picuinhas de segurança que só
> atrapalha (vide o MS Vista).
> Voltando ao teu WebService...
> No ResultHandler, o event.result deve ser um array, e não um string,
> pois vc teu webservice retorna mas de um resultado.
> Assim, event.result[0] deve corresponder ou retorno 'dest', e
> event.result[1] ao 'size'.
> vc tentou usar o debug e parar na entrada do teu resulthandler, pra
> ver o que é que tem em e.result?
> > >> E coloquei na pasta Webapps do Tomcat onde o WebServices está rodando,
> > >> coloquei na pasta webapps/axis2 também e na pasta
> > >> webapps/axis2/WEB-INF/services.
> > >> Mas continua dando o erro no showErrorDialog, segue a parte
> webservices:
> > >>>> Esse WebServices eu que controlo também. Estou usando Axis2 e com
> Axis2
> > >>>> eu gero um arquivo *.aar e coloco na pasta services.
> > >>>> Durante o deploy não é gerada uma pasta específica dessa aplicação,
> > >>>> então estou copiando o crossdomain.xml na pasta raiz do Axis2 e na
> pasta
> > >>>> services.
> > >>>> 2009/7/3 Erko Bridee de Almeida Cabrera <erko.bri...@gmail.com>
> > >>>> só complementando algo que esqueci
> > >>>>> por isso que nesses assuntos você sempre vai achar referência a
> palavra
> > >>>>> : *proxy*
> > >>>>> que é quem irá fazer o meio de campo da comunicação para você
> > >>>>> mas eu ainda acho mais facil fazer o acesso a conteudo externo
> > >>>>> (WebServices, XMLs e coisas do genero)
> > >>>>> através do back-end (Java, PHP, Ruby, etc)
> > >>>>> que lá no servidor, não tem essa limitação de acesso
> > >>>>> *obs.:* até hoje eu não entendo porque de existir do crossdomain,
> para
> > >>>>> mim só justifica para os
> > >>>>> desesperados por segurança... mas é tão facil burlar essa limitação
> do
> > >>>>> crossdomain do FP
> > >>>>> que para mim eu removeria ele do FP que mais atrapalha dq ajuda *a
> meu
> > >>>>> ver*
Vc tentou parar na entrada do resultHandler1 com o debug pra ver o que
é que vc tem no event.result?
É o jeito mais fácil de descobrir como está vindo a tua resposta.
> > Com este crossdomain vc aceita chamadas de qualquer site, isto é,
> > elimina qualquer proteção de segurança.... mas na verdade é como muita
> > gente faz :-)
> > Concordo com o Erko, é mais uma dessas picuinhas de segurança que só
> > atrapalha (vide o MS Vista).
> > Voltando ao teu WebService...
> > No ResultHandler, o event.result deve ser um array, e não um string,
> > pois vc teu webservice retorna mas de um resultado.
> > Assim, event.result[0] deve corresponder ou retorno 'dest', e
> > event.result[1] ao 'size'.
> > vc tentou usar o debug e parar na entrada do teu resulthandler, pra
> > ver o que é que tem em e.result?
> > > >> E coloquei na pasta Webapps do Tomcat onde o WebServices está rodando,
> > > >> coloquei na pasta webapps/axis2 também e na pasta
> > > >> webapps/axis2/WEB-INF/services.
> > > >> Mas continua dando o erro no showErrorDialog, segue a parte
> > webservices:
> > > >>>> Esse WebServices eu que controlo também. Estou usando Axis2 e com
> > Axis2
> > > >>>> eu gero um arquivo *.aar e coloco na pasta services.
> > > >>>> Durante o deploy não é gerada uma pasta específica dessa aplicação,
> > > >>>> então estou copiando o crossdomain.xml na pasta raiz do Axis2 e na
> > pasta
> > > >>>> services.
> > > >>>>> por isso que nesses assuntos você sempre vai achar referência a
> > palavra
> > > >>>>> : *proxy*
> > > >>>>> que é quem irá fazer o meio de campo da comunicação para você
> > > >>>>> mas eu ainda acho mais facil fazer o acesso a conteudo externo
> > > >>>>> (WebServices, XMLs e coisas do genero)
> > > >>>>> através do back-end (Java, PHP, Ruby, etc)
> > > >>>>> que lá no servidor, não tem essa limitação de acesso
> > > >>>>> *obs.:* até hoje eu não entendo porque de existir do crossdomain,
> > para
> > > >>>>> mim só justifica para os
> > > >>>>> desesperados por segurança... mas é tão facil burlar essa limitação
> > do
> > > >>>>> crossdomain do FP
> > > >>>>> que para mim eu removeria ele do FP que mais atrapalha dq ajuda *a
> > meu
> > > >>>>> ver*
|
