Поэтапная разработка сайта на Laravel 4: урок №5 (часть 2)

Всем доброго времени суток 🙂

Рад представить вашему вниманию продолжение пятого урока. В нем мы реализуем функционал регистрации и авторизации пользователей, рассмотрев имеющиеся в Laravel средства для этого. Но сперва предлагаю посмотреть вступительное видео, в котором будет виден конечный результат этого урока:

Итак, приступим.

Для начала нам необходимо создать таблицу в базе, которая будет содержать пользователей сайта. Для этого создадим миграцию  create_users_table :

У пользователя будут для начала следующие поля:

  • id  — идентификатор пользователя
  • email  — E-Mail пользователя (уникальный)
  • password — хэшированный пароль
  • username — никнейм
  • isAdmin — является ли этот пользователь администратором сайта
  • isActive — активирован ли этот пользователь (подтвердил ли он свой E-Mail)
  • activationCode — код активации (подтверждения) E-Mail
  • created_at ,  updated_at — времена создания и обновления записи в базе

Сама миграция (метод up ) для этой таблицы будет выглядеть следующим образом:

Строку 26 стоит рассмотреть отдельно. В Laravel во время авторизации имеется возможность «запомнить» пользователя, чтобы при последующих открытиях страниц сайта ему не приходилось заново вводить свои данные (логин/email и пароль). Для этого пользователю передается специальный cookie, содержащий этот самый токен. Этот токен — просто случайная строка длиной 100 символов, привязанная к пользователю, однозначно идентифицируя его. Токен появился в Laravel совсем недавно, начиная с версии 4.1.26. Раньше в cookie передавался просто зашифрованный id пользователя, что считалось уязвимостью, так как в случае, если этот cookie попадал к злоумышленнику, тот получал полный контроль над учетной записью, причем жертву в этом случае уже ничего не могло спасти, даже смена пароля. С введением случайного токена проблема стала менее критичной: даже если cookie попадет к злоумышленнику, пользователь сможет сменить свой пароль, в результате чего будет сгенерирован новый случайный токен, таким образом старый cookie будет недействительным.

Примечание: 26ю строку можно заменить на:

С таблицей закончили. Теперь можно приступать к модели пользователя.

С каждой инсталляцией Laravel идет базовый класс User  для пользователя, реализующий некоторые интерфейсы, а именно UserInterface  и  RemindableInterface . Первый необходим для взаимодействия с компонентом Auth , который используется для авторизации пользователей, и содержит два метода:  getAuthIdentifier  (получить идентификатор пользователя) и  getAuthPassword  (получить пароль пользователя). Помимо этих двух методов стандартный класс User  имеет также методы, необходимые для упомянутой выше авторизации с запоминанием, а именно:  getRememberToken ,  setRememberToken  и  getRememberTokenName . Начиная с версии 4.2, эти и два предыдущих метода (от интерфейса UserInterface ) вынесены в трейт Illuminate\Auth\UserTrait .

Интерфейс  RemindableInterface  нужен для реализации имеющегося в Laravel механизма восстановления забытого пароля. Он содержит единственный метод  getReminderEmail , возвращающий E-Mail пользователя. Как и в предыдущем случае, начиная с версии 4.2 этот метод вынесен в отдельный трейт:  Illuminate\Auth\Reminders\RemindableTrait .

Так как у нас поля пользователя именуются стандартно ( email  для почты, password  для пароля, и remember_token  для токена), то нам подойдет имеющийся изначально вариант модели User . Но Laravel не ограничивает нас в плане именования полей: мы вполне могли бы называть все поля, как нам захочется, будь то userEmail , user_email и т.п., но просто в этом случае пришлось бы проделать немного больше работы.

Итого, в зависимости от того, начиная с какой версии вы создали проект, модель пользователя по умолчанию внутренне может отличаться: все вышеперечисленные методы либо вынесены в трейты, либо реализованы непосредственно в самом классе User . Нам пока потребуется лишь одно маленькое изменение, а именно — добавить поле $fillable , чтобы мы могли заполнять модель данными при регистрации:

Теперь можно приступать к регистрации пользователей.

Для начала создадим контроллер UsersController , который будет отвечать за все операции с пользователями,  и пропишем маршруты к нему в файле app/routes.php :

Первое, что нам нужно, это отобразить форму с регистрацией. Для этого создадим метод getRegister  в контроллере с таким содержимым:

Этот метод просто вернет шаблон users/register  при GET-запросе на /users/register . Давайте создадим сам шаблон. Создадим папку users  внутри app/views , и в ней файл register.blade.php :

Здесь, как и в случае добавлении планет (строки 10-16), предусмотрен вывод ошибок при регистрации (в будущем я посвящу отдельный урок, в котором мы займемся рефакторингом и сделаем некоторые вещи грамотнее, а пока пускай будет так 🙂 ). В остальном все тоже самое. Стоит обратить внимание разве что только на строчку 41: поле для подтверждения пароля мы именуем так же, как и сам пароль, только добавляя ему окончание _confirmation . Это нужно для правила валидации confirmed , которое мы применим к введенному паролю, хотя опять же, Laravel нас не ограничивает в именовании, и мы могли бы назвать его как хотим, просто при определении правила это произвольное имя в этом случае нужно будет дополнительно указать.

Небольшое отступление: если вы используете в точности такие же шаблоны, как и я, то нужно немного подправить стили (добавить отступы для тэга body). Создайте файл public/css/style.css  с таким содержимым:

И добавте этот CSS-файл в главный макет сайта app/views/layout.blade.php :

Можно открыть эту страницу теперь и проверить, как она выглядит: http://sbshare.localhost:8000/users/register.

Пора приступать к непосредственно регистрации пользователей. За это будут отвечать метод postRegister  контроллера пользователей и сама модель User .

Сперва опишем правила валидации при регистрации. Как и в случае планет, эти правила уместно прописать в модели:

Переходим к «входной точке» регистрации — методу  postRegister  контроллера:

За исключением строк 13 и 16 все должно быть знакомо.

В 13й строке мы вызываем метод  register  модели, который выполнит всю непосредственную логику регистрации пользователя, используя данные, установленные в 12й строке стандартным методом Eloquent fill .

В 16й строке мы вызываем наш собственный метод getMessage базового контроллера (который мы позже напишем), который просто отображает переданное сообщение на странице. Он может нам пригодится и в других случаях; смысл его в том, чтобы не создавать для каждого отдельного подобного сообщения отдельный шаблон.

Переходим к методу register  модели. Его задача состоит в следующем:

  1. Сформировать хэш пароля при помощи стандартных средств Laravel
  2. Сгенерировать код активации для этого пользователя
  3. Записать пользователя в базу со значением false (0) поля isActive.
  4. Отправить пользователю письмо со ссылкой для активации

Выглядит он так:

В строке 3 мы генерируем случайный код активации, а в строке 9 отправляем письмо.

Генерация кода довольно проста: можно воспользоваться имеющейся в Laravel функцией для генерации случайной строки, хотя можно было бы и проявить фантазию и написать свою логику (я частенько в этом случае делал хэш от случайного числа, текущего времени и «соли» приложения):

Переходим к отправке письма. Этот метод может выглядеть так:

В этом методе сперва формируется ссылка для активации (строка 3). Но для этого нужно, чтобы в контроллере уже был метод getActivate , который будет осуществлять активацию пользователя (пока там можно поставить заглушку).

Строка 10 нужна для совместимости со старыми версиями PHP (до 5.4). Хоть я предполагаю, что вы используете уже Laravel 4.2 (который требует PHP не ниже 5.4), в «боевых» условиях это не всегда будет так, так как на большинстве шаред-хостингах до сих пор стоит PHP 5.3, и использовать Laravel 4.2 не получится.

Теперь нужно написать шаблон для письма, в котором просто в нужном месте вставить активационную ссылку {{ $activationUrl }} . Предлагаю вам пофантазировать и написать его самостоятельно.

Регистрация почти завершена. Осталось написать метод getMessage  базового контроллера ( BaseController ), о котором говорилось выше:

И шаблон для него ( app/view/message.blade.php ):

Проверьте, все ли работает правильно: зарегистрируйтесь и посмотрите на содержимое письма в логе.

Приступаем к активации. Как и в случае с регистрацией, за активацию будут отвечать два метода: getActivate  в контроллере и activate  в модели.

Здесь мы встречаем новый для нас компонент Laravel — Auth . Как ясно из его названия (от authorization) — он служит для авторизации пользователей и содержит различные методы для этого. В данном случае используется его метод login , который просто авторизовывает переданного в аргументе пользователя без каких-либо проверок. У этого метода также есть второй параметр: если в него передать true , то пользователь будет «запомнен», о чем я писал выше. С остальными необходимыми нам методами этого компонента мы познакомимся позже.

Здесь также вызывается метод activate  выбранного пользователя. Этот метод делает основную работу по активации: проверяет код и обновляет запись в базе в случае совпадения.

На этом регистрация полностью завершена.

Теперь нужно реализовать возможность авторизовываться на сайте, а также механизм восстановления забытого пароля. Начнем с авторизации.

Сперва нам нужна форма, где пользователь сможет ввести свои данные. Ее можно сделать как в панели навигации, так и на отдельной странице. Предлагаю пойти по второму пути.

Добавьте метод getLogin  в контроллер пользователей:

И сам шаблон с формой для авторизации в app/views/users/login.blade.php :

Это страница взята из примеров с сайта getbootstrap.com: http://getbootstrap.com/examples/signin/. Для нее понадобится дополнительный файл signin.css  со стилями. Скачать его можно по этой ссылке.

В строках 13-17 используется не описанный еще мною функционал сессий, хоть отчасти (неявно) мы его уже и использовали, когда выводили сообщения об ошибках валидации и подставляли предыдущий ввод пользователя при редиректах. Компонент Session , как ясно из названия, используется для работы с сессиями. Он заменяет стандартный механизм сессий в PHP и поддерживает различные драйверы для этого. То есть в Laravel вам не нужно устанавливать/читать явно сессионные данные через глобальную переменную $_SESSION . Вместо этого используются инструкции вида Session::put('name', $value);  и Session::get('name');  например. Но помимо стандартного функционала сессий, этот компонент имеет также очень полезную возможность складывать в сессию временные данные, которые будут существовать лишь при следующем запросе любой страницы сайты и будут недоступны при последующих. Это так называемые flash-данные. Использовавшийся нами ранее механизм вывода ошибок , к примеру, как раз реализуется за счет таких данных.

В данном случае проверяется, имеется ли в сессионных данных переменная alert , и если да, то выводится ее содержимое в соответствующем элементе страницы. В эту переменную мы будем записывать ошибку авторизации («Неверная комбинация имени (email) и пароля«).

Приступаем к непосредственно авторизации.

Для авторизации, как уже говорилось, используется фасад Auth . В данном случаем нам понадобится его метод attempt , который возьмет на себя проверку введенных пользователем данных. В первом аргументе этому методу передаются авторизационные данные: пароль и любые другие данные, необходимые для авторизации. На сайте sbshare.ru поддерживается авторизация как по имени пользователя, так и по его адресу, поэтому нам необходимо будет добавить дополнительную проверку при формировании данных, передаваемых в метод attempt . Вот как выглядит код метода postLogin :

В строках 12-17 мы определяем, что именно ввел пользователь в поле username : email или непосредственно свое имя, указанное при регистрации, и в зависимости от этого формируем данные для авторизации.

В 20й строке мы непосредственно пытаемся авторизовать пользователя. В случае успеха, пользователь, полученный по указанным данным, будет авторизован на сайте, и этот метод вернет true .

Примечание: для кого-то, особенно для начинающих web-разработчиков, является неожиданностью тот факт, что если галочка (checkbox) в форме не отмечена, то это поле вообще не придет от браузера. Поэтому мы передаем во втором параметре не Input::get('remember') , а Input::has('remember') , который будет true , если галка была отмечена. Есть разные точки зрения на этот счет — кто-то считает это багом или недоработкой HTTP, но лично я нахожу такую особенность очень удобной, особенно когда приходится обрабатывать списки checkbox’ов.

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

И наконец, в случае неудачи, мы перенаправляем пользователя обратно на страницу авторизации, попутно установив временное сообщение в сессии. withAlert  — это «магический» метод, аналогичный использовавшимся нами ранее методами withErrors  и withInput . Суть в том, что когда вызывается подобный метод, начинающийся с with , Laravel преобразует оставшуюся часть имени метода в название переменной, и временно запоминает ее посредством вызова  Session::flash('alert', $value); Вместо этой магии можно явно указывать имя переменной:

Чтобы дать пользователю возможность выйти с сайта, напишем простой метод getLogout  в контроллере пользователей:

Авторизация на этом почти завершена: остается добавить соответствующие ссылки для входа и выхода с сайта в макет.

Добавьте следующий код в файл layout.blade.php  в навигацию после закрывающего тэга </ul> :

В первой строке мы проверяем, авторизован ли пользователь ( Auth::check ). А в 11ой строке, посредством метода Auth::user , мы получаем текущего авторизованного пользователя и выводим его имя.

Авторизация теперь тоже готова.

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

Сперва нужно создать таблицу с кодами для восстановления паролей. Делается это путем выполнения следующих команд:

Первая создаст миграцию, вторая эту миграцию выполнит.

Следующий шаг — создание контроллера, который будет обрабатывать смену пароля. Делается это аналогично, при помощи артизана:

После чего нужно прописать маршруты к нему в файле app/routes.php :

Следующий шаг — создание шаблона для формы восстановления пароля. Если не трогать контроллер, то будет использоваться шаблон app/views/password/remind.blade.php . Суть этого шаблона в следующем:

  1. Он должен содержать форму с единственным полем email , отправляемую методом POST на RemindersController@postRemind .
  2. В случае успеха, вышеупомянутым методом будет установлено соответствующее сообщение в сессию по ключу status — шаблон должен уметь его вывести.
  3. В случае ошибки (пользователь не найден) — аналогично предыдущему пункту, только будет установлено сообщение об ошибке по ключу error.

Вот как этот шаблон выглядит у меня:

При правильном E-Mail на него будет отправлен шаблон app/views/emails/auth/reminder.blade.php , который нам желательно перевести на русский.

Еще желательно подправить саму отправку, так как по умолчанию у отправляемого письма не будет темы. Делается это следующим образом: в методе postRemind  нужно добавить второй параметр в вызове  Password::remind  — такой же, как и в случае отправки писем через фасад Mail , то есть замыкание:

Теперь нужно написать шаблон для формы сброса пароля. По умолчанию будет использоваться шаблон password/reset.blade.php . Форма на этой странице должна иметь следующие элементы:

  1. Скрытое поле token , содержащее переданный в этот шаблон токен ( {{ $token }} ).
  2. Поле email.
  3. Поля password  и password_confirmation .
  4. В случае ошибок, шаблон должен уметь вывести сообщение об этом, хранящееся в сессионной переменной error.

Форма должна отсылать данные методом POST на RemindersController@postReset .

Шаблон может быть таким:

В случае успешной смены пароля пользователь будет просто перенаправлен на главную страницу сайта.

На этом функционал восстановления пароля тоже готов.

Предлагаю завершить урок, доделав нашу модель планет, а именно — связать эту модель с пользователями и выводить автора планеты на страницах.

Если помните, в таблице планет уже имеется поле user_id , которое должно ссылаться на пользователя, добавившего эту планету. Для начала стоит подправить код добавления планеты, чтобы в это поле записывался id  текущего пользователя. Для этого нужно добавить следующий код перед вызовом Planet::create($data) в методе postAdd  контроллера планет:

Благодаря Eloquent, мы теперь можем с легкостью получать автора планеты без необходимости выполнять дополнительные запросы вручную для получения связанного пользователя по полю user_id . Для этого нужно прописать эту связь в модели планеты:

Эта запись «устанавливает» связь типа «много к одному» между моделями планеты и пользователя ( belongsTo  дословно переводится как «принадлежит к», то есть планета принадлежит какому-то пользователю). В данном случае в первом параметре мы указываем модель, к которой принадлежит модель планеты, а вторым необязательным параметром указываем поле в текущей модели, которе ссылается на пользователя.

Теперь для каждой планеты мы можем просто получить ее автора путем вызова $author = $planet->author;  — все остальное за нас сделает Eloquent.

Но тут стоит немного сказать об оптимизации и так называемой «жадной» (или «нетерпеливой») загрузке данных. Дело в том, что если вы просто каким-то образом получите модель планеты и попытаетесь получить ее автора, то Eloquent выполнит еще один дополнительный запрос в базу для извлечения пользователя, на которого эта планета ссылается. Этот подход называется «ленивой» загрузкой данных, и в этом нет ничего страшного, если вы работаете с одной планетой. Но как быть, если вы получаете целый список планет в коде, и для каждого нужно получить автора? При ленивой загрузке Eloquent будет делать по одному дополнительному запросу для каждой планеты. Соответственно, если вы получаете из базы список из ста планет, и для каждой впоследствии получаете автора, то суммарно у вас будет аж 101 запрос к базе данных (первый запрос — сама выборка ста планет, и потом еще 100 запросов для автора каждой планеты). Разумеется, такой подход не очень хорош.

Тут на помощь приходит «нетерпеливая» загрузка, когда вы извлекаете список планет сразу с авторами. В этом случае в базу будет совершено всего два запроса: первый — список самих планет, второй — список всех авторов для выбранных планет. В этом случае Eloquent обойдет список полученных авторов и подставит в каждую модель планеты соответствующего автора. Выполнить такую загрузку связанных моделей можно посредством метода with . Например, выборка последних планет в нашем методе getIndex  контроллера IndexController  будет теперь выглядеть так:

Теперь для каждой планеты в этой коллекции в поле author  уже будет установлен соответствующий пользователь, если он конечно имеется (ведь до этого урока у нас планеты добавлялись без автора, в этом случае author  будет хранить null ).

Имея все вышесказанное ввиду, мы теперь можем отображать авторов планет на страницах. Но нужно учитывать, что планета может быть добавлена незарегистрированным пользователем, в таком случае нужно это проверять и выводить, например, «Аноним» в качестве автора.

Вот как может теперь выглядеть соответствующая часть шаблона planets/planet_preview.blade.php :

На этом пятый урок закончен. Если кто не читал мою предыдущую заметку о первой части урока, повторю тут. Я завел репозиторий на GitHub с кодом этих уроков. Для каждого урока заведена соответствующая ветка. То есть, к примеру, результат этого урока можно увидеть в ветке lesson-5. Таким образом вы можете либо сразу скачать мое готовое исполнение, либо просто сравнить его со своей реализацией.

Ну и как обычно, пишите комментарии 🙂 Всем удачи 🙂

Поделиться в соц. сетях

45 thoughts on “Поэтапная разработка сайта на Laravel 4: урок №5 (часть 2)

  1. feex:

    Хорошая статья , только думаю вот тут {{ activationUrl }} будет ошибка … возможно я не прав, но я думаю там должно быть так {{ $activationUrl }}

    1. Спасибо, действительно должно быть {{ $activationUrl }}, исправил 🙂
      Просто по работе приходится работать с Twig’ом, вот и машинально написал так 🙂

  2. Tkas:

    У меня появляется ошибка после того, как я хочу зарегистрироваться
    Swift_TransportException
    Cannot send message without a sender address
    Но в базе данных адрес сохраняется.

      1. Tkas:

        Пока что просто поменял драйвер на mail и письма в mailoutput стали приходить. Посмотрим как это повлияет после выкладки на хостинг.

      2. Tkas:

        А можете поподробнее рассказать какой именно это адрес? С драйвером mail на хостинге письмо не отправилось.

          1. Tkas:

            Да, у меня такие же настройки. Я думал их заполнить чем-то надо) Но письма не отправляются =(

        1. Ну понятное дело, что заполнить надо, в этом то и ошибка.

          'from' => array('address' => 'noreply@domain.com', 'name' => 'MySite'),

          P.S. Странно, не могу ответить на последний комментарий, поэтому отвечаю на этот 🙂

    1. Токен перегенерируется при сбросе пароля. Это для того случая, когда вдруг твой куки с токеном попал к злоумышленнику. В этом случае старый куки будет недействителен.

      1. Tkas:

        Кстати, наш же токен называется remember_token, а не token. Откуда он передался в представление?

        1. Значит мы о разных токенах говорим. remember_token — это токен авторизации. А при восстановлении пароля используется другой токен, который служит для того, чтобы только пользователь, запросивший смену пароля, смог его сменить. То есть чтобы не каждый желающий мог перейти на страницу восстановления пароля и изменить пароль любому другому пользователю.

          1. Tkas:

            Но как используя именно этот token система узнает, что именно мы хотим поменять пароль, а не какой-то другой человек? Этот token берется из кук?

            1. Этот токен берется из ссылки, присылаемой в письме. Сама связка token -> email хранится в таблице password_reminders.

    1. Скорее второе. Только и отдыхом это не назвать: сейчас у меня завал на работе примерно до серидины сентября. Заниматься своими сайтами и Ларавелом не остается ни времени, ни сил.

  3. Anton:

    Вы очень хорошо и понятно излогаете материал, обращая внимания на тонкости. Я никогда не использовал ORM, потому что как раз считал его не совершенным при сложной выборке, а тут вы привели пример когда использование ORM удобно.
    Желаю вам дальше продожать создавать учебные материалы по Lavarel, свой выбор в пользу изучения этого каркаса я уже сделал, спасибо!

  4. Артем:

    День добрый! А мне при попытке залогиниться вот это показывает:

    Argument 1 passed to Illuminate\Auth\EloquentUserProvider::validateCredentials() must be an instance of Illuminate\Auth\UserInterface, instance of User given, called in /home/artmik/htdocs/Dropbox/lvtest/vendor/laravel/framework/src/Illuminate/Auth/Guard.php on line 371 and defined

    Что можно сделать?

  5. Виталий:

    php artisan auth:reminders-controller

    Возвращает php artisan auth:reminders-controller
    Laravel Framework version 4.0.11

    В чем может быть проблема?

  6. Сергей:

    Здравствуйте!
    А продолжения не будет? Хотел бы посмотреть на ту же форум добавления планеты только с ajax и распределения ролей, например, гости не могут добавлять.

    1. Продолжение по идее будет, но вопрос во времени. К тому же я сейчас жду 5ю версию фреймворка, чтобы посмотреть и решить, как продолжать уроки: доделать все на 4й версии, а потом мигрировать на 5ю, или же сразу начать мигрировать на 5ю. Так же немаловажным фактором является вдохновение … Поначалу то я писал уроки, поскольку оно было. А теперь я занимаюсь немного другими, не связанными с Laravel, делами, и поймать вдохновение стало сложнее 🙁 Но закончить уроки я все же хочу.

  7. Дмитрий:

    Спасибо за хороший материал. Наконец-то я нашёл то что мне нужно. Много фреймворков пробовал (Zend, Codeigniter, Yii, Kohana). Laravel понравился больше всех. Появилось желание разобраться до мелочей.
    В Вашем коде или скорее в документации есть одна неточность. При валидации параметр (alpha_num) ‘username’ => ‘required|alpha_num|unique:users’, не проверяет только на латинские символы и цифры, пропускает и кириллицу, что может печально сказаться. Нужна скорее регулярка. А так всё супер. Считаю Laravel на данный момент лучшим решением для веб разработки. Быстрый порог вхождения и что-то новенькое)

    1. Спасибо за комментарий. Вообще строго говоря под термином alpha подразумеваются и русские буквы тоже, если в регулярке используется модификатор u (юникод). Конкретно для правила alpha_num скорее всего используется класс [:alnum:] в регулярке, поэтому он пропускает и кириллицу. Но в слюбом случае спасибо, что заметили, я как-то не придавал этому значения.

  8. strannik:

    неужели в 2014 году, эта операция, которая реализовывалась миллион раз должна занимать столько времени… Почему нельзя сгенерить какой нибудь скелет-скаффолд и допилить его как надо

    1. Напомню, что это — урок по Laravel, в котором как раз объясняется, как сделать авторизацию в Laravel. Желающие могут исходить из него и делать все как им удобнее, включая собственный «скелет-скаффолд». Это нельзя было бы назвать уроком, если бы я сказал — скачайте исходники авторизации и смотрите сами. У меня на реализацию этого механизма уходит минут 10 с нуля например, не считая подгон дизайна страницы регистрации, Laravel берет много на себя.

  9. DarkSide:

    Доброе утро! Ваш сайт (тот что с координатами) как-то очень долго загружается. Интересно услышать ваше мнение о причинах лагов, т.е. база данных, или сам фреймворк, или еще чето?

    1. У меня он загружается крайне быстро, я бы даже сказал мгновенно. Возможно либо у вас, либо все-таки на хостинге какие-то временные затруднения были.

  10. Igor:

    Александр, здравствуйте! Спасибо за замечательные уроки — они меня очень здорово выручили. По ним сейчас делаю свой проектик (использую версию laravel 4.2).

    Сейчас столкнулся с одной задачей — не знаю как «отфильтровать» одним махом все маршруты генерируемые роутом типа этого: Route::controller(‘dashboard’, ‘DashboardController’); Моя задача — пускать в админ-панель по адресу только авторизовавшегося пользователя. Вообще, все URI, начинающиеся с , я хочу разрешить обрабатывать только для админа — т . е. только для авторизованного пользователя.

    Подскажите, пожалуйста, если можете, как это делается?

      1. Igor:

        Я почему-то решил, что это нужно делать в route.php и на части документации, на которую вы указали, не заострил внимания. Большое спасибо за подсказку — теперь все получилось 🙂

  11. Igor:

    Александр, здравствуйте! Пытаюсь реализовать в своем мини-проекте что-то вроде подписки на рассылку новостей для подписавшихся. Для этого вывожу на сайте форму, где пользователям нужно ввести лишь их E-Mail и нажать кнопку подписаться. Далее на почту пользователя приходит ссылка на активацию — всё прямо как из вашего урока с регистрацией пользователей (только без пароля и логина). Но вот беда — в случае, если пользователь вводит в форме для подписки своей email повторно, то ошибка о том, что такой email уже существует — не выводится.

    Первая мысль, которая у меня появилась по поводу решения этой задачи — написать немного кода в контроллере (сразу после валидации email), который искал бы в БД введенный пользователем email и если бы его находил, то возвращал пользователю соответствующее сообщение.

    Но может быть в laravel уже есть что-то встроенное по аналогии с регистрацией пользователей? Подскажите, пожалуйста, как бы лучше решить подобную задачу?

      1. Igor:

        В правиле валидации, ключевое слово unique я прописал. Но, кажется, я не уточнил одну деталь — у меня для подписчиков существует отдельная модель Subsriber.php, которая начинается так: class Subscriber extends Eloquent {……. Т. е. это отдельный класс, который не имеет отношения к классу User. В этом классе валидация описана так:


        public static $validation = array(
        'email' => 'required|email|unique:subscribers',
        );

        В остальном, логика регистрации и активации такая же как в вашем уроке.
        Это как-то меняет ситуацию?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.