Daria Motorina

Такс, я не понял, при чём тут компилятор вообще. Для вставки видео с ютуба на другой сайт используются фреймы. А для вставки кода в тело ответа тег<code></code>. Компилятор - это вообще программа которая переводит код с одного языка на другой. При чём тут ютуб или хабр? Кинь мне на ссылки на те

компиляторы, которые пользователи вставляют для ответа на вопросы.

.

1, 2 В вакансиях обычно указывают вилку зп и список требований

3, где повезет, там и брать

Либо при создании заявки дать обновлять аккаунт (что не всегда правильно), либо дать протечь абстракции и сделать все через join. Ну и доставать данные через аккаунт, а не через заявки.
Вот пример: https://laracasts.com/discuss/channels/eloquent/or...

Вы тут попали в больную гнойную мозоль тостера. Каждый день кто-то приходит и спрашивает "как стать программистом", в 99% случаев это бездельники которые ничего не умеют, и учиться не хотят, но увидели на ютубе видос о том что "программисты зарабатывают от 200к в месяц", а потом их завалила реклама курсов "стань питон-джедаем за 3 дня и уедь в США кататься на порше". Но на курсы денег нет поэтому они приходят сюда и спрашивают "как стать программистом за 3 дня самостоятельно, и можно ли будет получать хотя бы 150к на начальном этапе".

Так что не удивляйтесь комментариям.

По делу - начальный этап самый сложный. Во многом из-за засилья "хочунов", которые ничего не умеют но заспамили уже весь интернет и всех работодателей. Через это придется как-то пробиться, или упорством или хитростью. Надо как можно раньше получать реальный опыт, неважно какими способами - и искать работу джуном. Быть готовой что 20 раз откажут перед тем как взять. Дальше все зависит от упорства, города и удачи.

Город какой у вас?

На эту тему есть даже запрос в оффициальном github docker https://github.com/docker/docker/issues/7198#issue...

Есть вариант с монтированием в режиме чтения /etc/passwd, /etc/group и пробросом своего uid
Подсмотрено тут: wiki.ros.org/docker/Tutorials/GUI

docker run --rm  -ti \
           -v $(pwd):/tmp/hx \
           -w /tmp/hx \
           -v /etc/group:/etc/group:ro \
           -v /etc/passwd:/etc/passwd:ro \
           --user=$USER \
           debian:jessie

Не уверен что это в общем случае достаточно безопастный способ, но он определенно самый простой и безболезенный если на хосте linux.

Если я ничего не напутал и Вас понял правильно, то можно..

Алгоритм действий будет примерно такой:
- создать сущности для таблиц из БД
- установить и прописать их связи между собой
- Проверить
- Повторить )

UPD:
Я тут подумал..
Если всё равно надо будет находить и устанавливать связи между собой, то как вариант можно "сгенерить БД из Доктрины" и залить данные из старой базы.

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

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

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

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

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

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

Есть два варианта хранения данных об авторизованном пользователе:
1) В куки (так по умолчанию используется в асп.нет): необходимые данные (claims) шифруются machineKey и отдаются пользователю в http-only куках, таким образом при каждом запросе на сервер они присылаются, расшифровываются и далее можно проверить в необходимых местах.
плюсы: полностью stateless, нет надобности обращаться к БД
минусы: при необходимости "выбить" сессию со стороны сервера нужно поднимать более сложную логику и хранить флаги в промежуточном хранилище (проверять что если для такого-то пользователя требуется завершить, то такие действия, иначе другие);
2) Ключ сессии: после успешной аутентификации авторизуем пользователя и claims храним на сервере в быстрой памяти или БД (key-value), где ключ - ключ сессии, значение - любые данные.
плюсы: есть полный контроль состоянием авторизации (как и возможность завершить сессию со стороны сервера, так и сменить пользователю роль(или другие параметры) "на лету")
минусы: организация доп. прослойки - кэша или хранение в БД (медленно), при перезапуске/падении сервиса сессии клиентам потребуется перелогиниться.

1
1.1 В куки писать или ключ сессии или шифрованные данные о пользователе, сессия - абстрактное понятие (это пара: ключ и данные), ключ должен быть защищенным, т.е. трудным к копированию (хотя бы зрительно трудно запомнить), уникальным (чтобы не возникло коллизий: двум разным пользователям выдался один и тот же ключ, т.е. это не должна быть хэш-функция от логина-пароля или IP или чего-то неуникального).
1.2 В асп.нет существуют атрибуты авторизации (в которых можно расставлять проверки на требование таковой, роль, конкретный пользователь), в общем смысле логика такова: поступил запрос на сервер, далее нужно посмотреть к какому ресурсу идёт обращение (защищенному или свободному), если ресурс защищен, то проверить куки (ключ сессии или шифрованные данные), расшифровать/получить данные о сессии из кэша и предпринять решение: пускаем или не пускаем (отдаём 401/403 или отдаем 200/404/...).
1.3 Завести на сервере (в кэше или БД) словарь , при алгоритме проверки сессии добавить условие проверки на наличие записи в словаре.
1.4 С нескольких - словаря не нужно.

2
2.1 Даже если пользователь входит через ВК всё равно нужно отдавать свои ключи сессий/шифрованные данные, а вот внутри данных уже хранить access_token от вк-шной сессии, так очень маленькая вероятность, что токен ВК утечет, а если утек ключ сессии, то действия будут ограничены только функционалом сайта.
2.2 После расшифровки куки или данных по ключу сессии делать доп запрос на сервер ВК с токеном, который сохранился при аутентификации (access_token), запрос простой, например получить имя пользователя, если ВК выдал что токен просрочен или ошибку, то сессию закрывать или куки с данными обнулять.

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

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

git'y пофиг

Где вы его ожидаете увидеть?

Метод добавляет атрибут в обьект, из которого потом заново нужно строить html.