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?
http://www.w3.org/TR/access-control/ 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