• Дурацкий вопрос от человека, который нихуя не смыслит в веб-программировании:
    нужно написать маленькое приложэниэ, которое умеет спросить с юзера авторизацию-- скажем, http basic и далее одно из двух: или поддерживать с браузером persistent connection или иметь какой-то push-интерфейс, позволяющий определить, что юзер "еще там". При этом серверная часть должна уметь ответить на вопрос "там ли он еще" через, скажем, unix сокет по запросу от другого компонента.
    Куда смотреть на предмет того, как это пишется?

Replies (104)

  • @ArkanoiD, поддерживать конект с пушем, это или websocket, которые не во всех браузерах еще есть, или comet http Comet_(programming) в английской педивикии дает кучу ссылок
  • @ArkanoiD, днк чинить, шоб таких вопросов и не возникало
  • @solhov, обоснуй
  • @bormotov, наверняка есть сильно больше одного способа это сделать
  • @solhov, точнее, предложи разумную альтернативу. что не так в формулировке?
  • @ArkanoiD, изображать таким извращенным способом из коннект-лесс и стателесс протокола противоположное — это искать геморой на задницы, свою и пользователя
  • @solhov, а надо. задача — определить что клиент жив и доступен. кроме веба при этом ничего не используя. решение для telnet у меня уже есть, например. Оно не всем подходит как раз потому, что слишком сложно выглядит.
  • @solhov, по делу-то что можешь предложить? задача — out of band аутентификация. я альтернативы не вижу.
  • @ArkanoiD, наверянка :) но я сам такое не гродил. как-то интересовался, вроде попадались готовые примеры длинных коментных хвостов, но всё это на границе моих интересов ;(
  • @ArkanoiD, по делу? По какому делу? По твоим фантазиям? забыть. сделать веб-аутентификацию для файрвола или хот-спота? Посмотреть как делают другие и сделать также
  • @solhov, не хочется как другие, хочется лучше. хуево делают другие.
  • @solhov, авторизация IPшника на ограниченный промежуток времени по сравнению с тем что я предлагаю — вообще ни в пизду не годится, например
  • @ArkanoiD, из говна можно сделать конфетку, да. Но говеную
  • @solhov, по условиям задачи кроме говна ничего нет, увы. welcome to the real world.
  • @ArkanoiD, именно это ты и предлагаешь, раз говоришь про оут оф банд
  • @ArkanoiD, да ты гурман, разбираться в сортах говна
  • @solhov, с хера вдруг? я хочу решение,которое будет, однако, иметь защиту от того, что по этому адресу может случиться уже совершенно другой юзер — случайно или намеренно. существующие решения эту опасность игнорируют, а я на это пойтить не могу.
  • @ArkanoiD, это веб, добро пожаловать в реальность.
  • @solhov, я не вижу ПРИНЦИПИАЛЬНЫХ проблем при решении этой задачи. Да, это будет сиране костыль. Но я не вижу,почему бы ему не работать.
  • @solhov, ты предлагаешь сдаться и нихуя не делать, отличное решение
  • @ArkanoiD, ну не видишь. Ну что сказать. Пичалька. А помнишь ли ты о терминальных серверах?
  • @solhov, а что про них стоит помнить?
  • @ArkanoiD, я предлагаю за ум взяться и внтно изложить задачу
  • @solhov, вообще я не понимаю, с хрена вдруг тупой keepalive это ракетная физика и весь http ему поперек. Тот же gmail отлично знает,где у тебяживые и активные сессии и ему Заратуштра не запрещает.
  • @ArkanoiD, про их существование. Там у всех юзверей один ип
  • @solhov, а, это не сильно важно в данном контексте
  • @ArkanoiD, ничего он не знает. В http/1.0 кипалива нет, например
  • @ArkanoiD, у тебя хуй проссышь что важно и что нужно
  • @solhov, можно обойтись без 1.0. В общем,клиентский скрипт, который будет долбиться раз в оговоренное время тоже устроит, хоть это и хуже
  • @ArkanoiD, бладж, кончай моск ебать, все равно ты делаешь ровно то, что я сказал, только еще более через анус
  • @solhov, вот поэтому я не излагаю задачу от сотворения мiра, а задаю простой и конкретный технический вопрос.
  • @solhov, да почему, если в рамках http/1.1 мы можем обеспечить persistent connection и контролировать его умирание?
  • @ArkanoiD, ты хуйню придумал и спрашиваешь
  • @ArkanoiD, не можешь. Ты даже умирание тсп контролировать не можешь
  • @solhov, да с чего ты уверен что хуйню? предложи решение лучше.
    задача — авторизовать действия пользователя через firewall. при этом, кроме веб-окошка у нас ничего нет. на прокси, терминальные серверы и наты мы срали по условию задачи. для случаев когда не срали, есть отдельные мысли,что делать,которые сейчас к теме не относятся.
  • @solhov, почему не могу? если у меня есть возможность продернуть через канал туда-сюда какие-то данные — оченьдажемогу. Для telnet,скажем, эта задача тривиальна, для ssh тоже.
  • @ArkanoiD, не понимаю. Зачем? Авторизовывать надо через базу. Что за бред спрашивать ты себе разрешаешь на аську зайти?
  • @solhov, что значит "через базу"? о чем ты вообще?
  • @ArkanoiD, ну да, через пару часиков
  • @ArkanoiD, авторизация.
  • @solhov, почему через пару-то? как туда-сюда пролетели — так и считаем канал живым.
  • @solhov, б-же,причем тут какая-то "база"? повторю условие задачи: агента аутентикации на клиентской машине НЕТ.
  • @ArkanoiD, типичный кипалив у тцп. А то ведь и не включат
  • @solhov, а причем тут tcpшный keepalive-то? ты чем вообще читаешь? повторю еще раз:каналсчитается живым,когда через него вернулся ответ.
  • @ArkanoiD, причем тут агент, если речь про авторизацию?
  • @ArkanoiD, угу, вернулся. А потом канал помер.
  • @solhov, ну помер и хуй с ним. потому что с ним помрет и канал до приложения, запрашивающего авторизацию тоже.
  • @solhov, я не понял, к чему ты приплел "базу"
  • @solhov, (а оно-то как раз вполне себе stateful)
  • @ArkanoiD, к авторизации. потому что делать авторизацию у пользователя — глупость несусветная
  • @ArkanoiD, приложение, запрашивающие авторизацию — безусловно часть файрвола. так что ты какую-то фигню сечас сказал
  • @solhov, (facepalm) какая к зайкам "авторизация у пользователя"? у пользователя keepalive, проверка,что пользователь который уже авторизовался — еще там и не отвалился нах.
  • @solhov, херню сказал ты. смотри: пользователь открыл, скажем, ftp сессию. пользователь запросил дополнительную авторизацию, наша хреновина дернула его окошко браузера — ага, живой, пускаем. предположим, он сразу после этого отвалился. и что? нам похуй, потому что ftp-соединение отвалится вместе с ним.
  • @ArkanoiD, проверка, что пользователь авторизовался — она внутри файрвола и шутдаун девайса, если этого не происходит. зачем тебе неработающая инфраструктура?
  • @solhov, я тебя окончательно не понимаю. условно говоря, в рамках описанного, мне нужно аутентифицировать пользователя через web, а авторизовать его через ftp. что тут неясно? где тут неработающая инфраструктура?
  • @ArkanoiD, у кого он запросил? у файрвола? ты вообще понимаешь значение слов, которые употребляешь? не путаешь авторизацию с аутентификацией? не путаешь кто у кого что просит, а?
  • @ArkanoiD, авторизировать через ftp? у тебя на фтп лежит база в которой прописанны уровни доступа пользователей?
  • @solhov, по-моему это ты не понимаешь вообще о чем речь. база лежит на firewall'е. ftp является не способом, а объектом авторизации — мы проверяем,пускать ли его по ftp.
  • @ArkanoiD, когда говорят "авторизировать через Х", то Х является не объектом, а способом. авторизировать через tacacs+. авторизировать через radius.
  • @solhov, ох ты ж блядь, тебе разобраться хочется или цепляться к словам? мне нужно было пояснить что "авторизоваться через ftp" означает "авторизоваться для доступа по протоколу ftp"? это было непонятно из контекста или ты просто доебаться решил?
  • @ArkanoiD, Проще всего без всяких push, просто отдавать страничку, на которой скрипт раз в N секунд ломится на сервер. Сервер по прошествии 2N времени вычеркивает пользователя из списка живых. Никакой магии.
  • @dss, ну это запасной вариант если не получится по-человечески
  • @ArkanoiD, из твоего контекста вообще ничего не понятно, правда. ни для чего, ни кто на ком стоял. или я должен проявлять телепатию? короче, хочешь по простому и тебя удоволетворяют тайм-ауты — делай как все: страничка с refresh на тайм-аут. хочешь выебонов — java-applet. хочешь проблем — трахайся с попытками держать соединение. а юзверь esc жамкнет. или фарвол его локальный соединение закроет. или браузер соптимизирует и закроет. или у него браузер ебнется и он его еще раз запустит.
  • @solhov, во всех упомянутых тобой случаях не западло его еще разпопросить аутентифицироваться
  • @solhov, но было бы очень странно если бы это не делалось на pure js
  • @ArkanoiD, По-человечески не получится. Websockets нигде не работает, а все остальное — та же долбежка с клиента.
  • @dss, да нахуя вам всем скрипты сдались, бладж?! вам что, современный веб последний мозг отбил и извилины повыпрямлял? Refresh: 600 уже отменили?!
  • @ArkanoiD, У pure js нет контроля над соединением. Там можно только отправить запрос и получить ответ.
  • @dss, как-то удивительно,что на js можно легко написать что угодно, а вот штуку, которая бы СЛУШАЛА то, что ей пушат — внезапне,сложно
  • @ArkanoiD, ничего странного.
  • @ArkanoiD, HTTP вообще не умеет push. Все попытки прикрутить его — хаки и попытки наебать браузер.
  • @ArkanoiD, ага, и порвать закачки? я бы на месте клиента автора такого устройства анально покарал
  • @dss, ну, если это контролируемо, то push request может быть одним из вариантов ответа — если мы умеем ждать достаточно долго
  • @solhov, а причем тут закачки? у закачек собственный стейт, пока tcp под ними живет,никто их принудительно рвать не будет
  • @ArkanoiD, нихуя на js нельзя. ты поинтересуйся как-нибудь, как на js график нарисовать. это просто пиздец.
  • @ArkanoiD, Ты только что придумал long polling. Который и есть та бесконечная долбежка с клиента. Только клиент не отваливается, если данных нет, а ждет пока они появятся. Сути это не меняет.
  • @ArkanoiD, а, т.е. у тебя разлогинивание юзверя не рвет его сессии? я бы автора такого файрвола анально покарал.
  • @solhov, Ты правда идиот или притворяешься?
  • @dss, ну это надежный способ долбежки — он не дает "окна" когда у нас что-то может быть не то
  • @dss, что тебя не устраивает? если клиент сделал logout, то его сессии сквозь файрвол следует закрыть. мало ли кто там слушать сейчас может.
  • @ArkanoiD, Ну тогда вот тебе и ответ. При этом переподключаться все равно надо регулярно, но можно делать это внахлест, закрывая старое соединение уже после открытия нового, тогда дырок не будет.
  • @ArkanoiD, как ты думаешь, почему в индустрии уже лет 10 (или 15?) никто ничего лучшего не предлагает?
  • @solhov, потому что в этой индустрии уже 15 лет все через жопу
  • @dss, ага, теперь надо найти кого-нибудь, кто набросает прототип
  • @dss, ну можно по кусочкам и долго получать ответ. chunked-encoding. только выглядеть это будет как вечно недокачивающаяся страница — некрасиво. ну и соединение выедается. а при работе через проксю — количество соединений не per-site, а per-proxy.
  • @ArkanoiD, была бы возможность — давно кто-нибудь со стартапом вылез. нет, там все возможности через жопу.
  • @solhov, да не, просто такие частности никого толком не волнуют. ну мне сейчас примерно ясна архитектура и как ее встраивать в мою шнягу. что страница будет кагбе "постоянно висеть на загрузке" это совершенно пофиг
  • @ArkanoiD, А тебе ж эту фигню наверняка на plain C надо?
  • @dss, это сложнее почему-то? :-)
  • @ArkanoiD, Серверную часть http на plain C нетривиально реализовать. Только если какой-нибудь готовый embeddable server найти…
  • @dss, ну ему нужно-то обслуживать несколько тупых видов запросов
  • @ArkanoiD, выжираются соединения, в том числе до прокси. у меня так недавно броузер завесился, когда до одного сайта проблемы с каналом случились — все соединения на мелкой мишуре с него повисли и больше ничего не открывалось. вконеце-то концов нашел, кому надо было esc нажать, но не сразу.
  • @dss, собственно это от того, что "настоящий" веб-сервер туда тащить не стоит.
  • @solhov, ну, это неизбежные издержки.
  • @dss, да ты чё, я еще лет 10 назад http-сервер совмещенный с веб-администрилкой на plain C писал и заняло это все меньше 2000 строк.
  • @ArkanoiD, создавать гемор пользователям ради выебонов? ну не знаю.
  • @solhov, одно-два постоянно висящих соединения не заслуживают этого громкого слова — посмотри сколько их произвольный сайт с активно колбасящимся аяксом имеет
  • @solhov, вру. 3600 строк.
  • @solhov, я рад за тебя. но мне лень сейчас писать лишних 2000 строк на С, чтобы набросать для Арканоида прототип. а на каком-нибудь сраном питоне склепал бы, пока чай пью.
  • @ArkanoiD, 0 (спросил-закрыл). кстати, наверняка если с ссоедней страницы надо будет соединений наоткрывать — на остальных броузер всякие keep-alive закроет. сколько сейчас у ослика соединений я не знаю, но некоторое время назад у него лимит был 2 (прописью два) до прокси.
  • @dss, а чего не на агде?
  • @dss, да? склепай хоть на питоне, я перепишу потом если что :-)
  • @ArkanoiD, в клиентской части поставить js-таймер, который будет раз в минуту, скажем, долбиться на урл, типа пинг делать. Так реалистичнее всего. Если же совсем брутально делать, то можно через чистый HTML, через http-equiv refresh с таймаутом перегружать страницу.
  • @ArkanoiD, я б предположил, что можно в сторону ajax — на клиенте скриптик время от времени лезет к серверу, вот и keepalive. например на javascript.ru покопаться