Сергей Соколов, Хорошо, продолжим тему. Есть N дешевых людей (не знаю почему дешевые). Они собираются убить человека V, и придумали неплохой способ - он каждое утро возвращается по магистрали на скорости 130кмчас. Вопрос - сколько нужно дешевых людей, чтобы человек V улетел в кювет?
если вы на стороне клиента формируете дату, то что ему помешает изменить ее со своей стороны?
В самом простом случае, вы можете на сервере рендерить все ключевые даты и сразу отдавать их. Либо привести к 30-60-90 дней доступа.
Если услуга доступа у вас одна, то делаете таблицу транзакций
ид | пользователь | тип услуги | дата оплаты | дата начала | дата конца |
А пользователю добавляете поле конца подписки, чтобы не дергать таблицу с транзакциями. Это при условии что он покупает доступ мгновенно. Если нет (например действие начинается через неделю), то этот вариант не подойдет.
Если вам не принципиальны часы по подписке, то делайте поле date формата.
Делайте MVP и наращивайте проект. Измените задачу так, чтобы можно было отдавать клиентам кусками. Никому не надо, если вы будете большую фичу писать, а потом окажется что она не нужна.
freshik312, подписка на тэги делается по аналогии. в самом простом варианте вы можете придумать ее сами. Заметьте, что начальная база очень простая. Больше проблем на фронте.
FullstackWEB, и да, покажите мне в b3/b4 где работало так как надо? всегда так было, если колонки по высоте не стабильны - они перескакивают дальше, где могут разместиться.
А если вы даете человеческое задание как - надо по 2 колонки в ряд, то и выполнять нужно ее исходя из это потребности.
А в чем проблема собственно? Вы сами вполне подробно описали задачу свою, это уже половина решения. Хватит бояться, начинайте делать!
Хранить токен можно в сессии. Данные пользователя тоже там. Если ваше приложение это только прослойка, и вы ничего не храните на сервере, то не вижу совсем проблем.
Если у вас на сервере будут пользователи, и какой то иной функционал, то перепишите момент авторизации.