Насколько я понимаю каждый раз JWT подписывался корректно, просто значение realm бралось любое, которое передано в POST запросе и можно было его менять.
Я думаю, тут речь про «консультационные фирмы» (они же out-staff, видимо). Из конца статьи — «ответственные лица относятся к сторонам с конфликтующими интересами — конкурентам и клиентам». В out-staff компаниях очень часто смешанные команды (сотрудники заказчика, контракторы, люди из других компаний). В таком контексте это по крайней мере логично. Но в таком случае (out-staff) общаться с клиентами (с сотрудниками огранизации-клиента) надо всем, а не только синьорам (ну если не исключительно синьоры в штате).
По учебным материалам может быть решением привязка их к имеющимся именно у вас (и только у вас) компонентам. Например, стендам, заготовкам и т.д. Не каким-то базовым вещам, которые продаются, а именно чему-то модифицированному. Когда несколько базовых компонентов (электромоторы, шестеренки, элементы и т.д.) уже скомпонованы как-то. Скорее всего это сложно сделать без необходимости переписывать учебную программу. Но если получится — желающим украсть проще будет написать все с нуля, чем у себя создавать такие же базовые кирпичики-компоненты.
Есть еще amphp и reactphp — и то и другое позволяет делать постоянно запущенные, асинхронно работающие приложения на PHP. Первый немного активнее развивается по-моему (больше асинхронных оберток под разные БД и прочее). Они могут части друг-друга использовать (через адаптеры). Это уже большой новый мир, много пакетов и все отлично работает (особенно если думать про возможные утечки памяти и следить за этим).
Для меня Drupal — отличный способ сделать средний или небольшой проект быстро и максимально комфортно — модулей очень много и они почти всегда работают как надо. Проблемы возникают, когда необходимо сделать что-то необычное — но тут уже приходиться смотреть в сторону фреймворков. Перед одним необычным проектом я долго разрывался — кастомизировать модули Drupal либо воссоздавать все прелести вроде вложенных комментариев, модуля Insert и прочих под Yii, остановился на Yii и все получилось на ура — сделать все именно так, как хочется намного проще. Однако в процессе сильно скучал по простоте Drupal — скачал модуль, проставил галки — и все работает.
У меня вполне отлично 20 сайтов в одной БД (около 250 таблиц) — суммарный трафик не большой, но проблем вообще никаких пока. Когда вырастет нагрузка — всегда можно перенести в отдельную базу.
Опытным путем определил для себя таблицы, которые можно делать общими (Drupal 6):
Скорее всего какие-то из них не стоило делать общими (например, модуль Database logging, включенный по-умолчанию, ругается на watchdog — но я его выключаю — чтобы не плодить лишних таблиц). Особенно удобны переводы, настройки wysiwyg и профили imagecache. Но на практике проблем не возникает пока.
Для того, чтобы не было проблем при установке — можно устанавливать с настройками для одного префикса на все таблицы (создаст все таблицы с новым префиксом). Потом добавлять префиксы общих таблиц и удалять только что созданные, т.к. они уже заменены старыми.
Сложность еще и в том, что у разных людей разное восприятие самого действия покупки, а следовательно и цвета кнопки. Например в банкоматах, банка, в котором у меня счет — кнопка «Внести наличные» красная, а «Получить наличные» — зеленая. Вроде как получать деньги — прикольно и спокойно с карточки, а класть их туда — неспокойно и красно. А мне, например, наоборот хочется чтобы было — положил деньги — и успокоился, а когда снимаешь — будь внимателен, тратишь, теряешь их. Также, наверное и кнопкой В корзину. Всем по-разному она видится.
Только не смотря на это поток продолжается. Даже от тех друзей, кто спамит ежедневно и сурово. Т.е. понятно, что не сам человек этим занимается, удалять из друзей не хочется — все-таки знакомый. Но вот блок аккаунта на 10-15 пометку «Это спам» добавить не мешало бы. Иначе какой смысл в этой кнопке?
Насколько я понимаю каждый раз JWT подписывался корректно, просто значение realm бралось любое, которое передано в POST запросе и можно было его менять.
Опытным путем определил для себя таблицы, которые можно делать общими (Drupal 6):
default, access, actions, actions_aid, authmap, imagecache_action, imagecache_preset, filter_formats, languages, locales_source, locales_target, l10n_update_file, l10n_update_project, permission, role, sessions, term_data, term_hierarchy, term_relation, term_synonym, users, users_roles, vocabulary, watchdog, wysiwyg, wysiwyg_user.
Скорее всего какие-то из них не стоило делать общими (например, модуль Database logging, включенный по-умолчанию, ругается на watchdog — но я его выключаю — чтобы не плодить лишних таблиц). Особенно удобны переводы, настройки wysiwyg и профили imagecache. Но на практике проблем не возникает пока.
Для того, чтобы не было проблем при установке — можно устанавливать с настройками для одного префикса на все таблицы (создаст все таблицы с новым префиксом). Потом добавлять префиксы общих таблиц и удалять только что созданные, т.к. они уже заменены старыми.