Подтвердить что ты не робот

Защита паролем группы шаблонов ExpressionEngine

Я создаю сайт, где у персонала будет свой раздел сайта: example.com/jones, example.com/smith и т.д. Джонс и кузнец - это группы шаблонов с одинаковыми шаблонами внутри (с использованием Stash и Low Переменные, чтобы сохранить все DRY). Некоторые пользователи будут иметь разные потребности в конфиденциальности. С одной стороны их раздел будет публичным. С другой стороны, некоторым пользователям необходимо будет управлять тем, кто может получить доступ к их контенту (используя друзей Solspace).

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

Мы хотели бы защитить паролем группу шаблонов. Сотрудники могут сообщить людям, где их страница, и сообщить пользователям, что такое пароль. Это все возможно на уровне сервера, но возможно ли разрешить пользователю напрямую управлять паролем? Что-нибудь, что мы можем сделать, чтобы свести к минимуму, сколько нам нужно, чтобы руки от этого были лучше. Пользовательское поле и добавление, которое допускает такую ​​защиту? Я ничего не видел в Devot-ee, и методы на форумах этого не делают. Немного длинный, но решил, что я спрошу.

4b9b3361

ОТВЕТЫ

Ответ 1

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

Недавно я сделал нечто похожее, которое защищало группу записей, используя настраиваемое поле. Это похоже на подход, описанный в этой статье Защищенный паролем контент, сделанный простой. Но вместо того, чтобы использовать PHP в шаблоне, я использовал переменные Mo '. И вместо использования url_title я использовал настраиваемое поле (например, client_password ниже).

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

{!-- PASSWORD REQUIRED --}
{if client_password != ""}

    {!-- if passed show content and set session --}
    {if post:password == client_password}

        {!-- protected content here --}
        {!-- set session --}
        {embed='embeds/_set_session' entry_id="{entry_id}"}

    {!-- if session is valid show content --}
    {if:elseif "{exp:session_variables:get name='logged_in'}" == "{entry_id}"}

        {!-- protected content here --}

    {!-- if failed show login --}   
    {if:elseif post:password != "" AND post:password != client_password}

        <div id="protected">
            <p>Incorrect password. Please try again.</p>
            <br>
            <form action="" method="post">
                <strong>Password</strong><br />
                <div>
                    <input name="password">
                </div>
                <input type="submit" class="submit" value="submit">
            </form>             
        </div>

    {!-- if first attempt show login and prompt --}
    {if:else}

        <div id="protected">
            <p>This page is password protected. Please provide the password.</p>
            <br>
            <form action="" method="post">
                <strong>Password</strong><br />
                <div>
                    <input name="password">
                </div>
                <input type="submit" class="submit" value="submit">
            </form>             
        </div>

    {/if}

{!-- NO PASSWORD REQUIRED --}
{if:else}

    {!-- protected content here --}

{/if}

Ответ 2

Я хотел обновить это с помощью кода, который я использую, чтобы htaccess и htpasswd работали, чтобы защитить группу шаблонов. Его можно использовать так же, как у Alex's, но это все или ничего. Он имеет свои преимущества и недостатки, но хотел поделиться им как вариант.

Во-первых, я использую поведение собственного шаблона: example.com/group/template/url_title. Я хочу защитить паролем некоторые группы шаблонов, но вне членов EE и групп участников. т.е. один пользователь и пароль.

Мой файл htaccess выглядит так (от http://perishablepress.com/enable-file-or-directory-access-to-your-htaccess-password-protected-site/):

# We set some variables, matching URL for which we do not wish to active
# the password protection
SetEnvIf Request_URI "^/privategroup.*$" private

# Setup the password protection
AuthName "Password Needed"
AuthGroupFile /dev/null
AuthType Basic
AuthUserFile /Users/user/Sites/example/.htpasswd
Require valid-user

# Add the exceptions for matched URL's
Order Deny,Allow
Deny from env=private
Satisfy any

Файл htpasswd должен быть выше webroot, но для тестирования я оставил его в webroot. Строка AuthUserFile сообщает Apache, где можно найти файл с именами пользователей и паролями. Это должно... ДОЛЖНО быть абсолютным путем. Я использовал родственников и получил 500 ошибок. Для создания этого файла вам необходимо использовать терминал или какой-либо другой инструмент. http://developer.apple.com/library/Mac/#documentation/Darwin/Reference/ManPages/man1/htpasswd.1.html

В результате для каталога требуется имя пользователя и пароль. Сейчас он примет любого действительного пользователя в моем файле htpasswd. Однако я могу изменить это, указав конкретного пользователя (требуется пользователь john tim lisa) или группы.

Там у вас есть. Держите людей вне определенных групп шаблонов без использования каких-либо встроенных функций EE.

Ответ 3

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

Я отправлю его так же, как он может помочь вам или кому-то еще по дороге:

http://koivi.com/ee-entry-auth-dir/

Ответ 4

Посмотрели ли вы на использование опции HTTP Authentication в разделе Ограничения доступа к шаблону? Он использует пароль участника для аутентификации, но не требует, чтобы элемент фактически был зарегистрирован.

Вы говорите, что "не хотите использовать члены/группы участников для управления этим", но затем вы хотите "позволить пользователю напрямую управлять паролем"... конечно, используя встроенную систему-член самый простой способ?