Basically, it's baked in anywhere in the swf's. It's something YOU provide to the Xray INTERFACE at runtime and save it if you wish. That URL is passed to the connector via local connection, the connector makes the call to the server using the specified URL and bam, you get back your secure data.
So, you're the one with the Xray interface and the knowledge of the URL, while the connector is still dumb in fact - make sense?
Xray Interface(url) --> connector.load(URL) --> PHP --> connector.onLoad () --> Xray Interface popup for entering data or verifies a client IP
what do you think?
On 1/5/06, Rob Bateman <
[EMAIL PROTECTED]> wrote:
I've been pondering this problem for a while now, and here are some ideas...Any security provided on the xray interface side is pointless, becaus the swf could be hacked to remove such settingsPasswords or urls accessed from inside the server-side swf can be revealed as well with a simple decompile.As far as i see, the only way to ensure security is to not include the connector code in ther server side swf at all. If debugging is required, you could add a getstring to the url (say, debug=true) that is passed through the embed tag to the applcation and triggers a swf with the connector code to load inside the application swf. The swf you load could be inside a password protected directory of the server, which would trigger a password confirmation box. Once the connector swf was loaded, it could set up the relevant connector objects on the _root of the app.Rob--
On 1/5/06, Steve Mathews <[EMAIL PROTECTED] > wrote:Couldn't someone just watch what address' are called then do the same
thing (call the page directly)? Sure, they would need to know to look
for that, but it doesn't seem any more secure to me.
Steve
On 12/26/05, John Grden <[EMAIL PROTECTED] > wrote:
> yeah, that's been a thought and discussion for a while now.
>
> the problem is, how do you lock it down?
>
> You can't put a password on the connector nor can you specifiy the local
> connection names - hacking an SWF is yesterday's news, so your proprietary
> information is not secure by any means. All a person does is hack your SWF,
> then they've got all the information they need.
>
> So, it comes down to: How does Xray load external data? Do we put the
> ability to type in a server side script URL, that the connector loads?
> Then, how do you keep someone from cracking your SWF, and calling the PHP
> page directly?
>
> The only thing that comes to mind is using the Xray interface to pass along
> the Server Side Script URL THROUGH the connector - Xray tells the connector
> what URL to call, it calls the page, and now, has the necessary data to do
> validation with the interface (Username/Password). Does that make sense?
>
> XrayInterface(url) -> connector -> url -> connector ->
> XrayInterface.validation
>
> Thoughts?
>
>
> On 12/26/05, Benjamin Jackson < [EMAIL PROTECTED]> wrote:
> > I was wondering about the potential for security breaches is with
> > leaving the Xray debugger active on live sites. On the one hand, it's
> > important to be able to debug the live site if something goes wrong
> > after deployment. On the other hand, it doesn't seem too smart to allow
> > anyone with the debugger execute arbitrary Actionscript on my swf.
> >
> > Any opinions?
> > ___________________
> > Ben Jackson
> > Diretor de Desenvolvimento
> >
> > [EMAIL PROTECTED]
> > http://www.incomumdesign.com
> >
> >
> > _______________________________________________
> > osflash mailing list
> > [email protected]
> > http://osflash.org/mailman/listinfo/osflash_osflash.org
> >
>
>
>
> --
> John Grden - Blitz
> _______________________________________________
> osflash mailing list
> [email protected]
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
>
>
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
~~~~~~~~~~~~~~~~~~~~~~~~
Rob Bateman - Flash Product Manager
BBC News Interactive
Tel: 0208 6248692
Mob: 07714 329073
[EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
--
John Grden - Blitz
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
