Смотрите следующий сценарий.
У меня есть некоторый пользовательский модуль, который позволяет внешнему пользователю выполнять некоторые действия с некоторыми пользовательскими объектами. (детали не очень важны).
Запрос заключается в том, что администратор должен иметь возможность войти в систему с учетной записью клиента (без пароля) и иметь возможность выполнять эти действия для клиента.
Поскольку вы не можете использовать сеанс внешнего интерфейса из внутреннего интерфейса, и я не хочу создавать постоянную ссылку автологина для внешнего интерфейса, поскольку это может быть большой дырой в безопасности, это то, что я делал до сих пор.
- добавить пустой атрибут для объекта клиента. (давайте назовем это
login_key
) - добавьте кнопку в бэкэнд на странице редактирования клиента, которая перенаправляет на страницу администратора, где случайная строка генерируется и сохраняется в атрибуте
login_key
. - в том же действии я перенаправляю администратора на URL внешнего интерфейса, как это
autologin/index/index/customer_id/7/login_key/ajkshdkjah123123
(значение, созданное на предыдущем шаге). - по внешнему URL-адресу, если идентификатор клиента
login_key
совпадает с конкретным клиентом, тогда я устанавливаю объект клиента в сеансе (после входа в систему) и удаляю,login_key
чтобы URL-адрес не работал в будущем.
Это швы на работу. Я имею в виду, я вошел в систему как выбранный клиент, и ссылка, используемая для автологина, не работает во второй раз.
Недостатком является то, что если два администратора одновременно нажмут кнопку «autologin», один из них не сможет войти в систему, но это приемлемый риск.
Моя главная проблема заключается в том, что это также может быть (не так) большой проблемой безопасности. Может ли кто-то увидеть что-то не так с этим подходом? или предложить лучший?
Игнорируйте тот факт, что учетные записи клиентов могут быть разделены по веб-сайту. Это не важно, а также легко управляется.
Ответы:
Поскольку ни у кого не было веской причины не делать то, что я просил, я предполагаю, что мой метод безопасен. Поэтому, чтобы не оставлять этот вопрос открытым, я решил добавить код в качестве ответа и отметить его как принятый.
Итак, у меня есть новое расширение, которое называется
Easylife_Simulate
следующими файлами:app/etc/modules/Easylife_Simulte.xml
- файл декларации:app/code/local/Easylife/Simulte/etc/config.xml
- файл конфигурацииapp/code/local/Easylife/Simulate/sql/easylife_simulate_setup/install-0.0.1.php
- установить скрипт - добавляет новый атрибут клиента:app/code/local/Easylife/Simulate/Model/Observer.php
- наблюдатель, чтобы добавить кнопку в форме редактирования администратора клиентаapp/code/local/Easylife/Simulate/controllers/Adminhtml/SimulateController.php
- контроллер администратора, который обрабатывает нажатие на сгенерированную выше кнопку.app/code/local/Easylife/Simulate/controllers/IndexController.php
- контроллер внешнего интерфейса, который производит автологин.app/code/local/Easylife/Simulte/Helper/Data.php
- модуль помощникВот и все. Это похоже на работу для меня. Как я уже сказал в этом вопросе, недостатком является то, что если 2 администратора нажимают кнопку входа в систему для одного и того же клиента (приблизительно) в одно и то же время, один из них не будет авторизован. Но он может повторить процесс через несколько секунд.
источник
Мы используем аналогичный подход для нашей команды обслуживания клиентов, который называется «призрачный логин», где мы делаем кнопку доступной через учетную запись клиента в админке. Мы не используем никаких пользовательских атрибутов для login_key или чего-либо подобного и фактически используем переопределенную / настроенную функцию loginAction, расширенную от Mage_Customer_AccountController для обработки входа в систему.
Кроме того, во время loginAction, после нашей пользовательской логики и проверки, мы используем Mage_Customer_Model_Session :: setCustomerAsLoggedIn, чтобы гарантировать, что мы не теряем функциональность событий, которая может быть выполнена во время входа в систему. Если вы посмотрите на этот метод, вы заметите, что он устанавливает клиента в сеансе, а также отправляет событие customer_login.
При таком подходе мы можем фактически сделать так, чтобы несколько агентов входили в систему как один и тот же клиент, которого мы выбрали (хотя мы не хотели бы, чтобы несколько агентов добавляли в корзину / размещали заказы одновременно на одном и том же счете).
Мы использовали это в течение двух лет без каких-либо заметных проблем в течение этого времени.
источник
setCustomerAsLoggedIn
в своем коде, по той же причине, что и вы. Но мне было любопытно, какой метод использовать для аутологина. (если не секрет).