LINUX.ORG.RU

И опять про дурацкие браузеры


0

0

Итак, я уже понял, что опера недостойна называться браузером.

Теперь еще и с огнелисом проблема. Пилю, значит, я свою библиотечку (раз, два) и решил протестировать, как она будет работать на незащищенном протоколе.

Для Ъ: организую аутентификацию пользователя посредством «всплывающего» блока, в котором расположен iframe с формой ввода пароля/логина (через SSL). Чтобы фрейм красиво выравнивался по центру страницы, используется функция parent.function(), которая после загрузки фрейма определяет его размеры и правильно центрует Когда я вызываю этот фрейм с защищенной страницы, проблем нет, а вот при вызове с незащищенной возникает проблема: firefox ругается, что «доступ к элементам parent запрещен».

Это вообще что за беспредел? Для чего такую чушь устроили? И как с этим бороться? Неужели придется для незащищенных соединений перенаправлять всю страничку на защищенное (как я делал с самого начала), там проверять данные и, в случае успеха, перенаправлять обратно?

☆☆☆☆☆

реквестирую тред с началом

Итак, я уже понял, что огнелис недостоен называться браузером.

MaZy ★★★★ ()
Ответ на: комментарий от MaZy

Да запросто. Firefox течет, Opera течет, Chrome течет. Да еще и везде понапичкано всяких никому не нужных ограничений...

Ужас!

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от MaZy

В том то и дело, что нет. И как с этим жить - непонятно.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

С нетерпением ждём ответа, чем же нам пользоваться в качестве броузера?

Hokum_2011 ()

Проблема лежит глубже. Безопасность и удобство — вещи, достаточно тяжело скрещиваемые.

baverman ★★★ ()
Ответ на: комментарий от LongLiveUbuntu

Естественно, я не рассматриваю не-браузеры (IE), терминальные браузеры (links, lynx) и всякие неизвестные браузеры (safari).

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Hokum_2011

firefox'ом, чем же еще? Плакать, колоться, но продолжать жрать этот кактус, т.к. больше все равно никаких аналогов нет.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от LongLiveUbuntu

И где я вам на это сотню человеколет возьму?

Eddy_Em ☆☆☆☆☆ ()

Итак, я уже понял, что wget достоин называться браузером.

vurdalak ★★★★★ ()
Ответ на: комментарий от LongLiveUbuntu

Т.е. по-вашему, можно нормальный браузер за 50 человеколет написать?

Мне кажется, что и сотни не хватит...

Eddy_Em ☆☆☆☆☆ ()

> Чтобы фрейм красиво выравнивался по центру страницы, используется функция parent.function()

css же.

anonymous ()
Ответ на: комментарий от Eddy_Em

> всякие неизвестные браузеры (safari).

Вася, ну ты п****бол.

anonymous ()
Ответ на: комментарий от Eddy_Em

> Мне кажется, что и сотни не хватит...

Хватит. Ты у нас умный, справишься и раньше.

anonymous ()
Ответ на: комментарий от anonymous

И как мне при помощи css выровнять по центру страницы фрейм, размеры которого можно определить лишь после его загрузки?

И еще: помимо функций выравнивания, нужно еще кое-какие функции из родительского окна вызывать.

Eddy_Em ☆☆☆☆☆ ()

Эдди продолжал хотеть… :)

Deleted ()
Ответ на: комментарий от LongLiveUbuntu

> Нормальный браузер можно за неделю написать

Если взять готовый движок.

anonymous ()
Ответ на: комментарий от Eddy_Em

Лазарус тебе поможет, Monodevelop, Qt...

В чем проблема? WebKit же специально для таких как ты написали, не?

LongLiveUbuntu ★★★★★ ()
Ответ на: комментарий от LongLiveUbuntu

Еще один вебкитобраузер хуже еще одного плеера.

anonymous ()
Ответ на: комментарий от LongLiveUbuntu

Monodevelop

К счастью, я еще не пообедал, а то проблевался бы.

WebKit же специально для таких как ты написали, не?

-//-

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от LongLiveUbuntu

Так это ты не написал, а взял и получил готовый кусок багофич :]

Deleted ()

>доступ к элементам parent запрещен

Возможные причины:

  1. Не совпадают домены, адреса или протоколы. Так все известные мне браузеры делают: не может iframe, который загружается по http, получить доступ к parent, который загружен по https, и наоборот. По-моему, это твой случай.
  2. Страницы загружаются из локальных файлов. Не знаю, как Огнелис, а Хром, например, в этом случае тоже запретит доступ к parent, как если бы были разные протоколы, кроме как если запустить его со специальной опцией.
proud_anon ★★★★★ ()
Ответ на: комментарий от proud_anon

Это все я читал уже. Ладно, несовпадение доменов - теоретически, оно может привести к мифическим нарушениям безопасности (что это такое - я не знаю и не представляю, как можно нарушить таким образом безопасность). Но несовпадение протоколов внутри одного домена - полный бред. Как же взаимодействовать между элементами, работающими через защищенное и незащищенное соединение?

// кстати, родилась мысль: ведь POST-запрос, направленный по защищенному соединению, шифруется - так что можно сделать один скриптик и форму авторизации для защищенных соединений и другой, такой же, но с заменой https на http - для незащищенных. POST-запрос с паролем и логином отправлять по SSL-соединению. Проверю, может быть, будет работать. Правда, не уверен на 100%, что при таком соединении данные будут шифроваться.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

>Но несовпадение протоколов внутри одного домена - полный бред. Как же взаимодействовать между элементами, работающими через защищенное и незащищенное соединение?

Вероятно подразумевается, что так быть не должно. Если https, то везде. Иначе это фикция.

Deleted ()
Ответ на: комментарий от Eddy_Em

Не пойму, что именно вам надо сделать, но если вам просто iframe надо посередине страницы поставить, нельзя ли, чтобы родитель сам этот iframe выравнивал, а не он просил родителя его выровнять?

>Ладно, несовпадение доменов - теоретически, оно может привести к мифическим нарушениям безопасности (что это такое - я не знаю и не представляю, как можно нарушить таким образом безопасность). Но несовпадение протоколов внутри одного домена - полный бред.

Ну это, в общем-то, понятно как:
1.У вас в iframe находятся логин и пароль, передаваемые по https. А iframe этот находится на странице, передаваемой по http.

2.Злоумышленник перехватывает страницу, передаваемую по http, и внедряет туда свой javascript, который будет воровать со страницы с https пароль. Или же подменять там в форме action, чтобы перенаправить POST-запрос. Или же хотя бы подменять там функции, вызываемые из этого iframe'а, чтобы что-нибудь сделать.

3.???

4.Убытки.

proud_anon ★★★★★ ()
Ответ на: комментарий от proud_anon

нельзя ли, чтобы родитель сам этот iframe выравнивал, а не он просил родителя его выровнять?

А как родитель узнает, что iframe загрузился и заполнился?

Злоумышленник перехватывает страницу, передаваемую по http, и внедряет туда свой javascript, который будет воровать со страницы с https пароль.

Как? Пароль/логин передаются по SSL со странички в iframe. Без SSL передаются только незащищенные данные и куки с текущим идентификатором сессии.

Теоретически, они могут подменить функции фрейма - но ведь фрейм и страничка расположены в одном и том же домене! Как можно в этом случае сделать подмену?

Eddy_Em ☆☆☆☆☆ ()

> Неужели придется для незащищенных соединений перенаправлять всю страничку на защищенное ...?

да

... там проверять данные и, в случае успеха, перенаправлять обратно?


нет. обратно — ненадо.. если уж SSL, то всё через SSL

user_id_68054 ★★★★★ ()
Ответ на: комментарий от user_id_68054

если уж SSL, то всё через SSL

Нафига мне видео по SSL гонять? Я его только для аутентификации использую и для доступа к файлам.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от LongLiveUbuntu

> В чем проблема? WebKit же специально для таких как ты написали, не?

в Webkit теже проблемы (утечка памяти) что и в Chromium :-) ..

номер билетика Webkit — упомянается в билетике от Chromium

user_id_68054 ★★★★★ ()
Ответ на: комментарий от Eddy_Em

> Нафига мне видео по SSL гонять? Я его только для аутентификации использую и для доступа к файлам.

а что плохого если погонять? :-) .. мир рухнет? скорость значительно уменьшится?

# p.s.: современное асинхронное шифрование — только в самом начале как асинхронное работает.. а далее простая синхронная-функция и XOR

user_id_68054 ★★★★★ ()
Ответ на: комментарий от Eddy_Em

> Firefox течет, Opera течет, Chrome течет.
Нужно напейсать браузер на джаве. Это же очевидно.

anonymous ()
Ответ на: комментарий от Eddy_Em

>Как? Пароль/логин передаются по SSL со странички в iframe. Без SSL передаются только незащищенные данные и куки с текущим идентификатором сессии.
Так Javascript'ом прямо на клиенте могли бы спереть, если бы не защита!

>Теоретически, они могут подменить функции фрейма - но ведь фрейм и страничка расположены в одном и том же домене! Как можно в этом случае сделать подмену?
Так мы же исходим из того, что «человек посередине» может прочитать и подменить какие угодно данные, кроме передаваемых по SSL, так, что его не заметят.

proud_anon ★★★★★ ()
Ответ на: комментарий от Eddy_Em

>Нафига мне видео по SSL гонять? Я его только для аутентификации использую и для доступа к файлам.

Так и не гоняй. Сделай только авторизацию по SSL. Попробуй как-нибудь обойтись, чтобы не надо было кроссдоменную защиту обходить. Потом, идентификатор сессии там достаточно безопасный? А то он по HTTP передается, может, если его спереть, то и пароля не надо?

proud_anon ★★★★★ ()

А только у меня возникает вопрос, нафейхоа тут iframe?

drakmail ★★★★ ()
Ответ на: комментарий от drakmail

> А только у меня возникает вопрос, нафейхоа тут iframe?

ну мне вообще например зачастую непонятно зачем люди используют <iframe> в своих web-приложениях

создаётся ощущение что <iframe> предназначен специально для генераии злобных костылей :-D

..но в данной ситуации видно что автор настолько отчаянно борится с глюками современных броузеров — что применение iframe может быть даже не самый большой костыль :-)

user_id_68054 ★★★★★ ()
Ответ на: комментарий от proud_anon

идентификатор сессии там достаточно безопасный? А то он по HTTP передается, может, если его спереть, то и пароля не надо?

Одноразовый, на время посещения. Кстати, надо бы его к айпишнику клиента привязать, для пущей безопасности...

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от user_id_68054

Кстати, еще при помощи iframe приходится обходить утечки памяти: каждую динамическую картинку и видео запихивать в отдельный iframe, который раз в минуту-другую перезагружается. Иначе за час получаем крах системы (в случае огнелиса oom-killer начинает мочить всех подряд, chrome просто выдает oops).

Ну, а в данном случае использование iframe нужно для того, чтобы наиболее простым способом подгрузить формочку аутентификации. Правда, оказалось, что не такой уж он и удачный...

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

>Кстати, надо бы его к айпишнику клиента привязать, для пущей безопасности...

Ой, придут люди с жопорезом-диалапом, такая радость им будет, что при каждом дисконнекте слетает авторизация... Хоть бы добровольно сделал, чтобы выбирать можно было, привязывать или нет.

proud_anon ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.