Как ни странно, любой файрвол умеет аутентифицировать не только HTTP, но и FTP. И NTLM везде подерживается для него.
Вообще для меня новость. Не подскажете, какой RFC регламентирует применение NTLM в FTP-прокси?
SOCKS — штука прозрачная.
Вообще-то, Socks это протокол.
Видимо подразумевается какое-то решение типа sockscap (проприетарное, x86-only) может прозрачно заставить некоторые tcp-приложения юзать socks-прокси (и то, если протокол требует несколько согласованных tcp-соединений, как ftp в активном режиме, работать не будет)
А сейчас то же самое с пайпами.
На unix-like роутерах легко давать правила типа «эта группа (ip-адресов) в этом пайпе и в сумме у них 1 мегабит», «а каждый юзер из это группы — по 2 мбита»
ок, пусть будет не торрент.
Чисто по работе. Есть такие тётеньки гуманитарные — контент-менеджеры, и они хотят заливать картинки по FTP на хостинг. Про SOCKS они слышать не хотят, админу тоже нежелательно локально что-то настраивать. Поэтому политика по IP
Нет, пример не работает ))))
Это голый SQL. Я хочу полноценную объектную модель, чтобы положить клиенту в список заказов новый заказ, сказать Save и заказ сохранился и привязался к клиенту.
Я хочу не писать Join-ы руками, как в ваших примерах,
.From(Order)
.FullJoin(Customer)
.On(COLUMN.Of(Order) == COLUMN1.Of(Customer))
.FullJoin(City)
.On(COLUMN.Of(City) == COLUMN1.Of(Customer))
а тупо сделать .Where(order => order.Customer.City.Name='Москва')
А два join-а фреймворк сделал сам. Разница, как между Фортраном и Паскалем.
А функции… Например, bin_and(x,y) или «Customer.Name starting with 'Пет' » в Firebird. Имелось ввиду, каких это затащить в синтаксис Where, чтобы пользоваться плюшками СУБД и генератора SQL одновременно
Главный недостаток предложенного фреймфорка — это трансляция в голый SQL, когда нормальные ORM умеют мапить объект по нескольким таблицам, поддерживают наследование, lazy-загрузку по ссылкам, поддержку отношений 1-ко-многим и их lazy-загрузку либо генерацию sql по аггрегированным запросам к ним т.п.
Отлично — работник может залогиниться на любом компьютере и получить одни и те же права. Причем тут тюрьма?
И какие еще костыли? Есть задача: пользователю (человеку) предоставить определенные права. Правильное решение — назначить права его учетке. Костыль — работать на уровне IP адресов. Это просто нелогично.
Я не спорю, что правильная аутентификация — по учётке. На внутренних сервисах (Exchange, Sharepoint) так и есть. Но для доступа в сеть из зоопарка кривых программ (настройте-ка uTorrent по NTLM) фильтр по IP подходящий компромис.
А зачем тогда вообще DHCP?
Наверное, чтобы не бегать по машинам, переконфигурируя интерфейс, если внезапно PDC и DNS перенесли в другую сеть.
На всякий случай — это такое заглядывание в далёкое и неизбежное будущее, я не говорю, что сейчас так надо делать.
Производительность будет выше, т.к. нет процессов, нет kernel и user, нет IPC, нет классического клипбоарда (любая передача данных — просто ссылка на managed-объект, а все объекты пусть будут read/only, как в чистом лиспе).
Падений не будет, т.к. ВЕСЬ код формально верифицирован и доказана правильность выполнения при корректных входных данных. А проверка корректности входа будет выполнятся единожды при передаче на вход алгоритма. Там, где доказательство провалилось, проверки будут как обычно (к слову, постоянный challenge для математиков: если какая-то сортировка не доказывается формально, а интуитивно правильная, это надо исправлять и фиксить «компилятор»)
Транслируется в 1 sql-запрос, который выберет лучшего клиента (по кол-ву дорогих заказов). Границы между данные в базе и загруженными в память стёрты (хотя можно гибко управлять политиками загрузки, если требуется оптимизация).
Если отвлечься от практики и потеоретизировать, направление на managed-среды в ОСестроительстве давно просматривается (Microsoft чтобы внезапно не оказаться отставшей понемногу тоже пилит).
Плюсы понятны: убрать границы между процессами. Убрать оверхед на IPC и переключение адресных пространств. С другой стороны, будут подтягиваться компиляторы и верификаторы программ. В циклах проверка границ будет только для начального и конечного индекса, а не при каждом обращении к массиву и т.п. Это уменьшит тормоза managed-кода. В идеале компилятор научится полностью доказывать корректность алгоритма (сейчас это возможно, но очень затратно вычислительно) и ставить проверки только на входные параметры функции, а программисту давать warnings — «не могу оптимизировать, выкинув проверки, потому что в таких-то входах программа свалится».
Но пока в юзер-программах есть хоть строчка native-кода, это остаётся небезопасным.
У компании должна быть выработана политика, в которой перечислены разрешенные к употреблению приложения.
Политика вырабатывается не админом, а спускается сверху.
Есть установка делать хорошо работнику, а не превращать рабочее место в тюрьму, особенно когда ничего секретного нет. Оплата за качество и количество сделанной работы, плюс комфорт (всегда можно отвлечься и отдохнуть) делают чудеса: юзеры не отсиживают с 9 до 18 и галопом по звонку домой, а могут без напряга и до 22 поработать. В результате все в выигрыше.
Вариантов полно
Не понимаю, в чём зло фиксированных адресов, что вы готовы столько костылей нагородить в их защиту. При заведении рабочео места просто адрес берётся из соответствующего диапазона, который везде прописан для какой-то политики и всё. Единственный минус, когда за компом могут работать в разные смены, но как правило политика для таких юзеров общая (а если нет, дешевле отдельный комп поставить, и работнику будет комфортнее)
js среди динамических языков занимает место, которое принадлежит C++ у статических.
Все ругают, но в то же время стандарт, куча библиотек, гибкость и т.п.
Юс-кейсы типа «дружбану Васе надо открыть Квейк и Старкрафт» приводят к тому, что потребуется-таки фиксировать его IP в DHCP
http-прокси привязывать к IP легче, чем к NTLM.
Потому что каждый второй автор опен-сорс мнит себя супер-кодером и http-стек делает сам на сокетах, вместо вызова неправославного WinInet.DLL. в итоге, если поддержка прокси и есть, то либо basic, либо md5 digest.
DHCP принято использовать там, где абсолютно неважно, какой адрес схватит клиент
У нас DHCP выдаёт фиксированный адрес (соответствующий MAC).
Иначе как реализовывать хотелки начальства типа «А закрой (открой) ЭТОМУ компу в отделе полный доступ в инет»
Неизвестным MAC-ам выдаётся адрес из пула, который никуда не имеет доступ.
Вообще для меня новость. Не подскажете, какой RFC регламентирует применение NTLM в FTP-прокси?
Вообще-то, Socks это протокол.
Видимо подразумевается какое-то решение типа sockscap (проприетарное, x86-only) может прозрачно заставить некоторые tcp-приложения юзать socks-прокси (и то, если протокол требует несколько согласованных tcp-соединений, как ftp в активном режиме, работать не будет)
На unix-like роутерах легко давать правила типа «эта группа (ip-адресов) в этом пайпе и в сумме у них 1 мегабит», «а каждый юзер из это группы — по 2 мбита»
Чисто по работе. Есть такие тётеньки гуманитарные — контент-менеджеры, и они хотят заливать картинки по FTP на хостинг. Про SOCKS они слышать не хотят, админу тоже нежелательно локально что-то настраивать. Поэтому политика по IP
Это голый SQL. Я хочу полноценную объектную модель, чтобы положить клиенту в список заказов новый заказ, сказать Save и заказ сохранился и привязался к клиенту.
Я хочу не писать Join-ы руками, как в ваших примерах,
.From(Order)
.FullJoin(Customer)
.On(COLUMN.Of(Order) == COLUMN1.Of(Customer))
.FullJoin(City)
.On(COLUMN.Of(City) == COLUMN1.Of(Customer))
а тупо сделать .Where(order => order.Customer.City.Name='Москва')
А два join-а фреймворк сделал сам. Разница, как между Фортраном и Паскалем.
А функции… Например, bin_and(x,y) или «Customer.Name starting with 'Пет' » в Firebird. Имелось ввиду, каких это затащить в синтаксис Where, чтобы пользоваться плюшками СУБД и генератора SQL одновременно
Наверное, чтобы не бегать по машинам, переконфигурируя интерфейс, если внезапно PDC и DNS перенесли в другую сеть.
Производительность будет выше, т.к. нет процессов, нет kernel и user, нет IPC, нет классического клипбоарда (любая передача данных — просто ссылка на managed-объект, а все объекты пусть будут read/only, как в чистом лиспе).
Падений не будет, т.к. ВЕСЬ код формально верифицирован и доказана правильность выполнения при корректных входных данных. А проверка корректности входа будет выполнятся единожды при передаче на вход алгоритма. Там, где доказательство провалилось, проверки будут как обычно (к слову, постоянный challenge для математиков: если какая-то сортировка не доказывается формально, а интуитивно правильная, это надо исправлять и фиксить «компилятор»)
Транслируется в 1 sql-запрос, который выберет лучшего клиента (по кол-ву дорогих заказов). Границы между данные в базе и загруженными в память стёрты (хотя можно гибко управлять политиками загрузки, если требуется оптимизация).
Плюсы понятны: убрать границы между процессами. Убрать оверхед на IPC и переключение адресных пространств. С другой стороны, будут подтягиваться компиляторы и верификаторы программ. В циклах проверка границ будет только для начального и конечного индекса, а не при каждом обращении к массиву и т.п. Это уменьшит тормоза managed-кода. В идеале компилятор научится полностью доказывать корректность алгоритма (сейчас это возможно, но очень затратно вычислительно) и ставить проверки только на входные параметры функции, а программисту давать warnings — «не могу оптимизировать, выкинув проверки, потому что в таких-то входах программа свалится».
Но пока в юзер-программах есть хоть строчка native-кода, это остаётся небезопасным.
Политика вырабатывается не админом, а спускается сверху.
Есть установка делать хорошо работнику, а не превращать рабочее место в тюрьму, особенно когда ничего секретного нет. Оплата за качество и количество сделанной работы, плюс комфорт (всегда можно отвлечься и отдохнуть) делают чудеса: юзеры не отсиживают с 9 до 18 и галопом по звонку домой, а могут без напряга и до 22 поработать. В результате все в выигрыше.
Не понимаю, в чём зло фиксированных адресов, что вы готовы столько костылей нагородить в их защиту. При заведении рабочео места просто адрес берётся из соответствующего диапазона, который везде прописан для какой-то политики и всё. Единственный минус, когда за компом могут работать в разные смены, но как правило политика для таких юзеров общая (а если нет, дешевле отдельный комп поставить, и работнику будет комфортнее)
Все ругают, но в то же время стандарт, куча библиотек, гибкость и т.п.
Юс-кейсы типа «дружбану Васе надо открыть Квейк и Старкрафт» приводят к тому, что потребуется-таки фиксировать его IP в DHCP
http-прокси привязывать к IP легче, чем к NTLM.
Потому что каждый второй автор опен-сорс мнит себя супер-кодером и http-стек делает сам на сокетах, вместо вызова неправославного WinInet.DLL. в итоге, если поддержка прокси и есть, то либо basic, либо md5 digest.
Конечно, v4. Я сейчас не скажу точное название технологии, но DHCP-сервер один, а свичи умеют его как бы проксировать в сети отделов.
И как это сделать, если клиенты — Windows, а шлюз — FreeBSD либо RouterOS?
У нас DHCP выдаёт фиксированный адрес (соответствующий MAC).
Иначе как реализовывать хотелки начальства типа «А закрой (открой) ЭТОМУ компу в отделе полный доступ в инет»
Неизвестным MAC-ам выдаётся адрес из пула, который никуда не имеет доступ.