Виталий Жук

Здесь еще нужно очень хорошо разделять понятия авторизация и аутенфикация.

Аутенфикация - это определения пользователя, то есть, что это за пользователь. Обычно этот этап проходит сразу же после ввода логина пароля. Если логин верный, ты мы и сразу можем сказать: "Пользователь аутенфицырован". К примеру, если использовать HTTP Basic аутенфикацию, то в случае не верного логина/пароля будет ошибка 401.

Авторизация - это проверка прав пользователя к определенному ресурсу. К примеру, может ли пользователь редактировать какой-то материал (статью, коммент), может ли он просматривать какой-то ресурс.

Очень часто еще может "всплыть" понятие "Фаервол" - это механизм определения для поведения системы аутенфикации/авторизации. К примеру: В личном кабинете, необходимо чтобы пользователь был обязательно авторизован, но вот на сайте (доки, другие страницы), нет. В результате, мы можем создать два фаервола, определяющих это поведение для разных URL-ов.

Два этих механизма могут работать как угодно, так как Вы захотите, главное, это скажим соблюдать некие правила:
1. Ни в коем случае не аутенфицировать по UserID, иначе, любой сможет получить доступ. К примеру: Вы сохраняете в куки только UserID для аутенфикации, тогда, кто-то сможет подменить со своей стороны куку, и ввойти под другим пользователем.
2. Не храните в куках логин/пароль. Так как есть множество вирусов, которые могут прочитать куки и отправить на другой сервере.
3. Пароль в БД должен быть хеширован, и проверка должна быть именно по хешам, а не по реальным паролям. Иначе, если кто-то у Вас свиснит БД, то очень вероятно, что и сможет получить доступ к множествам другим аккам, так как множество людей используют один и тот же пароль.

Лично для своих проектов, я всегда использую Symfony Security, так как в этом пакете уже все сделано место Вас. Главное это верно подключить и настроить, и вауля :)

Один из хороших подходов — это создания собственного валидатора, который будет валидировать не свойство а, целлый класс. symfony.com/doc/current/cookbook/validation/custom_constraint.html Здесь плюс большой, что Вы его сможете потом при необходимости определить как сервис, и внедрить в него зависимости.

Также есть возможность обработать эту проверки на евенте FormEvents::SUBMIT (На >= 2.1 < 2.3 FormEvents::BIND), и если есть ошибка, то самому добавить ее addError(new FormError(/**… **/));

Лично я себе покупал Pro 13'', после чего сделал апгрейд (ОЗУ — 16 Гб, ССД — 120). Работает как часики.
Так что, мне кажется, лучше будет взять Про + айпад, а потом примерно за 130 — 200 дол сделать отличный апгрейд.

Создавайте простой сервис:

use Doctirne\ORM\EntityManager;

class SettingLoader
{
  protected $em;
  public function __construct(EntityManager $em)
  {
    $this->em = $em;
  }

  public function get($key)
  {
    $val = $this->em->getRepository('MailBundle:Setting')->findOneBy(array('key' => $key));
    if (!$val) { throw new \InvalidArgumentException('Setting not found.'); }
    return $val;
  }
}

Ну и на последок сам сервис:

<service id="settings_loader" class="MyBundle\SettingLoader">
  <argument type="service" id="doctrine.orm.default_entity_manager" />
</service>

Ключ для дефоултного менежера: doctrine.orm.default_entity_manager

Так, относительно ответов все понятно, что ничего не поняино. Каждый пишет то, что хочет, при это не чиатя самого вопроса: «есть ли какие-то математические алгоритмы при генерации случайных чисел?»

Причина не в том, что мы не можем использовать md5 от рандома или таймстампа, а в том, что на данный момент нам не известно конечное количество. Длина ключа должна быть не сложной для ввода простому пользователю. А если длина будет 32 символа? Ну давайте будем вводить! Наверное удобно будет… И при этом, если мы на данный момент возьмем все лишь 8 символов, а в результате нужно будет огромнейшее количество ключей, то что тогда?
Если знать, по какому алгоритму создавать, то потом совсем не будет проблем с увеличенеим ключа.