Change in crossdomain.xml??
kr...@neuroproductions.be
was working just fine, but now I get a Security sandbox violation
error.
when I look at the crossdomain, I see it onley accept requests from
<cross-domain-policy>
<allow-access-from domain="*.twitter.com"/>
</cross-domain-policy>
Did it change? or am I missing something?
kr...@neuroproductions.be
core problem remains
kr...@neuroproductions.be
Alex Payne
night. Unfortunately, do to an insecure interaction between Flash and
browsers, allowing cross-domain requests from any domain opens us to
assumed login attacks, which a Japanese security researcher had noted
publicly in the last 48 hours.
I didn't alert the list because we wanted to observe the behavior of
some of our Flash assets after the change, and so the current contents
of crossdomain.xml are not yet concrete. If anyone has suggestions
for a crossdomain.xml that's both secure and useful to Flash
developers, please let the list know.
On Sun, Mar 9, 2008 at 5:52 AM, <kr...@neuroproductions.be> wrote:
>
>
> I fixed my app, by getting the data via php on my own domain, but the
> core problem remains
>
--
Alex Payne
http://twitter.com/al3x
Dossy Shiobara
>
> Yes, we changed crossdomain.xml [...]
Yup, and it neutered Twitter Karma, which relied on the permissive
crossdomain.xml that twitter.com was publishing. :-)
Oh well, I guess that's the end of using Flash for making Twitter API
requests ... for anyone other than Twitter, of course.
-- Dossy
--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
kr...@neuroproductions.be
your own domain (and put your own "allow all" crossdomain.xml in if
needed)
there is a nice php class in the docs that you can use
@Alex,Twitter: Can't you use an other domain for the API, just like
the yahoo and google APIs ? at least check how they do it. with the
key and stuff.
Anyway, I hope it gets fixed :)
Dossy Shiobara
>
> @ Dossy : you can always reach the api via a server-side script on
> your own domain (and put your own "allow all" crossdomain.xml in if
> needed) there is a nice php class in the docs that you can use
The great thing about Twitter Karma was that users' ID and passwords
never touched my server--all communication was directly between the
end-user's browser and twitter.com's servers.
I don't use many Twitter "tools" because I don't hand out my own auth.
credentials to third parties, so I wanted to make Twitter Karma a tool
that I would feel comfortable using if someone _else_ had implemented
it.
Proxying requests through my servers will naturally "work" but I
wouldn't want to send my auth. credentials through some third-party
server, therefore I don't like asking other users to do it.
> @Alex,Twitter: Can't you use an other domain for the API, just like
> the yahoo and google APIs ? at least check how they do it. with the
> key and stuff. Anyway, I hope it gets fixed :)
Me too.
Alex Payne
that you'd like to see us implement?
We're not trying to shut down Flash developers, just trying to protect
our users' security.
--
Alex Payne
http://twitter.com/al3x
kr...@neuroproductions.be
this article can help you
http://blog.monstuff.com/archives/000302.html
On 9 mrt, 20:20, "Alex Payne" <a...@al3x.net> wrote:
> Kris: could you elaborate on the solution that Yahoo and Google use
> that you'd like to see us implement?
>
> We're not trying to shut down Flash developers, just trying to protect
> our users' security.
>
Dossy Shiobara
> that you'd like to see us implement?
>
> We're not trying to shut down Flash developers, just trying to protect
> our users' security.
1. Move the Twitter API to api.twitter.com. Use the completely
permissive crossdomain.xml on api.twitter.com.
2. Stop supporting HTTP Basic auth. on api.twitter.com. Implement OAuth
or some other kind of auth. token system.
3. Require non-public API requests to include a valid user auth. token.
Alex Payne
if I have anything to say about it :)
--
Alex Payne
http://twitter.com/al3x
Cameron Kaiser
> or some other kind of auth. token system.
Despite all the disadvantages of HTTP Basic, shutting it down completely
without a transition period will break a lot of applications.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Why did the chicken cross the Moebius strip? To get to the other ... uh ...
Cameron Kaiser
> > or some other kind of auth. token system.
>
> Despite all the disadvantages of HTTP Basic, shutting it down completely
> without a transition period will break a lot of applications.
Never mind -- I read this as twitter.com, not api.twitter.com.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- "I would blame Microsoft even if it *weren't* their fault." -- me ----------
Marco Kaiser
Are you thinking about supporting only OAuth for API access, dropping Basic Auth?
Dossy Shiobara
> Are you thinking about supporting only OAuth for API access, dropping Basic
> Auth?
You have to drop HTTP Basic auth--that is exactly where the security
issue arises from. Once the browser captures the auth. credentials
from the user, it always sends them, thus allowing third-party sites to
generate requests in the browser, via Flash, as the user, which can be
used for malicious purposes.
Marco Kaiser
By the way, I'm not talking about accessing the API from a browser, but in desktop clients. There is no 3rd-party-site involved. I'd be happy if basic auth or any other mechanism that does not require the user to be redirected to a browser would only be available over SSL, though.
Dossy Shiobara
> They "have to"? Wow... Maybe they should decide themselves?
True. The choices are: keep things the way they are and lock out
third-party developers from using Flash or force them to go through a
proxy; OR, make the changes I mentioned.
It sounds like Alex is hinting that they're opting to do the latter, not
the former. We'll see.
Marco Kaiser
Enough said.
Cameron Kaiser
> > Auth?
>
> You have to drop HTTP Basic auth--that is exactly where the security
> issue arises from. Once the browser captures the auth. credentials
> from the user, it always sends them, thus allowing third-party sites to
> generate requests in the browser, via Flash, as the user, which can be
> used for malicious purposes.
If you mean completely remove HTTP Basic Auth from the entire API
specification and make OAuth the only method, though, I would *not* support
that. That would break too many clients, and there are lots of one-off
scripts that use the easy method of passing auth headers (including over
SSL).
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- PowerPC inside! ------------------------------------------------------------
Dossy Shiobara
> I bet there are some other choices between the two you think of... not
> just black and white. But yes, we will see.
There are other choices, but none of them involve allowing HTTP Basic
auth. That is precisely the core of the security issue. SSL wouldn't
help here, either.
Marco Kaiser
Alex Payne
very, very long grace period and plenty of conversations with this
group.
--
Alex Payne
http://twitter.com/al3x
Marco Kaiser
that's fine, thanks for letting us know.
Ed Costello
We're not going to remove Basic Auth from the Twitter API without a
very, very long grace period and plenty of conversations with this
group.
Would you consider adding digest authentication and gracefully migrating to that?
-ed costello
Artific Industries, e...@artific.com, http://artific.com/
Alex Payne
--
Alex Payne
http://twitter.com/al3x
creacog
that have no need to send authentication.
Is it worth considering a subdomain (e.g. public.twitter.com ) through
which only non-private feeds can be served or proxied without a cross-
domain restriction? If the userid has changed their feed to private -
simply return a suitable 'private' message as the status. (not ideal I
know)
creacog
A slight fault in the AS3 v2 api (http://twitter.com/
Twitter_AS3_2.0.zip)...
private function errorHandler (errorEvent :IOErrorEvent) : void
needs to change to
private function errorHandler (errorEvent :ErrorEvent) : void
...or the SWF will issue a run time failure when it hits the security
error generated by the current cross-domain restriction...
TypeError: Error #1034: Type Coercion failed: cannot convert
flash.events::SecurityErrorEvent@18946191 to flash.events.IOErrorEvent
Dossy Shiobara
API:
<?xml version="1.0" encoding="UTF-8"?>
<hash>
<request>/notifications/follow/[username].xml</request>
<error>There was a problem following the specified user.</error>
</hash>
Is this a rate limit issue? Something else?
Alex Payne
John Spurlock
Dossy's changes are also needed to support the new Silverlight client,
which uses the same crossdomain policy files.
__________________________
John Spurlock
http://twitter.com/johnspurlock
On Mar 9, 3:53 pm, "Alex Payne" <a...@al3x.net> wrote:
> Dossy: all of those things should be happening inside of this month,
> if I have anything to say about it :)
>
>
>
> On Sun, Mar 9, 2008 at 1:51 PM, Dossy Shiobara <do...@panoptic.com> wrote:
>
>
> > > Kris: could you elaborate on the solution that Yahoo and Google use
> > > that you'd like to see us implement?
>
> > > We're not trying to shut down Flash developers, just trying to protect
> > > our users' security.
>
> > 1. Move the Twitter API to api.twitter.com. Use the completely
Alex Payne
Herdiansah
http://www.dailyflashid.org/archives/2007/06/sitwitts_simple.php
and still working on it.
On Mar 30, 10:09 pm, "Alex Payne" <a...@al3x.net> wrote:
> Apologies, but we're not there yet on these changes. This list will be the
> first to know when we are.
>
creacog
> > Apologies, but we're not there yet on these changes. This list will be the
> > first to know when we are.
Richard Monette
mikey...@gmail.com
fixed this by changing from what the API recommends, to what it used
to be:
# THIS DOESN"T WORK YET
#path = "/notifications/follow/#{screename}.json"
# THIS DOES
path = "/friendships/create/#{screename}.json"
HTH
Mike
www.baobabhealth.org
On Jun 16, 10:01 pm, Richard Monette <richard.mone...@gmail.com>
wrote: