Учетная запись администратора: Где, когда и как?
Где, когда и как создать учетную запись/пользователя администратора для частного веб-сайта?
Таким образом, то, что я спрашиваю, - то, что является предпочтительной техникой для создания той первой учетной записи/пользователя администратора. В моем случае это для частного webapplication. Я говорю об учетной записи/пользователе, которая будет владеть приложением и в случае необходимости создаст/продвинет других администраторов. Я предполагаю, что Вы можете этот парень пользователь root?
Вот несколько способов, которыми я встретился в другом websites/webapplication.
Мастер установки:
Вы видите это много в программном обеспечении блога или форумах. Когда Вы установите приложение, оно попросит, чтобы Вы создали пользователя администратора. Частный webapplication не будет, скорее всего, иметь этого.
Файл установки:
Файл Вы работаете для устанавливания приложения. Этот файл создаст администратора, составляют Вас.
Конфигурационные файлы:
Конфигурационный файл, который содержит учетные данные для учетной записи администратора.
Вручную вставьте его в базу данных:
Вручную вставьте информацию об администраторе в базу данных.
4 ответа
Когда:
На этапе начальной загрузки. Кто-то предложил seed.rb. Лично я предпочитаю использовать гем bootstrapper (с некоторыми дополнениями, которые позволяют мне анализировать файлы csv).
Это действие позволяет вам создать задачу rake, которая может быть вызвана следующим образом:
rake db:bootstrap
Это создаст начального пользователя-администратора, а также любые данные для раздачи (например, список стран или формат блога по умолчанию, так далее). Скрипт очень гибкий. Вы можете заставить его запрашивать пароль или принять параметр пароля, если хотите.
Как:
Во всех случаях я использую declarative_authorization для управления разрешениями пользователей.
Ваш пользователь-администратор должен вернуть роль под названием «admin» (или любое другое имя, которое вы выберете) в списке связанных с ней ролей. У меня обычно есть одна роль на пользователя, в основном потому, что я могу использовать наследование ролей (например, администраторы также являются редакторами по умолчанию). Это означает, что в моей базе данных есть одно поле для пользователей с именем «role_id». 0 обычно используется для роли администратора, так как он создается первым.
Где:
Конкретный файл внутри db / bootstrap / users.rb (или yaml, или csv) указывает сведения о пользователе с активированной ролью администратора. Порядок rake db: boostrap анализирует этот файл и соответственно создает пользователя.
Я вижу, вы пометили здесь рубин на рельсах. В RoR вы, вероятно, использовали бы файл seed.rb в / your_app / db.
Если вы используете asp.net, я могу предположить, что вы используете MSSQL или, возможно, Oracle. Сохраненная процедура, которая запускается как сценарий установки, может сделать эту работу.
Я видел приложения php, использующие файл install.php, который при запуске один раз устанавливает необходимые данные в базу данных, а затем сообщает установщику удалить файл перед запуском приложения.
Итак, есть три способа справиться с этим.
Мастер установки: - определенно лучший подход. Чисто, надежно и удобно. Должен быть интегрирован с установщиком приложений.
Установочный файл: - нормально, но только если у вас есть один-единственный скрипт для запуска. Есть еще -> проблемы и потенциальные недостатки безопасности (все, кто забыл удалить этот файл после ...)
Файлы конфигурации: Избегать. Вы требуете, чтобы пользователь знал PHP, внутреннее устройство вашего приложения, возможно, конфигурацию на стороне сервера (все, что выше ftp, может быть "сложным")
Вручную вставьте это в базу данных: Чтобы избежать * 2.
Кроме того, два последних решения невозможны, если вы используете хеширование паролей (например, md5 или sha1 с солью для конкретного сайта), что сегодня является серьезной обязанностью.
Если на вашем сайте есть учетные записи пользователей (а я вижу, что они у вас есть), конфигурационный файл с учетными данными администратора очень неудобен. Это решение заставляет вас дублировать большую часть логики аутентификации. Лучше держать учетную запись в базе данных.
Я понимаю, что вы готовите приложение для себя, а не поставляете его клиентам. Подготовка мастера установки или установочных файлов кажется пустой тратой времени.
Я бы сделал самое простое - просто сырую вставку. Плюсы: никакой лишней работы, тот же механизм аутентификации, что и для других пользователей. Если вы используете какие-то миграции баз данных, вы можете создать миграцию, которая создаст учетную запись root с каким-то фиктивным паролем, который вы сможете изменить позже.