Chrome отправка post данных

[Lao_kutuz]

Не так давно пеппер флеш хромовский стал отказываться делать переходы на страницы, если передаются какие-то пост данные

	var urlReq	:URLRequest = new URLRequest(myWonderfullURl);
			urlReq.method = URLRequestMethod.POST;
			urlReq.contentType = "application/json";
			urlReq.data =  JSON.stringify(myComplexData);
			navigateToURL(urlReq,"_blank");

Вообще задача такая - бекенду передать некий обьект жсоном для генерации отчета, который как раз и должен открыться в новой вкладке браузера. Как обойти этот косяк в хроме? Советовать всем клиентам устанавливать новый флеш плеер и отключать пеппер флеш - не вариант.

[caseyryan]

C GET запросом так же?

[Lao_kutuz]

Нет, GET хорошо проходит. Если в урлу передавать параметры кое-какие, то отчет наш генерируется хорошо, вкладка открывается без проблем.

Очень странно ведет себя хром и пепперфлеш. Неужели не так много разработчиков столкнулись с этой проблемой? Я думал что очередное обновление хрома решит проблему, но похоже они с ней бороться не планируют. Нашел еще одно обсуждение этой проблемы тут, но решение явно не подходит.

[ZicoRio]

Во Flash player в Chrome (PPAPI) одно чинят - другое ломают.
И так очень давно, впечатление, что пилят это дело ленивые пофигисты,
неудосуживающиеся все протестировать.
К сожалению даже если вы и найдете обходной маневр (в чем сомневаюсь)
после обновления плеера он может перестать работать.
Я уже несколько лет пилю свое приложение, где интерфейс на Flash.
Устал от их пофигизма и написал свой браузер на Qt, где я могу многое заточить как
мне нужно, включая ставить любую версию плеера. Правда плеер NPAPI, а от этого интерфейса
уже начали уходить на PPAPI (Google всех совратил). Ну да поживем - увидим.
Если сможете справиться с проблемой - напишите как удалось.

[ZackMercury]

А разница - GET или POST? Юзер всё равно сможет подменить данные и там, и там.

[caseyryan]

Разница в ограничениях на длину запроса

[ZicoRio]

Похоже, господа, дело совсем не в POST методе или данных, а в том, что
теперь нельзя менять/добавлять свои хидеры (новая политика безопасности!!! - мать ее)
при использовании navigateToURL().
Это также теперь нельзя во Flash player 13.0.0.214.

Вот ссылка на обсуждение:
https://forums.adobe.com/thread/1475657
в котором некий Jeromie Clark говорит, что другого выбора у них просто не было.
И спрашивается как тут обойтись без трех-этажного злословия!!!??
Теперь буду долго пить чай...

[caseyryan]

Очередной бред от адоби. Видимо они и правда заинтересованы в том, чтобы от флеш плеера отказывались в пользу других технологий

[ZicoRio]

Очень похоже на то, что сначала реализовали Гугловцы,
а потом уже в Adobe доделали. Может спорить не стали или еще что.
Но тенденция, скажем, странная.
С одной стороны урезали, на мой взгляд, безобидный функционал,
а с другой - может когда скажут, что вот мол теперь Flash безопасный совсем
и доводы Apple перестанут быть камнем для внедрения (поддержки).

[gloomyBrain]

Да зачем бороться за внедрение флеша в мобильные браузеры? Это бессмысленная затея, причем скорее из-за производительности и удобства, чем из-за безопасности. Более того, я лично не могу представить себе случай, при котором отправка собственных заголовков может повлиять на безопасность флеша. Могу представить, что кто-то не умеет обрабатывать заголовки при получении и у этого кого-то возникают проблемы с безопасностью. Но при чем тут флеш? Заголовки отправлять может кто угодно, их безопасная обработка - это проблема принимающей стороны.
По сему считаю аргументацию адоби бредовой и заведомо недостоверной. Причем, надо же, они пишут о сторонней компании, которая, дескать, сообщила им об уязвимости. Капец.