А не означает ли это, что скомпрометированный компьютер в корпоративной сети потенциально будет иметь доступ к локальному веб-серверу на других компьютерах сети? Есть ли в локальном веб-сервере проверки на то, откуда пришел запрос?
Или ответственность за это перекладывается на админов?
Это все, конечно, замечательно, но держать в продукиве апач только ради SSO как-то не охота. А nginx, когда я последний раз смотрел, с керберосом особо не дружил.
Приходится пользователям немного страдать все еще…
Не очень понятно о чем конкретно статья.
Автомобиль лучше или хуже велосипеда? А вертолет автомобиля?
Облако — суть еще один способ решения задачи, остается задача выбора способа решения и эту задачу каждый решает сам.
Развернуть сегодня 1С внутри офиса на 10-15 пользователей стоит на круг (железки и софт) порядка полумиллиона рублей в клиент-сервере и сильно меньше (можно уложиться и в сто тысяч) при толстых клиентах и файловых базах на шарах. Или за 50-150 тысяч в год облака.
А вот развернуть у себя, например, сервис для большого количества заказчиков (sla, резервирование и вот это вот все) — уже миллион и выше. Или опять 50-150 в год облака.
Но как часто в SMB нужно обновлять серверные парки 1С? А серверные парки растущих клиентских сервисов?
Вокруг облака много пиара, просто потому, что про другой способ все и так знают, а единовременные затраты оборотных средств на облако всегда ниже, на это и упор.
Что значит «не в их компетенции»? Я не холивара для, а интереса из.
Ведь если вы продаете услуги отечественным юрлицам — у вас либо есть ооо/ип/проч., зарегистрированный в РФ (и как тогда быть с предписанием?), либо бухгалтерия клиента должна уметь и смело платить иностранным контрагентам (что тоже не всегда и везде просто).
Или платит лично директор с карточки?
Это так.
Но вот банальный и попсовый кейс: кто-то хакнул чей-то сайт и вместе с контентом прилетает обфусцированный «злой» код на JS. Это противно, но понимаемо — код можно развернуть и понять что и как.
В случае же бинарных данных — что делать? Всем срочно учить asm, дизассемблировать бинарники и ковыряться? По мне — для предприятий проще будет забанить на уровне корпоративной прокси получение таких данных, а за корпоративными проксиками так или иначе находится приличный процент веб-аудитории.
Как по мне, так Ruby — просто еще один язык. Нет в нем вещей (особенно под веб), которые нельзя сделать на другом языке, равно как и наоборот.
Что меня сильно напрягает пока что в нем — символы. Чувакам захотелось создавать хэши как {a: «b»}, и чтобы быстрее, чем {«a» => «b»} и чуваки запилили новый тип данных по сути. Это какая-то страшная глупость, по-моему. Все эти .to_sym, .to_s и прочие .intern нехило рвут шаблон по первости.
Претензии к windows тоже не очень понятно зачем — в окошках удобно жить только с с# и прочим дотнетом, для всего остального, переносимого из unix, надо будет что-то делать руками. А зачем? Имхо, пытаться строить системы на ОС только потому, что в команде есть фанаты данной ОС и им «неудобно» — еще одна страшная глупость, прямо как символы в Ruby.
Все равно может не спасти.
Я подозреваю, что полетная документация — штука не публичная (если вообще не закрытая и не выдаваемая «под роспись») и для ее распространения на планшеты используют какую-либо MDM-систему (щас они почти все умеют разливать по устройствам защищенный контент и им управлять).
В случае, если система не сможет залить документы (например банальное: забыли перевыпустить сертификат) — она не зальет их на все устройства, которые обслуживает.
Справедливости нет.
Однако пока в одной чксти света результатом работы людей является новый поезд, в другой части света результатом работы людей является акт сдачи/приемки в эксплуатацию. Разницу чувствуете? :)
ActiveX, как я понял, нету. Настроек всяких там безопасностей и исполнений апплетов и прочего тоже нету. То есть это не браузер, это игрушка для хипстеров — ее не настроить через GPO и с ее помощью нельзя будет нормально работать с 90% интранет-систем в бизнесе.
Из всего этого следует, что где-то рядом со Спартанцем будет жить себе мирно IE11. Тогда зачем это всё?)
Простите, но зачем это все?
Почему нельзя взать инсталлер Битрикса как любой другой cms и развернуть на хосте в нужном месте будь то корень домена или любой другой каталог?
В моем понимании все эти «готовые виртуальные машины с %systemname%» хороши только в одном случае — для быстрого прототипирования и показа заказчику. Во всех остальных случаях нужно готовить хост согласно привычке/снадартам/лучщим практикам и ставить на него нудные системы. Или вообще использовать докер.
А можно реквестировать пост на хабре или большой красный баннер «мы наконец-то выпилили l2tp»?)
Ну и про сам процесс перехода почитать будет интересно.
Подождите…
То есть получается, что вот например, я пригласил подрядчика поднять сервис на вин-сервере. Сервис большой, энтерпрайзный, и, как у них заведено, хочет работать от учетки с правами локал админа и от нее же устанавливаться.
То есть я дал подрядчику учетку с правами локал админа на сервере в домене.
И теперь подрядчик может так вот «запросто» угнать пароли всех доменных пользователей, которые логинились на сервер после последней перезагрузки?
Итого это еще один повод админам иметь две учетки: с правами админа везде, кроме контроллера и с правами админа на контроллере; или что еще делать-то? О.о
Бывают крупные внедрения/миграции enterprise-продуктов. Обычно такие проекты бьются на этапы, но этап может длиться несколько месяцев и стоить несколько миллионов.
Программирование программированию рознь и спор этот вечен.
Моя скромная позиция интегратора примерно такова:
1. 1С не самое плохое решение и не самое хорошее. Но в своей нише (цена/функциональность) крупных конкуррентов у системы нет. Enterprise продукты, позволяющие строить аналогичные УС проще/быстрее/каноничней/понятней стоят в несколько раз дороже. Если у вас работает 20-100 человек — вы, скорее всего, выберете 1С и это будет даже дешевле, чем если начнеете писать с нуля.
2. У 1С есть потолок. И по количеству данных и по качеству. Рано или поздно производительность начнет деградировать, а необходимость привнести в данные новых связей — вызывать желание напится.
3. Переезд в «enterprise» из 1С — это отдельный цирк с конями. Вообще на мой взгляд самые сложные миграции данных (если не брать в расчет документоориентированные вещи) — миграция с 1С куда угодно.
Ну и да, 1С — это, все таки, не язык. Это фреймворк уровнем выше, чем пресловутый .net.
Или ответственность за это перекладывается на админов?
Приходится пользователям немного страдать все еще…
Автомобиль лучше или хуже велосипеда? А вертолет автомобиля?
Облако — суть еще один способ решения задачи, остается задача выбора способа решения и эту задачу каждый решает сам.
Развернуть сегодня 1С внутри офиса на 10-15 пользователей стоит на круг (железки и софт) порядка полумиллиона рублей в клиент-сервере и сильно меньше (можно уложиться и в сто тысяч) при толстых клиентах и файловых базах на шарах. Или за 50-150 тысяч в год облака.
А вот развернуть у себя, например, сервис для большого количества заказчиков (sla, резервирование и вот это вот все) — уже миллион и выше. Или опять 50-150 в год облака.
Но как часто в SMB нужно обновлять серверные парки 1С? А серверные парки растущих клиентских сервисов?
Вокруг облака много пиара, просто потому, что про другой способ все и так знают, а единовременные затраты оборотных средств на облако всегда ниже, на это и упор.
Ведь если вы продаете услуги отечественным юрлицам — у вас либо есть ооо/ип/проч., зарегистрированный в РФ (и как тогда быть с предписанием?), либо бухгалтерия клиента должна уметь и смело платить иностранным контрагентам (что тоже не всегда и везде просто).
Или платит лично директор с карточки?
Но вот банальный и попсовый кейс: кто-то хакнул чей-то сайт и вместе с контентом прилетает обфусцированный «злой» код на JS. Это противно, но понимаемо — код можно развернуть и понять что и как.
В случае же бинарных данных — что делать? Всем срочно учить asm, дизассемблировать бинарники и ковыряться? По мне — для предприятий проще будет забанить на уровне корпоративной прокси получение таких данных, а за корпоративными проксиками так или иначе находится приличный процент веб-аудитории.
И каждый сайт теперь — черный ящик?
А потом выкинем все нафиг и будем использовать JSON. Ну ок.
Что меня сильно напрягает пока что в нем — символы. Чувакам захотелось создавать хэши как {a: «b»}, и чтобы быстрее, чем {«a» => «b»} и чуваки запилили новый тип данных по сути. Это какая-то страшная глупость, по-моему. Все эти .to_sym, .to_s и прочие .intern нехило рвут шаблон по первости.
Претензии к windows тоже не очень понятно зачем — в окошках удобно жить только с с# и прочим дотнетом, для всего остального, переносимого из unix, надо будет что-то делать руками. А зачем? Имхо, пытаться строить системы на ОС только потому, что в команде есть фанаты данной ОС и им «неудобно» — еще одна страшная глупость, прямо как символы в Ruby.
Я подозреваю, что полетная документация — штука не публичная (если вообще не закрытая и не выдаваемая «под роспись») и для ее распространения на планшеты используют какую-либо MDM-систему (щас они почти все умеют разливать по устройствам защищенный контент и им управлять).
В случае, если система не сможет залить документы (например банальное: забыли перевыпустить сертификат) — она не зальет их на все устройства, которые обслуживает.
Однако пока в одной чксти света результатом работы людей является новый поезд, в другой части света результатом работы людей является акт сдачи/приемки в эксплуатацию. Разницу чувствуете? :)
Из всего этого следует, что где-то рядом со Спартанцем будет жить себе мирно IE11. Тогда зачем это всё?)
Почему нельзя взать инсталлер Битрикса как любой другой cms и развернуть на хосте в нужном месте будь то корень домена или любой другой каталог?
В моем понимании все эти «готовые виртуальные машины с %systemname%» хороши только в одном случае — для быстрого прототипирования и показа заказчику. Во всех остальных случаях нужно готовить хост согласно привычке/снадартам/лучщим практикам и ставить на него нудные системы. Или вообще использовать докер.
Ну и про сам процесс перехода почитать будет интересно.
То есть получается, что вот например, я пригласил подрядчика поднять сервис на вин-сервере. Сервис большой, энтерпрайзный, и, как у них заведено, хочет работать от учетки с правами локал админа и от нее же устанавливаться.
То есть я дал подрядчику учетку с правами локал админа на сервере в домене.
И теперь подрядчик может так вот «запросто» угнать пароли всех доменных пользователей, которые логинились на сервер после последней перезагрузки?
Итого это еще один повод админам иметь две учетки: с правами админа везде, кроме контроллера и с правами админа на контроллере; или что еще делать-то? О.о
Моя скромная позиция интегратора примерно такова:
1. 1С не самое плохое решение и не самое хорошее. Но в своей нише (цена/функциональность) крупных конкуррентов у системы нет. Enterprise продукты, позволяющие строить аналогичные УС проще/быстрее/каноничней/понятней стоят в несколько раз дороже. Если у вас работает 20-100 человек — вы, скорее всего, выберете 1С и это будет даже дешевле, чем если начнеете писать с нуля.
2. У 1С есть потолок. И по количеству данных и по качеству. Рано или поздно производительность начнет деградировать, а необходимость привнести в данные новых связей — вызывать желание напится.
3. Переезд в «enterprise» из 1С — это отдельный цирк с конями. Вообще на мой взгляд самые сложные миграции данных (если не брать в расчет документоориентированные вещи) — миграция с 1С куда угодно.
Ну и да, 1С — это, все таки, не язык. Это фреймворк уровнем выше, чем пресловутый .net.