2009-07-05 11 views
2

Я работаю над тем, чтобы мое приложение было проще использовать для администраторов. Одна из вещей, которые я действительно хотел бы сделать, это позволить администраторам изменять другие настройки пользователя изнутри программы, но при этом позволяет постоянным пользователям изменять свои собственные параметры, поскольку мое приложение не обязательно только для администраторов, которые хотят заставить пользователей использовать определенные настройки.Позволяет администраторам изменять настройки пользователя из моей программы - какой у меня лучший вариант?

Я подумал о двух возможных способов сделать это:

1) Переместить путь к файлу настройки пользователя, из которого сейчас (CLSID_APPDATA, часто Документы и настройки \ Имя) в мире -доступный путь (CLSID_COMMON_APPDATA, обычно Документы и настройки \ Все пользователи). Затем сохраните настройки каждого пользователя в уникальном файле для пользователя (вероятно, имея имя, равное имени текстового SID пользователя), поэтому папка выглядит примерно так:

C: \ Documents and Settings \ All Users \ My Company \ Моя программа \ настройки \ 123-abc-456-def.settings
C: \ Documents and Settings \ All Users \ Моя компания \ Моя программа \ Настройки \ 234-bcd-477-xyz.settings
C: \ Documents и Settings \ All Users \ My Company \ Мои настройки программы \ \ 946-HDC-743-ddd.settings

Плюсы:

  • Это позволяет администратору видеть и непосредственно измените настройки любого пользователя, потому что путь COMMON_APPDATA одинаковый для всех пользователей. Это, как я на самом деле, как это будет - это самый простой - но есть крупный жулик:
Минусы:

  • разрешения может быть проблемой. Чтобы позволить обычным пользователям сохранять свои настройки, вы должны разрешить пользователям писать доступ к папке настроек COMMON_APPDATA программы.

    Конечно, когда настройки сохранены и файл настроек, созданный на диске, вы хотите ограничить доступ для записи в файле настроек пользователя пользователю, для которого настроены параметры, и для администраторов, чтобы другие ограниченные пользователь не может их изменить.

    Однако, возможно, до того, как пользователь сможет написать свои собственные настройки из программы, опытный, злонамеренный ограниченный пользователь создает файл настроек для этого конкретного пользователя без ведома пользователя. Если ограниченный пользователь создает файл, это означает, что у них есть файл ... и тогда этот пользователь (для которого настройки) больше не может изменять настройки, если администратор не изменит права доступа к файлу.

    Возможно, маловероятная ситуация, но меня это все еще беспокоит.
2) Вместо перемещение пути к файлу настройки к глобально доступному пути и изменению файла настроек пользователя непосредственно, есть мое приложение создать и сохранить файл «переопределить» в папке CLSID_COMMON_APPDATA в приложении, чтобы позволить администратору для переопределения настроек пользователя.

Когда мое приложение загружает для этого пользователя (кто есть настройки были «переопределены») он будет обнаружить этот файл и загрузить его вместо обычного файла настроек, который находится в CLSID_APPDATA ( Документы и Settings \ Имя пользователя).

Плюсы:

  • Разрешения легко иметь дело.

    По умолчанию для Документы и Settings \ Имя пользователя APPDATA папки, только администраторы и Пользователь могут получить доступ к файлам из. Таким образом, сама по себе защищает пользовательские персональные настройки пользователя от других ограниченных пользователей.

    Чтобы защитить настройки «переопределить», мое приложение может просто запретить доступ к записи в папку COMMON_APPDATA - где написан файл переопределения - всем, кроме администраторов, и это все. Эти переопределяющие настройки будут модифицироваться только администраторами.
Минусы:

  • Этот метод, очевидно, более окольным. Если пользователь изменяет свои собственные персональные настройки, администратор не увидит эти изменения - администратор может видеть только настройки, которые он переопределяет обычные настройки пользователя (что он может заставить пользователя использовать вместо этого).

    В некотором роде это может быть хорошо, но ... тот факт, что это круговое движение, меня немного отстраняет.

Мне интересно узнать, что вы, ребята, думаете об этом. Какой из моих лучших вариантов? Я лично склоняюсь больше к # 2, потому что, хотя это менее понятно, кажется, что он более безопасен и не является , так что круговое движение, где это будет путать для администратора.

Однако я также открыт для предложений. Есть ли лучший вариант, который, по вашему мнению, будет работать лучше?

EDIT 7/6/09: Я хотел бы отметить, что для варианта № 2, администратор может не только отменить все настройки пользователя с одним файлом переназначения, но и переопределить параметры отдельного пользователя с переопределения файла для конкретного этот пользователь (как и с параметром № 1, это имя файла, скорее всего, будет иметь имя SID пользователя, параметры которого переопределены). Не уверен, что это было полностью ясно в исходном посте.

ответ

1

Если на каждом компьютере не существует более одной учетной записи пользователя (то есть компьютер используется более чем одним человеком), выбор второй - лучший выбор.

Даже если на каждом компьютере имеется несколько учетных записей пользователей, я думаю, что вариант второй по-прежнему является лучшим выбором. В худшем случае администратор должен будет изменить настройки на нескольких учетных записях на одном компьютере, а не на одном.

Если ваш объект позволяет случайным образом использовать любой компьютер для любого человека, тогда вариант один является лучшим выбором, поскольку второй вариант будет слишком сложным для поддержания того, что многие разные учетные записи на каждом компьютере.

Конечно, вы всегда можете установить параметры приложения в пользовательские папки на сервере. Это сделает его очень удобным для администратора.

+0

Объект позволит случайное использование любого компьютера любым человеком. Вы поднимаете хороший момент ... папка «Все пользователи APPDATA» не перемещается вместе с пользователем и специфична для компьютера, поэтому в некоторых случаях это может быть больно. Тем не менее, я действительно пытаюсь разработать свою программу для работы с Active Directory и службами терминалов ... могу ли я смело предположить, что и AD, и TS сделают это не проблемой? Я думаю, что у организации с сотнями, а может быть, с тысячами компьютеров, будет единственный сингл All Users APPDATA? – ZZZzzz

+0

Службы терминалов работают только на серверных машинах. Active Directory, AFAIK, не заботится о папках приложений на отдельных рабочих станциях. ИМО лучше всего сделать роуминг профилей. Хранение их на рабочих станциях - это кошмар для обслуживания. –

+0

Argh, мой cookie очистился, прежде чем я смог ответить. Вот мое мышление: Active Directory упрощает установку программного обеспечения один раз и позволяет ли он доступным для всего количества компьютеров, находящихся в сети, правильно? Если это так, разве это не так просто для администратора, если это еще не все, у всех есть одна и та же папка «Все пользователи»? И если они не хотят этого делать, то разрешите им настроить мою программу на использование альтернативной доступной для всего мира, но доступной только для администратора папки? – ZZZzzz

0

Если администратор уже имеет права на каталог пользователя, где хранится его файл настроек, разве это не решит вашу проблему? В любом случае, похоже, что вариант 2 лучше, тогда у вас может быть один файл, который может переопределить группу пользователей, тогда у каждого пользователя есть свои собственные настройки.До тех пор, пока ваше приложение достаточно умное, чтобы сказать, когда переопределить параметр, а когда не слишком, вариант 2 не должен быть такой проблемой.

+0

К сожалению, похоже, что нет простого документированного способа получить локальный путь appdata для конкретного пользователя ... в противном случае вы правы, это было бы намного проще. Похоже, что RegLoadKey() может технически работать - тогда я могу получить ключ Folders оболочки/пользовательских папок, но я не уверен, как он будет функционировать в среде сетевых служб/служб AD/терминалов. SHGetFolderPath() принимает дескриптор доступа к токену, но для этого требуется, чтобы все пользователи - даже администраторы - вводили пароль пользователя, и все равно требуется, чтобы кэш реестра пользователя был установлен. – ZZZzzz

 Смежные вопросы

  • Нет связанных вопросов^_^