Здравствуйте, stele, Вы писали:

S>Ща полезу в исходники смотреть от куда беруться именованные анонимы, чтобы аргументированно крыть идеями.

Берутся они из таблицы messages, там есть есть поле usernick наряду с uid. Для случая смены имени (одинаковый uid) или именованного анонима (uid==0). Наследие простейших бэбэшек, когда весь форум хранился в одной таблице и в одном текстовом файле.

Здравствуйте, akasoft, Вы писали:

A>Берутся они из таблицы messages, там есть есть поле usernick наряду с uid. Для случая смены имени (одинаковый uid) или именованного анонима (uid==0). Наследие простейших бэбэшек, когда весь форум хранился в одной таблице и в одном текстовом файле.

Это не наследие, это специально так задумано.

Здравствуйте, AndrewVK, Вы писали:


AVK>Это не наследие, это специально так задумано.

А может быть теперь сервер будет отдавать usernick клиентам при uid == 0 в виде @"<Аноним_XXXXX>" тем самым можно избежать переделывания Януса и все версии включая бету и релиз получат возможность различать анонимов. Из минусов загадим базу псевдоименами анонимов. А к следующему релизу готовить отдельную поле для номера анонима и механизм его вывода. Правда остаётся вопрос

При расщеплении ветки анонимы перенумеруются. И тот который был в оригинальной ветке, например, 23-им, станет 1-ым.

Но я думаю это не принципиально анонимов всё равно до некоторой степени рассортировали и уж какой он первый в янусе или тридцатый на сервере не принципиально.

Здравствуйте, stele, Вы писали:

Тополнение предложение
S>А может быть теперь сервер будет отдавать usernick клиентам при uid == 0 в виде @"<Аноним_XXXXX>" ...
читать так
А может быть теперь сервер будет отдавать usernick клиентам при uid == 0 и отсутствии оригинального usernick в виде @"<Аноним_XXXXX>" ...

Здравствуйте, stele, Вы писали:

S>А может быть теперь сервер будет отдавать usernick клиентам при uid == 0 в виде @"<Аноним_XXXXX>"

Это все изврат. Единственный разумный вариант — отдавать хеш IP отдельным полем.

Здравствуйте, AndrewVK, Вы писали:


AVK>Это все изврат. Единственный разумный вариант — отдавать хеш IP отдельным полем.

А вы сделали хеш только по IP, а я предполагал первый символ хеш ip, второй хеш Browser ID (User-Agent) Strings или их хитрая сумма какая так поселективней будет деанонимизирование тех кто за проксёй.

Здравствуйте, stele, Вы писали:

S>А вы сделали хеш только по IP, а я предполагал первый символ хеш ip, второй хеш Browser ID (User-Agent) Strings или их хитрая сумма какая так поселективней будет деанонимизирование тех кто за проксёй.

Это не фиксируется в БД.

Здравствуйте, AndrewVK, Вы писали:

AVK>Это не фиксируется в БД.
Вот речь как раз о том, чтобы фиксировать. генерить 2-х (или 4-х) байтовый хеш из IP, x-forwarded-for, user-agent и т.п. и класть его в базу.
Плюс можно класть его в пирожки. Тогда Dialup-щики с бегающими адресами будут распознаваться.

Здравствуйте, stele, Вы писали:

S>А вы сделали хеш только по IP...

По моему, в большинстве случаев вполне достаточно REMOTE_ADDR и HTTP_X_FORWARDED_FOR.

S>А может быть теперь сервер будет отдавать usernick клиентам при uid == 0 в виде @"<Аноним_XXXXX>" тем самым можно избежать переделывания Януса и все версии включая бету и релиз получат возможность различать анонимов. Из минусов загадим базу псевдоименами анонимов. А к следующему релизу готовить отдельную поле для номера анонима и механизм его вывода. Правда остаётся вопрос
S>

S>При расщеплении ветки анонимы перенумеруются. И тот который был в оригинальной ветке, например, 23-им, станет 1-ым.

S>Но я думаю это не принципиально анонимов всё равно до некоторой степени рассортировали и уж какой он первый в янусе или тридцатый на сервере не принципиально.

Если сервер генерирует на лету, то пусть и Янус генерирует на лету — делов-то

Здравствуйте, AndrewVK, Вы писали:

S>>А может быть теперь сервер будет отдавать usernick клиентам при uid == 0 в виде @"<Аноним_XXXXX>"

AVK>Это все изврат. Единственный разумный вариант — отдавать хеш IP отдельным полем.

Значит в Янусе в ближайшее время не будет

А при таком раскладе раздавая хэш ip всем вы очередную волну праведного гнева в которую вылилось осуждение первоапрельской шутки adonz и ко не вызовете. Одно дело уже обработанный и обезличенный номер, который может повторяться с течением времени и верен в некоторый интервал времени. А другое дело хэш ip, по которому можно прослеживать действия на протяжении всего времени. Как то это стрёмно с разных точек зрения.

Здравствуйте, stele, Вы писали:

S>А при таком раскладе раздавая хэш ip всем вы очередную волну праведного гнева в которую вылилось осуждение первоапрельской шутки adonz и ко не вызовете.

Главная отмазка, этот номер идентифицирует абонента, не работает. Обратное преобразование приприличном хеше выполнить невозможно.

S> Одно дело уже обработанный и обезличенный номер, который может повторяться с течением времени и верен в некоторый интервал времени. А другое дело хэш ip, по которому можно прослеживать действия на протяжении всего времени. Как то это стрёмно с разных точек зрения.

Стремно это только и исключительно с точки зрения того, кто периодически занимается пакостями (а чем еще можно оправдать длительное хождение из под анонима?).

Здравствуйте, Mamut, Вы писали:

M>Если сервер генерирует на лету, то пусть и Янус генерирует на лету — делов-то

Ты предлагаешь отсылать при синхронизации IPшники?

M>>Если сервер генерирует на лету, то пусть и Янус генерирует на лету — делов-то

AVK>Ты предлагаешь отсылать при синхронизации IPшники?

Эээээ... Торможу

Hello, AndrewVK!

S>> А при таком раскладе раздавая хэш ip всем вы очередную волну праведного
S>> гнева в которую вылилось осуждение первоапрельской шутки adonz и ко не
S>> вызовете.

A> Главная отмазка, этот номер идентифицирует абонента, не работает.
A> Обратное преобразование приприличном хеше выполнить невозможно.

Если алгоритм хэширования будет известен (например, будет генерироваться динамически и янусом), то можно будет заранее составить словарь хэшей по всем ипишникам (ну или по часто используемым регионам, их не так много) и элементарно сравнивать.
Дабы усложнить такую атаку хэш нужно "подсаливать".
Но если подсаливать чем-то постоянным, например User-Agent (хотя он конечно совсем не постоянен),- то такой информации в базе не хранится, а если чем-то переменным, например временем сообщения, то для одного и того-же анонима он каждый раз будет разным.
Это можно победить генеря хэш только раз, подсаливая его чем угодно, но его придётся хранить.
Я это уже почти всё реализовал. Постоянная идентификация анонима осуществляется через ASP.NET Profile (с включенной анонимной идентификацией, отслеживает через куки). Для сообщений пометки хранятся в UserTitle и UserColor. По идее вся нужная инфраструктура в Янусе уже есть, ибо они сейчас как раз для этого и используются, типа пометок "jetbrains", "mvp" & etc.

Здравствуйте, der Igel, Вы писали:

DI>Если алгоритм хэширования будет известен (например, будет генерироваться динамически и янусом),

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

DI>Дабы усложнить такую атаку хэш нужно "подсаливать".

Ага.

DI>Это можно победить генеря хэш только раз, подсаливая его чем угодно, но его придётся хранить.

Именно.

DI>Я это уже почти всё реализовал. Постоянная идентификация анонима осуществляется через ASP.NET Profile (с включенной анонимной идентификацией, отслеживает через куки). Для сообщений пометки хранятся в UserTitle и UserColor. По идее вся нужная инфраструктура в Янусе уже есть, ибо они сейчас как раз для этого и используются, типа пометок "jetbrains", "mvp" & etc.

А янус их не подерживает

>Дабы усложнить такую атаку хэш нужно "подсаливать".

обычно говорят подсолить (ну или подсоливать)
а то звучит как-то немного не так, сассоциировалось с кабинетом липосакции


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

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

Hello, Serjio!

S> обычно говорят подсолить (ну или подсоливать)
S> а то звучит как-то немного не так, сассоциировалось с кабинетом
S> липосакции

Согласен, сало оставим.
А вообще перевод, новые термины и т.д. у нас обсуждают в "Проблемах перевода". Там можно поднять эту тему.

раз уж анонимов посчитали (что есть очень гут)
и здесь было бы удобно видеть номер анонима




а поскольку я иногда просмариваю форумы RSDN в Outlook Express
то хорошо бы еще и в поле From поставить номер анонима






P.S. а также совсем замечательно если еще и оценка message будет
при просмотре сообщения как html