hi tim.
the crossdomain.xml file is now open an unrestricted to search. in
the future, as part of the migration to api.twitter.com for API
endpoints, we may consider relaxing a crossdomain.xml policy on that.
John I'm with others here that this represents a significant change to
the operation of the API and has affected numerous applications and
samples, etc.
Frankly I wish Twitter would really understand x-domain policy files
better. If there is a concern around security, then address it and
don't allow *user* changes on the API domain root. I fully understand
the reason for x-domain policies as we need them for Silverlight as
well -- and appreciate how they help mitigate the attack surface.
But especially for Search, which is an unauthenticated API it doesn't
make sense. Having twitter segment their API (or provide a different
endpoint for RIA clients that has the security risk mitigation in
place) seems to make sence. That's exactly what others (Yahoo,
Microsoft, etc.) do -- instead of hanging their API off of the end-
user application it is segmented (i.e., yahooapis.com or
api.twitter.com) so as to help the security threat surface.
Twitter doesn't block domains from using the services otherwise and
having a x-domain policy in place that is DIFFERENT than what is
allowed in the API in general is very confusing to the developer
audience.
Please change the Search API back ASAP as that in the short-term has
the greatest negative effect on a lot of applications that relied on
it and are now affected TWICE in one week without notification. Users
of the transactional API always knew from the very beginning about the
x-domain policy file (even though it, too, went through a change early
on), but the Search API hasn't been like this for a long time.
Consider your developer audience in the short-term while you consider
a longer-term solution. And until then, provide us with a phase-out
plan instead of a complete shut-off which negatively affects us and
our customers. I understand Twitter is a free service and such has
the typical SLA that comes along with free. But it has been an
invaluable service to your customers and ours --
I also agree with others that making these announcements BEFORE the
changes on status.twitter.com and these lists as well as the official
API announce is essential. There has only been answers on these
issues based on questions -- nothing pro-active from your team about
the changes or what is going on.
-th
On Nov 6, 7:35 am, Marauderz <maraud...@gmail.com> wrote:
John,
Even before last week, our Flash apps could always access
search.twitter.com. means that the crossdomain.xml had always allowed
universal access before. So it is NOT the same state that it was last
week.
The change in the crossdomain.xml will mean that all the Flash,
Silverlight and any other platform that respects a crossdomain.xml
file are now essentially broken by this change.
I understand the concerns for security, but maybe you could then
think
of setting up another domain for RIA app search use instead then? In
any case, a lot of twitter apps have just been silenced because of
this crossdomain.xml change.
On Nov 6, 8:08 am, John Adams <j...@twitter.com> wrote:
On Nov 5, 2009, at 3:32 PM, codewarrior415 wrote:
OK, the crossdomain policy now only allows your flex application to
access the API. You are not allowing flex appication access your
API?
How come the change again today. This morning it was working fine.
twitter.com's crossdomain.xml is exactly the same as it was last
week,
it was restored from the original configuration.
The search.twitter.com crossdomain.xml policy was incorrectly set to
permit from all sites for all actions.
We've configured that to be identical to the twitter.com
crossdomain.xml to prevent CSRF, session fixation, and attacks on
user accounts, which is a major security issue which Facebook and
Myspace fell to earlier this week.
Could you describe what you are trying to do and we'll research?
-john
--
Raffi Krikorian
Twitter Platform Team
ra...@twitter.com | @raffi
