LINUX.ORG.RU

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


0

0

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

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

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

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

☆☆☆☆☆

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

>А к чему тогда привязывать?

Да сделай кнопку, если хочешь: «Привязать сессию к IP». А, кстати, к UA - хорошая идея.

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

Ну, сейчас я вообще просто беру URL странички, с которой производится обращение к функции аутентификации, кодирую его случайным числом и отсылаю в качестве идентификатора сессии. Доступ к ресурсам проверяется по БД (в которой указаны разрешенные URL'ы для каждого пользователя или /, если доступ разрешен ко всему).

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

> кстати, к UA - хорошая идея.

плохая идея :-)

[привязывать к IP кстате тоже плохая идея, в условиях современных NAT-провайдеров, которые могут меня IP на выходе NAT спонтанно]

но что касается привязки к UA — это плохая идея в квадрате :-) .. минорное обновление броузера. и сессия потеряна

хотя... если только НЕ имеется ввиду сессия закрывающаяся-не-по-времени

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

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

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

> Кстати, еще при помощи iframe приходится обходить утечки памяти: каждую динамическую картинку и видео запихивать в отдельный iframe,

эту весёлую тему — я помню на форуме...

...я ещё тогда делал тэст http://bit.ly/ls5Qjy (super-tmp1.narod.ru) и очень разочаровался в IT после того как тэст за-FAIL-ился на всех любимых броузерах :-D

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

>хотя... если только НЕ имеется ввиду сессия закрывающаяся-не-по-времени
Так вроде у него как раз сессия одноразовая, истекать должна по закрытию браузера.

>привязывать к IP кстате тоже плохая идея, в условиях современных NAT-провайдеров, которые могут меня IP на выходе NAT спонтанно
Потому и я говорю, что это только при согласии юзера.

Понятно, что без печенек в любом случае никуда.

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

минорное обновление броузера. и сессия потеряна

Куки я на год выдаю, так что, если их не потрет обновление, сессия потеряна не будет. А то, что к UA плохо привязываться, я и сам понял: достаточно в огнелисе сменить в UAswitcher'е UA, как сессия будет потеряна...

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

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

Нет, годовая.

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

> Понятно, что без печенек в любом случае никуда.

это да.... без печенек никуда...

...обидно только что как только дело доходит до печенек, то разработчики могут обычно (в 98% случаев) забывают предостеречься от CSRF-атак

...впрочем что-то я разварчался :-) :-)

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

разработчики могут обычно (в 98% случаев) забывают предостеречься от CSRF-атак

Это что еще за чудо?

Насчет библиотечки - как только допилю хотя бы полфункционала (осталось вылизать make install и сделать нормальной работу при незащищенных соединениях) - выложу на всеобщее обсирание обсуждение. Для проверки сделал простенькую тестовую страничку с кнопочкой, отображающей уровень доступа пользователя, если он вошел, и формочкой для отправки файла.

Потом еще хочу допилить отображение степени загрузки файла и, может быть, что-нибудь эдакое еще.

До выходных, скорее всего, за эту задачу не возьмусь: приболел что-то, не хочу на больную температурящую голову что-нибудь испортить. Да и интернет у нас нонче что-то совсем скатился - сейчас средняя скорость 1кБ/с.

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

Под той фразой я имел в виду, что после выхода идентификатор сессии удаляется, а при следующем входе выдается уже совершенно другой.

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

>после выхода идентификатор сессии удаляется, а при следующем входе выдается уже совершенно другой

Теперь мне непонятно, как же аутентификация производится.

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

Я же объяснял частично: логин и пароль пользователя, URL страницы, вызвавшей форму аутентификации и URL CGI, для которого надо получить куку, отправляются на сервер. Тот ищет в БД пользователя с таким логином, проверяет разрешение его доступа к данному URL и, если все ОК, шифрует URL солью из псевдослучайного числа, получая таким образом идентификатор. Затем заносит в БД запись идентификатора и имени пользователя и отсылает пользователю ответ ID=идентификатор URL=домен, а у пользователя JS производит нужную куку.

Авторизация производится так: CGI читает присланную ему куку и выделяет оттуда идентификатор. В БД ищется логин пользователя с данным идентификатором, проверяется его доступ к данному URL'у и уровень доступа (т.к. один CGI может выполнять разные функции в зависимости от уровня). Затем, на основе этой информации, CGI либо запускается, либо посылает нафиг. Отдельная кука для странички, обращающейся ко всем этим CGI нужна, чтобы сразу проверить - авторизован ли пользователь, ну а если не авторизован - открыть ему формочку ввода логина/пароля.

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

Да, в БД, естественно, хранятся не пароли, а их хеши (SHA512).

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

Почему так категорично? Есть к примеру, Dolphin, кторый поголовно на всех самсунгах стоит. Гугл посмотреть может, js может, даже флеш может, единственный минус у этого браузера — говноинтерфейс вместо тачскрина, но это не его вина.

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

А если просто показать div по центру

Как? html - не латех, элементов \hss и \vss в нем нет. А не зная размеров блока невозможно его выровнять.

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

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

Ты залогинен на сайте интернет-банка, на главной странице которого отображаются твои данные и кнопки для перевода денег. Хитрый человек вписывает URL этой страницы в невидимый iframe на своей.

Ты заходишь, а скрипты в фоне работают со страницей банка и делают всякую гадость.

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

Хитрый человек вписывает URL этой страницы в невидимый iframe на своей.

В том же домене?

Не надо мне тут бред нести...

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

Возможно так будет очевидней:
localhost:21 vsftpd
localhost:443 apache
localhost:80 nginx

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

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

Ладно, со всеми этими файлохостингами, думаю, такое может стать возможным.

Eddy_Em ☆☆☆☆☆
() автор топика

Это вообще что за беспредел? Для чего такую чушь устроили?

Это не чушь, это систем защиты такая, по скольку, например, Apache может по http:// показывать одно, а по https:// - совсем другое. По этому http:// и https:// считаются разными сайтами.

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

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

с css этого не сложно добиться, достаточно внимательно почитать правильные места в спеке CSS 2 и помнить о

div{ 
   display: inline-block; 
}
AGUtilities ★★★
()
Ответ на: комментарий от Eddy_Em

>А не зная размеров блока невозможно его выровнять.

А JS на что? Всё отлично выравнивается.

Hint: google://html popup div center

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

Е-мое, проблема в том, как узнать, что содержимое фрейма уже загрузилось, если фрейм с родителем взаимодействовать никак не могут!

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

Меня просто интересует, почему именно iframe? Почему нельзя просто div сделать с формой, у которой action на https стоит?

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

Можно и так, только дофига в JS придется писать - а так просто загружаю готовье.

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

Все, нашел уже, как выровнять блок при помощи display: table, display: table-cell.

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

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

Давно пришел к выводу, что нормальных, неглючных программ всего четыре, и три из них легко пишутся на HQ9+.

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