Я запутался, помогите. :)
Пишу код в винде в vs code. Все проекты живут в, условно, c:\users\username\box\dev\, потому что box\ — точка монтирования облачного хранилища, которое синкает все между компом и ноутом (читай: дропбокс).
Код запускается из wsl1, куда я хожу по ssh. Это, может быть, извращение, но ssh сессий все равно всегда открыто несколько, плюс-минус одна — не важно, зато все в одном месте — удобно. В wsl1 тот самый box\ примонтирован как отдельно как /win.
Продакшен для всего кода — линух, докера нет ибо не нужен, везде git push/pull.
Очень удобно, что при изменении сети на винде (отключился от одного впн, подключился к другому впн, вообще выключил впн) в wsl1 оказывается всё та же виндовая сеть и не надо давить никакие кнопки.
Ну и изредка из wsl1 что-то делаю с пачками больших файлов, которые откуда-то (из внешнего мира) появились на виндовом диске.
А зачем Вам спецсимволы в пароле? По сути, речь идёт о том, чтобы на win-хосте поднять локальный прокси, на котором авторизация не требуется вовсе, и ходить из wsl на него. И уже на локальном прокси проходить аутентификацию на внешнем.
В случае доменной инфраструктуры внешний прокси скорее всего поддерживает NTLM, и здесь отлично подходит cntlm, который в своем конфиге пароля от доменной учётной записи вовсе не содержит.
Если уж совсем невмоготу, то спецсимволы в пароле можно заменять на hex-значения (url encode), то есть вместо @ будет %40 и так далее.
Не нужно настраивать прокси внутри wsl. Это ужасная практика, потому что когда инструментов внутри wsl станет много, а пароль поменяется — будет больно.
У себя в команде мы почти сразу пришли к сетапу, когда на win-хосте работает cntlm, а внутри wsl определены переменные окружения HTTP_PROXY и HTTPS_PROXY, смотрящие на cntlm. Те инструменты, которые в 2020 игнорируют эти переменные, настраиваются смотреть на cntlm вручную, но их довольно мало.
Никоим образом не относясь непосредственно к разработке фронта, мне таки приходится периодически его деплоить и немножко суппортить. И примерно раз в полгода вспоминается мне вот этот доклад в частности: https://events.yandex.ru/events/yac/2013?openTalkVideo=252-37
Мне как-то libpam-google-authenticator показался самым простым способом прикрутить 2FA. Никакой возни на клиенте вообще, и "искаропки" (ибо pam). Кайф же.
Пролистал по заголовкам несколько последних страниц с постами корп блога, может плохо смотрел, может случайно упустил нужные статьи. Подскажите, пожалуйста, где можно почитать про практическую сторону дела? В смысле, не говоря об очевидных вещах (как отправить емейл и где хранить лида), интересует ряд аспектов: встроить свой собственный канал коммуникаций (кастомные гуи, логика, интеграции, юзерские роли); строить кастомную логику поверх емейла (всякие там триггеры, трекинг, и прочие клёвые штуки); инсертить и удалять как-то из базы записи (иногда миллионами в день), желательно чтобы можно было и push и pull; иметь структуру данных сильно сложнее, чем "лид-опортьюнити-ордер-клиент" (а иногда ещё и многие-ко-многим) и крайне желательно, чтобы на миллионах исторических экшенов в базу можно было накидать новых полей и не умереть. И прочие подобные крутые штуки, с помощью которых можно крутить-вертеть коробку под свои нужды и процессы.
Таким образом, проблема вовсе не в высоких зарплатах программистов. Проблема в наличии огромного количества халтурщиков, которых некуда деть. Так ведь?
Как правило, на страницах авторизации 3DS видно в чью пользу совершается платёж. Клиент, приходя по кнопке "оплатить" интернет-магазина или сервиса не ожидает увидеть там ФИО физического лица, как правило.
Не очень ясен смысл затеи. У тинькова, например, есть готовый платёжный виджет для размещения на сайте. Почему не использовать его?
Странный UX. Клиент, покупая что-либо в вебе, ожидает на странице 3DS и в списке своих транзакций увидеть что-то понятное и релевантное продавцу.
А в Вашем случае клиент увидит card2card Иванову Ивану?
Честно говоря, вот это кино, на мой взгляд, самое лучшее обозрение того, что мы называем "рунет" глазами гуманитария, которому социальное ближе и интересней технологического. И это достойно. В конце концов про софт и DRM здесь все и так знают. А о влиянии на общество задумываются не все.
Вот тут Вы не совсем правы. Хотя это зависит от точки зрения.
С точки зрения типичного участника, скажем, Хабра, интерес представляют именно люди, чьи руки и головы стояли и стоят за технологиями, которые обеспечивают проистекание общественных процессов. То есть таки инженеров, делавших и делающих рунет технический.
А кино — оно про сами процессы, текущие в "народных массах". С этой точки зрения ключевые уже не инженеры, а движетели потоков. Пусть бы и поначалу движетелями бывали инженеры.
Все же рунет — как и любое другое общественное явление — это, в первую очередь, движение. Поток, внутри которого существуют другие потоки, во главе которых оказываются люди. Причем покуда задача людей во главе потока — определять повестку членов потока, инженеры в таких ролях — случайная случайность. В основном же во главе гуманитарии по складу ума. А софт вообще вторичен.
Так что все вполне сходится. Со временем вместо ролей "восторженных инноваторов-романтиков" на передний план выходят роли "Потупчик", "Навальный" и "Носик".
Берём контору, использующую MDM для BYOD (ну там, в корпоративный exchange ходить с айфончика, который парень на день рождения подарил).
Ставим в ближайшей кафешке сканер HS-платформы
Таргетируем на сотрудников, досягаемых через HS-платформу, фишинг с раздачей собственного SCEP профиля
????
PROFIT
Ручная модерация кампаний в диджитал маркетинге — это хорошо, но очень сильно дорого, когда кампании не свои, а партнёрские, и выручка от канала пропорциональна объему партнёрской базы и их кампаний. ИИ не панацея — примеров промахов существующих вендоров хватает.
Уповать на то, что если контора практикует BYOD, то конторский профиль запрещает установку сторонних — возможно. Но ровно до момента, пока сотрудникам массово очень сильно не захочется себе ещё профилей. То есть, пока предложения партнёров HS-платформы недостаточно щедры или всеобъемлющи.
С другой стороны, в свое время все тоже самое было с email каналом. И на сей раз приспособимся.
В aggregated отчётах DMARC по моим доменам видны случаи, особенно от yahoo/outlook.com и пары локальных европейских esp, когда письмо не прошло DMARC из-за fail'а DKIM и реже SPF, а IP-адрес в отчёте о таких письмах — один из хостов того самого esp. Сделать с этим вряд ли что-то можно, а включать reject с такими отчётами (единицы % от общей массы трафика) — страшно.
Я запутался, помогите. :)
Пишу код в винде в vs code. Все проекты живут в, условно, c:\users\username\box\dev\, потому что box\ — точка монтирования облачного хранилища, которое синкает все между компом и ноутом (читай: дропбокс).
Код запускается из wsl1, куда я хожу по ssh. Это, может быть, извращение, но ssh сессий все равно всегда открыто несколько, плюс-минус одна — не важно, зато все в одном месте — удобно. В wsl1 тот самый box\ примонтирован как отдельно как /win.
Продакшен для всего кода — линух, докера нет ибо не нужен, везде git push/pull.
Очень удобно, что при изменении сети на винде (отключился от одного впн, подключился к другому впн, вообще выключил впн) в wsl1 оказывается всё та же виндовая сеть и не надо давить никакие кнопки.
Ну и изредка из wsl1 что-то делаю с пачками больших файлов, которые откуда-то (из внешнего мира) появились на виндовом диске.
Стоит ли смотреть на wsl2 или черт с ним?
Моя мысль была не про то, чтобы влиять на пароль. А про то, чтобы вынести использование пароля из wsl на уровень win-хоста, где это зачастую проще.
А зачем Вам спецсимволы в пароле? По сути, речь идёт о том, чтобы на win-хосте поднять локальный прокси, на котором авторизация не требуется вовсе, и ходить из wsl на него. И уже на локальном прокси проходить аутентификацию на внешнем.
В случае доменной инфраструктуры внешний прокси скорее всего поддерживает NTLM, и здесь отлично подходит cntlm, который в своем конфиге пароля от доменной учётной записи вовсе не содержит.
Если уж совсем невмоготу, то спецсимволы в пароле можно заменять на hex-значения (url encode), то есть вместо @ будет %40 и так далее.
Не нужно настраивать прокси внутри wsl. Это ужасная практика, потому что когда инструментов внутри wsl станет много, а пароль поменяется — будет больно.
У себя в команде мы почти сразу пришли к сетапу, когда на win-хосте работает cntlm, а внутри wsl определены переменные окружения HTTP_PROXY и HTTPS_PROXY, смотрящие на cntlm. Те инструменты, которые в 2020 игнорируют эти переменные, настраиваются смотреть на cntlm вручную, но их довольно мало.
Никоим образом не относясь непосредственно к разработке фронта, мне таки приходится периодически его деплоить и немножко суппортить. И примерно раз в полгода вспоминается мне вот этот доклад в частности: https://events.yandex.ru/events/yac/2013?openTalkVideo=252-37
Мне как-то libpam-google-authenticator показался самым простым способом прикрутить 2FA. Никакой возни на клиенте вообще, и "искаропки" (ибо pam). Кайф же.
Где конкретно — не скажу. Но рекомендую, если интересно, полистать комьюнити больших и очень больших вендоров — и не такие масштабы бывают.
Пролистал по заголовкам несколько последних страниц с постами корп блога, может плохо смотрел, может случайно упустил нужные статьи. Подскажите, пожалуйста, где можно почитать про практическую сторону дела? В смысле, не говоря об очевидных вещах (как отправить емейл и где хранить лида), интересует ряд аспектов: встроить свой собственный канал коммуникаций (кастомные гуи, логика, интеграции, юзерские роли); строить кастомную логику поверх емейла (всякие там триггеры, трекинг, и прочие клёвые штуки); инсертить и удалять как-то из базы записи (иногда миллионами в день), желательно чтобы можно было и push и pull; иметь структуру данных сильно сложнее, чем "лид-опортьюнити-ордер-клиент" (а иногда ещё и многие-ко-многим) и крайне желательно, чтобы на миллионах исторических экшенов в базу можно было накидать новых полей и не умереть. И прочие подобные крутые штуки, с помощью которых можно крутить-вертеть коробку под свои нужды и процессы.
Спасибо!
Таким образом, проблема вовсе не в высоких зарплатах программистов. Проблема в наличии огромного количества халтурщиков, которых некуда деть. Так ведь?
Непонятна сфера применения шлюза. Для интернет-коммерции точно не годится. А зачем тогда?
Как правило, на страницах авторизации 3DS видно в чью пользу совершается платёж. Клиент, приходя по кнопке "оплатить" интернет-магазина или сервиса не ожидает увидеть там ФИО физического лица, как правило.
Не очень ясен смысл затеи. У тинькова, например, есть готовый платёжный виджет для размещения на сайте. Почему не использовать его?
Странный UX. Клиент, покупая что-либо в вебе, ожидает на странице 3DS и в списке своих транзакций увидеть что-то понятное и релевантное продавцу.
А в Вашем случае клиент увидит card2card Иванову Ивану?
Выходит, смысл исключительно в том, чтобы привести клиента на страницу перевода денег с предзаполненным получателем?
Честно говоря, вот это кино, на мой взгляд, самое лучшее обозрение того, что мы называем "рунет" глазами гуманитария, которому социальное ближе и интересней технологического. И это достойно. В конце концов про софт и DRM здесь все и так знают. А о влиянии на общество задумываются не все.
Вот тут Вы не совсем правы. Хотя это зависит от точки зрения.
С точки зрения типичного участника, скажем, Хабра, интерес представляют именно люди, чьи руки и головы стояли и стоят за технологиями, которые обеспечивают проистекание общественных процессов. То есть таки инженеров, делавших и делающих рунет технический.
А кино — оно про сами процессы, текущие в "народных массах". С этой точки зрения ключевые уже не инженеры, а движетели потоков. Пусть бы и поначалу движетелями бывали инженеры.
Все же рунет — как и любое другое общественное явление — это, в первую очередь, движение. Поток, внутри которого существуют другие потоки, во главе которых оказываются люди. Причем покуда задача людей во главе потока — определять повестку членов потока, инженеры в таких ролях — случайная случайность. В основном же во главе гуманитарии по складу ума. А софт вообще вторичен.
Так что все вполне сходится. Со временем вместо ролей "восторженных инноваторов-романтиков" на передний план выходят роли "Потупчик", "Навальный" и "Носик".
А можете заодно подсказать толковых ресурсов по админству и внедрению AEM? Документация адоби, как обычно, местами потрясающе неочевидна.
Ручная модерация кампаний в диджитал маркетинге — это хорошо, но очень сильно дорого, когда кампании не свои, а партнёрские, и выручка от канала пропорциональна объему партнёрской базы и их кампаний. ИИ не панацея — примеров промахов существующих вендоров хватает.
Уповать на то, что если контора практикует BYOD, то конторский профиль запрещает установку сторонних — возможно. Но ровно до момента, пока сотрудникам массово очень сильно не захочется себе ещё профилей. То есть, пока предложения партнёров HS-платформы недостаточно щедры или всеобъемлющи.
С другой стороны, в свое время все тоже самое было с email каналом. И на сей раз приспособимся.
Так DKIM цел. От остальных esp приходят отчёты с успехами обработки политик. То есть это именно локальные проблемы и/или некорректные реализации esp.
В aggregated отчётах DMARC по моим доменам видны случаи, особенно от yahoo/outlook.com и пары локальных европейских esp, когда письмо не прошло DMARC из-за fail'а DKIM и реже SPF, а IP-адрес в отчёте о таких письмах — один из хостов того самого esp. Сделать с этим вряд ли что-то можно, а включать reject с такими отчётами (единицы % от общей массы трафика) — страшно.