Запоздалый комментарий, но просто эту идею которую ты озвучил, чтобы каждый аноним в системе был юзером запала мне в мозг.

Сперва я её отвергал - дескать зачем мне рыться в огромной таблице условно сессиий, когда надо найти пользователя.
Затем я о ней просто помнил и периодически раздумывал.
И в итоге похоже что так оно и есть. Всё пришло к тому, что либо мне учёт разных сущностей в БД делать костылями типа

с последующими извратами при формировании самого запроса в зависимости от анонима или юзера,
Либо для каждой сущности делать отдельно таблицу связи с юзерами и отдельно с анонимами.

И вот сейчас я пришёл к осознанию того, что необходимо принять и реализовать твой вариант, который стоило бы принять 2 года назад :)

Опыт вещь серьёзная!

vmag,

Ну тут загвоздка возникла вокруг такой задачи: Необходимость оформлять подписку (E-Mail) на обновления разных сущностей. И не обязательно для этого регистрироваться в системе.

Т.е. к примеру: Есть обсуждение, и я попав на него - жму "Получать новости этого обсуждения на E-Mail". И соответственно просто должен иметь возможность ввести е-маил, получить письмо с подтверждением и в дальнейшем получать новости по этой сущности в системе.

И загвоздка вся вокруг этих таблиц:




Тут алгоритм такой:
1. При указании e-mail'а хоть авторизованым юзером, хоть анонимом сперва этот адрес вносится в emails, и для вставленного emailID (если вставится, т.е. не существующий) формируем запрос на подтверждение email'а в emailReq
2. И вот в этой схеме проявляется вся двоякость, что если запрос был создан пользователем, то надо искать запросы с userID таким-то, если анонимом - то по sessID и NULL в userID.

Кроме того, особая вишенка в том что я делаю, что типа анонимная подписка - она тоже как-бы сквозь-сессионная. Т.е. аноним сделал так:
1. Подписался на тред, подтвердил е-маил, и в рамках его текущей сессии он уже может бегать по тредам и просто жать "на это тоже подпишусь" и всё это учитывается по emailID подтверждённый в его сессии.
2. Потом он пропал с сайта, сессия подохла, и он снова заходит и снова жмёт "подписаться", ему говорят давай e-mail, и подтверждай его. Он вводит e-mail, тот же который был в п.1, система видит что в тот раз это был "сессионно" подтверждённый емаил, значит в другой сесиии можно его тоже "подтверждать". (Если емаил закреплён за юзером, то такого сделать нельзя)
3. Новый аноним подтверждает высланным кодом прежний емаил, и ему вся его прежняя история подписок на этот емаил доступна. Эдакий сквозной аноним.

И получается что сейчас у меня есть пользователи, а параллельно есть ещё учёт сессий, связываемых между собой в одного субъекта условно по подтверждённому emailID. А если бы делать анонима как советовал Кот Матроскин изначально новая сессия - просто пользователь, с флагом isAnon=1, то была бы везде привязка к userID, а различия бы строились на основе этого флага.

Пока не решился я на перелопачивание, аккуратно без костылей реализую описанный алгоритм, но очко нет-нет да жмётся на предмет того, а не рухнет ли колосс в какой-то момент?
Это я утрирую конечно, архитектура вполне логичная и г.вном с палками стараюсь дыры не заделывать, однако "более лучшее решение" конечно уже было высказано в начале этого топика.

Dimitry Sibiryakov,

Ну как что... Например возможность зайти с другого ПК, где нет этой куки, или вообще привычки на непонятных ресурсах работать в приватном режиме.

А если на куку только завязываться, то соответственно потёрли куку - всё, потерялась вся эта "сквозная" привязка.

И внезапно система вернётся к более неудобному способу идентификации по почте. В чём
проблема-то?
Ну не совсем идентификация по почте. Это конкретно для тех кто не хочет регистрироваться, но готов получать информацию. А повторная идентфикация по почте - это просто как интересная "плюшка", где подтвердив E-Mail анон имеет свой "личный кабинет" сам изначально о таком и не мечтавший.



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

Vmag , в твоей схеме я сходу вижу например такую проблему:
Ключ подписки описанный тобой (userID, entityID, emailAddr) позволяет:
1. На один E-Mail присобачить сколь угодно много пользователей с подписками.
2. Вносит хаос в виде как раз того, что ты выдал за интересную особенность: чтобы пользователь с прикреплённым к нему e-mail'ом мог оформить подписку от себя но на другой e-mail. Я конечно за возможности и свободу действий пользователей, но мне этот вольный бардак кажется лишним.

А по поводу судов и спама - во-первых потверждение email'а никто не отменял для старта рассылки. Во вторых в тексте каждого рассылочного письма чётко читаемая и не прятаемая ссылка: Хотите удалить из рассылки свою почту - щёлкайте сюда.
Совсем не вижу что именно юридически обязывающего даёт регистрация пользователя на моём сайте в плане получения писем. На многих ресурсах есть возможность подписаться не регистрируюсь, это вполне рабочая практика.
А уж как кого зовут в интернете - если бы это узнавалось из регистрации на сайте - думаю интернет и стиль общения в нём были бы совсем другими чем сейчас :)
А тов.Майору один хер при необходимости более важны будут логи моего веб-сервера для поиска кого-то забредшего на сайт :)

skyANA,

Это просто получается доп.прослойка ведь. Смысл в том, чтобы этот "Контакт" был связан с конкретным субъектом. И этот субъект - это владелец е-майла, и при этом неважно он авторизован на сайте или нет.

Предложение контакта просто добавляет ещё один уровень абстракции между субъектом и емаилом.

Проблема в том, чтобы этот контакт мог быть олицетворён как с пользователем имеющим на сайте учётку, так и просто со случайным посетителем решившим подписаться на что-либо.

Спасибо, я погружусь поглубже в эту схему. Надо понять всё это спокойно и применительно к моему случаю.


А что в этом плохого? Вроде вполне логично прежде чем работать вообще с email'ом и писать его в БД, оценить с помощью какого-нибудь filter_var'а




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

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

Спасибо!

Товарищ, а можно пример какого-то емаил'а или лучше несколько разных на которые были ложные срабатывания, я проверю свою функцию проверки и отловлю если есть проблемные места.