alexvdem, видимо, нужно пояснить. Я видел, что там написано. Однако, думаю, вы и сами за минуту можете накидать несколько "относительно честных способов", как маркетологи могут предлагать бесплатную услугу, однако, ее настоящее использование будет все таки стоит денег. Именно поэтому я и спросил, про ваш личный опыт и ваше мнение. То, что есть питоновские либы я тоже видел (вопрос ведь был не о том), но сходу не увидел в них функционал о приеме push уведомлений. Вполне вероятно, что он там есть, но опять же по этой причине и спросил ваше мнение.
В любом случае, спасибо вам за ваш первый комментарий, в нем была новая и интересная информация.
Дмитрий, да, такое будет работать. Просто в скрипте надо будет добавить эту проверку времени файла. Просто, думал, может быть есть вариант как-то красивее это сделать (тут у нас и cron и http).
alexvdem, не хотелось опираться на внешний сервис, но идея интересная. Это еще и бесплатно? Для питона есть либы чтобы слушать оповещения с таймаутом, не знаете?
Lynn «Кофеман», по HTTP хочется, чтобы приходило просто уведомление, оповещение, сигнал с минимумом информации "что-то случилось, самое время разобраться и если надо - поделать их" (самих данных может быть очень много). Но HTTP запрос - штука ненадежная. Могут быть любые сетевые проблемы иногда, а серверная часть оповещений должна быть легкая, а не так, что если вдруг клиент выключился - сервер без остановки пытается его долбить неделю. (представим, что таких клиентов тысяча, и из этой тысячи десяток мертвые)
Поэтому хочется иметь дублирующий механизм который просто по тайм-ауту будет выполнять проверки. (нет новостей 5 минут? Окей, проверим сами). Но он не запускается если оповещения приходят достаточно часто.
Представим аналогию, что мы работаем с почтой. Клиент - что-то вроде fetchmail, раз в 5 мин проверяет и качает почту по POP3. И мы хотим чтобы почтовый сервер нас оповещал сразу же при приходе нового письма, и мы сразу же скачали почту.
Но целиком полагаться на HTTP не можем, поэтому нужно оставить запуск через 5 минут после предыдущего запуска. Это позволит восстановиться после любого сетевого сбоя, потеряв не более 5 минут.
Lynn «Кофеман», без слипа получится, что работа появляется раз в день, допустим, а клиент будет грузить сервер нон-стоп почти на сто процентов. "Есть там что новое? А сейчас? А щас? А щас появилось? А может сейчас есть?". Вот и нужно как-то не допускать тысячи бесполезных запросов в минуту.
SuperNickname, спасибо. Termux вроде и в плеймаркете есть. Или там он не такой? Это личное предпочтение или пробовали его с клавиатурой, и он нормально передает Esc и Enter?
eegmak, может быть кто-то более компетентный ответит - я не знаю. Но как я по Esc понял - это даже не в столько в руте дело, сколько в какой-то хитрой-кривой схеме, которая есть в одном SSH клиенте, и нету в других. Может каким-то таким способом это и можно.
Но вообще, почти все клиенты имеют либо свою визуальную клавиатуру (со всеми кнопками), либо микро-клавиатуру со спецклавишами (esc, ctrl, alt, tab, итд). Так что вообще задача послать какую-то комбинацию - она точно решаема и решаема легко. Другое дело, что это все делается немного переподвыподвертом. Пару раз тыкнуть в экран аэромышкой или обычно USB мышкой или пальцем на планшете - несложно. Но все таки, мозг хочет машинально любую привычную комбинацию пальцами очень быстро исполнить за полсекунды. И когда несколько раз вместо полсекунды тратишь пять секунд - это постепенно может начать выбешивать :-)
eegmak, у меня alt-tab работает (меняет вкладки на андроиде), а ctrl-c в SSH-сессии (JuiceSSH) - передается на сервер, например, останавливает ping. А вот Esc во всех SSH клиентах кроме одного отрабатывался локально (как "назад", выход из сессии), так что редактировать в vi просто невозможно было.
Борис Сёмов, Клавиатура "полноразмерная", как бы для десктопа? Или явно смартфонно-планшетная? (просто, может быть они отличаются как-то?). А какой SSH клиент? Я вот заметил, что JuiceSSH даже у меня как-то справляется с обычной клавиатурой.
lohatnikov, я так понял, в пределах одного сервера (origin), JWT в принципе не нужен. Лучше использовать сессии и куки.
А в ситуации нескольких сервисов (причем, возможно, от разных вендоров) - нужно как-то авторизацию на одном сервисе передать на другой, и куки тут уже не помогут. Поэтому правильный способ - использовать JWT для такой передачи, но вообще не хранить его. Получили JWT с первого сервиса, использовали на втором сервисе, получили куку от второго сервиса и забыли JWT.
Mikhail Osher, ага, я тут думал, есть два вида проектов:
1. Небезопасные, потому что написаны на чем-то древнем и уязвимом по дизайну (вроде PHP)
2. Небезопасные, потому что написаны на чем-то новом, модном, что еще во-первых само не отлажено и дыряво, и во-вторых, программист не имеет большого опыта с этим новым (потому что оно новое).
Олег Гамега, да, можно закрыть от чтения. Но выигрыш мне не очевиден. Проблема же не в том, чтоб не прочитали, а чтоб не воспользовались. (Мы боимся, что прочитают, потому что потом пошлют запрос с тем же значением куки). А внедренный враждебный скрипт из браузера аутентифицированного пользователя вполне может отправлять запросы к серверу, эти запросы будут принадлежать авторизованной сессии (так как будут включать куку). Хоть само значение куки он не узнает, но пользоваться им будет.
Олег Гамега, это чем-то по результатам отличается от ситуации с куками? Вот есть у нас сессионная кука для db.example.com, и мы в штатном режиме отправляем на db.example.com запросы. Потом нам в страничку через XSS внедрили JS скрипт. Он ничего из localStorage не прочтет (мы же умные, у нас только кука, да и та httpOnly), но он пошлет запрос на db.example.com, что-нибудь оттуда прочтет или запишет, и добрый браузер добавит в этот запрос куку. Тот же самый ущерб, разве нет? Кука/токен нужны же ведь не как самоцель, а чтобы предотвратить "враждебные" запросы. И код из third-party скрипта так же может пользоваться кукой (хотя и не может прочитать ее).
Или вы какую-то другую ситуацию-уязвимость видите, где кука более выигрышная?
Alex, посмотрел видео. парень поругал JWT, но это на мой вопрос не ответило. Да, он ругает JWT аргументированно, но проблема отзыва токена меня сейчас не волнует, зато волнует вопрос, как предотвратить взлом исходно. И если рассматривать угрозу, что кто-то внедрил свой код на страницу (XSS), получается, что в любом случае (и с куками и с токеном) - он сразу получает все, и нет возможности это никак предотвратить? использование или неиспользование localStorage ни на что не влияет.
Сергей Горностаев, да в общем-то нет особых проблем. Вопрос больше о том, чтоб понять, почему авторы текстов (довольно авторитетные) отговаривают от этого.
Хотя одну из возможных причин против куки я вижу - когда аутентификацию делаем в одном месте (auth0/okta/...), а JWT надо отправлять на другой сервис. Добавил в вопрос ссылки на "отговаривания".
вебсокет хорош тем, что сервер у нас на сервере, а клиент - клиент. может и за NAT'ом быть. В этом случае, запускать вебсервер на клиентской машине нет смысла - мы просто не достучимся ведь до нее. (я согласен, так было б гораздо проще, нужный URL дергать изредка).
В любом случае, спасибо вам за ваш первый комментарий, в нем была новая и интересная информация.