ICMS2 - одинаковые username'ы

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

Было на форуме обсуждение на эту тему пол года назад, к сожалению не могу найти тему.
ТС, сразу, мало кто поддержал, тогда он, чтобы подтвердить свои слова о существовании проблемы,
просто стал менять свои имя и аватар на имена и аватары своих оппонентов и продолжал общение.

что вы планируете с этим делать?

Спросите это у тех кто выкупил контакт — а то я там уже сам себя не могу найти))
клоны, клоны, клоны,…

У меня дело дошло до авторизации и вот думаю что с выше поднятым вопросом делать, знаю о решениях:
— не показывать ник, заменить на имя/фамилия // но это ничего не меняет
— формировать ник автоматически, аля: user125

Так как есть оставлять точно не буду.

Да, на форуме этот вопрос уже поднимался Проблема идентичности пользователей в icms. Решения там не нашли.

PIN, есть ещё варианты, например:
1. Везде рядом с именем пользователя показывать его id, типа такого: Вася Пупкин (id0000001). Это обсуждалось на форуме без каких либо конкретных решений.
2. Сделать хак и заставлять пользователей придумывать уникальные логины, которые потом и выводить вместо имени пользователя, а также подставлять в адресах вместо id. В идеале — сделать эту возможность опциональной с управлением через админку.
3. Очень сильно попросить r2 учесть пожелания по данной теме и сделать что-то подобное п.2. Он говорил, что подумает над этим вопросом, но у него сейчас другие приоритеты (и это понятно), поэтому если он и сделает что-то подобное, то очень нескоро. Тем более, что по его мнению, как я его понял, уникальные имена не нужны практически ни на каких сайтах, а там где нужны, пользователи должны сами заботиться о своей уникальности. Или админы там смогут сделать хак авторизации (хотя такие хаки противоречат концепции InstantCMS2 о возможности обновления ядра через админку).

В-общем, я пока вижу только два варианта: хакать под свои требования или ждать новые возможности в официальных сборках.

WebMan, мои размышления:
1. подписывать к нику что-либо ID, дату регистрации… считаю не информативным, при большом количестве все равно будет путаница.
2. пусть дублируются, но держать их в отдельной группе, можно перефразировать, в группу ПОЛЬЗОВАТЕЛИ переходят только при наличии индивидуального ника. Индивидуальность поддерживать среди ников с префиксом заданным в админке, префикс чисто технический и ни где не отображается, хотя можно и отображать.
Например:
! Василий <- такой ник единственный и все это понимают
Василий <- таких может быть сколь угодно.
или выводить не индивидуалов бледно серым, думаю подействует.
---
как сделать так чтобы не лесть в основой код? думаю не проблема. Главное определиться как будет лучше!

"цветовая дифференциация штанов" — имеет право на жизнь и вообще как мы без нее живем ))))

в группу ПОЛЬЗОВАТЕЛИ переходят только при наличии индивидуального ника

Спасибо, PIN, интересная мысль. И выделение ников уникальных пользователей — тоже может быть удобно. Только не префиксом, а действительно цветом или каким-нибудь значком.
Только вот как сделать это без хаков я пока не представляю. Хуками это скорее всего не получится. Нужно искать и пробовать.

WebMan, могу еще накидать идей: переход в состояние "уникальный" проводить через отдельный контроллер. где и будет к нику прибавляться префикс. Далее, в шаблоне отслеживать этот префикс, отсекать его и дифференцировать ник цветом.
Можно конечно и без префиксов обойтись, создав на основании созданного контроллера таблицу в базе и помещая туда уникумов, но это замарока не стоит того.
Вывод (мой): для реализации требуется 1 контроллер + адаптация шаблона (хотя и по нему можно подумать как меньше кодить)

хм… конечно в основной регистрации надо будет запретить использование префикса… вот те и хук с права.

PIN, достаточно создать в настройках пользователей ещё одно поле — признак уникальности. И после каждого изменения ника или логина пересчитівать этот признак по хуку (если таковой найдётся; или встроить нужный хук). Дополнительные таблицы не требуются. Всё же лучше использовать отдельное поле в БД, чем каждый раз парсить ник/логин.пользователя.

2. Сделать хак и заставлять пользователей придумывать уникальные логины, которые потом и выводить вместо имени пользователя

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

Можно ещё выводить связку неуникального ника (Вася Пупкин) с уникальным логином (vasyapup) так:
"Вася Пупкин ака vasyapup"
Но это опять же усложняет пользователям общение. Так что вариант с только одним уникальным логином (или ником) подходит больше всего.

Так что вариант с только одним уникальным логином (или ником) подходит больше всего.

Классика.

WebMan,

Дополнительные таблицы не требуются.

да накрутил ситуацию, сам склонен ничего не добавлять, даже поле