Is it possible to use pre-flighting?
Sending the OPTIONS method first with the request we intend on
performing, and api.twitter.com responding with the appropriate
response code if they deem our transaction safe?
On Nov 7, 4:38 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> hi tim.
> thecrossdomain.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 acrossdomain.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 thecrossdomain.xml had always allowed
> >> universal access before. So it is NOT the same state that it was last
> >> week.
> >> The change in thecrossdomain.xml will mean that all the Flash,
> >> Silverlight and any other platform that respects acrossdomain.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
> >> thiscrossdomain.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, thecrossdomainpolicy 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'scrossdomain.xml is exactly the same as it was last
> >>> week,
> >>> it was restored from the original configuration.
> >>> The search.twitter.comcrossdomain.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