Форум сайта IronFlex.com.ua

[MaJ0r]

Ведущий пробел - это *space*Val. Форма регистрации пропускает такой вариант. Я пробовал с Фаустом.

 

До конца опыт не проводил без согласия, но тут к гадалке не ходи - запишет в базу уже без пробела.

 

Кстати, у тебя в мысли противоречие Val!=Val*space* означает как раз не отсекать. А ты следом пишешь, что нужно отсекать.

Конечно, нужно тримить

 

А там походу rtrim

не противоречие, а поток сознания ) Перескочил. Для нормальной секьюрности(тут на форуме, пока не было торговцев вроде пофиг) не должно быть ников типа *space*nickname, *space**space*nickname или пробелов в конце.

Вообще хорошо, что нашли такой косяк, а то кидки на форуме возможны.

[Admin]

Поменял товарищу ник. Алгоритм проверим, но на самом деле интересная штука :ab:

[andreyyy]

Написал новому нику грозное ) предупреждение. Сам же его и получил ))).

Как бывший, но классный программист, рисую алгоритм прверки ников при регистрации:

1. Отсекаются левые и правые окружающие пробелы.

2. Проверяется, чтобы все буквы в нике принадлежали одному языку - или английскому или русскому.

3. Ник сверяется с БД всех ников на форуме.

Все. Ни один хитро сделанный конь не проскочит.

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

 

2. пункт интересен, кстати. Пусть уже большая база, но хоть новых ограничила бы такая проверка от мимикрии.

 

Кстати, Аутло - не Аутло, а Нуль-утло ))

 

 

 

[andreyyy]

Написал новому нику грозное ) предупреждение. Сам же его и получил ))).

 

Все же думаю, что он тоже получил.

[Valery]

Поменял товарищу ник. Алгоритм проверим, но на самом деле интересная штука :ab:

Да тут все просто, как грабли ). Я, конечно, программного кода не видел, но порассуждать гипотетически могу. Пояснения за цитатой Андрея.

Все же думаю, что он тоже получил.

Думаю, что не получил. Скорее всего, при отсылке почты, как бы ты ее не отправлял, использован один и тот же механизм - по нику найти в БД профиль (или еще что-то там) адресата и запердолить на него письмо. Так вот, отыскивается ПЕРВЫЙ в БД профиль, соответсвующий нику. А первый в БД - я, поскольку намного раньше зареган.

Усе ))).

[andreyyy]

Думаю, что не получил. Скорее всего, при отсылке почты, как бы ты ее не отправлял, использован один и тот же механизм - по нику найти в БД профиль (или еще что-то там) адресата и запердолить на него письмо. Так вот, отыскивается ПЕРВЫЙ в БД профиль, соответсвующий нику. А первый в БД - я, поскольку намного раньше зареган.

Усе ))).

 

Вряд ли, коллега.

 

Думаю, добавляется одна запись с ключевым полем Val, но тогда она будет подтягиваться и тому профилю и к твоему.

 

Добавляется в таблицу личных сообщений одна запись как для пользователя Val.

Т.к. имеем двоих Валов, то при связывании с этой таблицей и ты и он увидят сообщение.

 

 

[andreyyy]

И если данные организованы так, как я описал (тупо одна таблица с сообщениями с ключевыми полями "Получатель" и "Отправитель"), то он видит тупо всю переписку, а не только сегодняшние тесты.

 

Вернее видел. Уже ж Админ переименовал.

[Valery]

Вряд ли, коллега.

 

Думаю, добавляется одна запись с ключевым полем Val, но тогда она будет подтягиваться и тому профилю и к твоему.

 

Добавляется в таблицу личных сообщений одна запись как для пользователя Val.

Т.к. имеем двоих Валов, то при связывании с этой таблицей и ты и он увидят сообщение.

Как бы там таблицы не связывались, дело не в этом. Я уже не помню названий SQL-функций и всякой прочей хрени, но смысл такой - когда лезут в БД для отыскания получателя, то делается выборка ОДНОГО объекта БД с ником Вал, и это значение ПЕРВОЕ в базе, т.е. Я. А можно было бы отобрать, используя другую функцию, МНОЖЕСТВО значений с ником Вал, вот тогда все ники получили бы почту. Но тот, кто писал код, сделал, в принципе, все правильно, он исходил из того, что дубль-ников не может быть в БД. Тут основная ошибка при валидации ника, там пропущен дубль. Кстати, коль уже заставили меня вспомнить кое-что из теории баз данных, то вот вам наглядный пример преимущества натуральных естественных ключей от искусственных - если бы ник был ключевым полем, то такая хрень никогда бы не произошла. Попривыкали объявлять ключами обыкновенные сиквенсы, - пожинайте плоды ).

[andreyyy]

Как бы там таблицы не связывались, дело не в этом. Я уже не помню названий SQL-функций и всякой прочей хрени, но смысл такой - когда лезут в БД для отыскания получателя, то делается выборка ОДНОГО объекта БД с ником Вал, и это значение ПЕРВОЕ в базе, т.е. Я. А можно было бы отобрать, используя другую функцию, МНОЖЕСТВО значений с ником Вал, вот тогда все ники получили бы почту. Но тот, кто писал код, сделал, в принципе, все правильно, он исходил из того, что дубль-ников не может быть в БД. Тут основная ошибка при валидации ника, там пропущен дубль. Кстати, коль уже заставили меня вспомнить кое-что из теории баз данных, то вот вам наглядный пример преимущества натуральных естественных ключей от искусственных - если бы ник был ключевым полем, то такая хрень никогда бы не произошла. Попривыкали объявлять ключами обыкновенные сиквенсы, - пожинайте плоды ).

Вал, прости идиота, но ....

 

Я не говорю о конкретных SQL-функциях, но организация данных как раз относится к алгоритму.

Итак. Давай рассуждать в терминах реляционных баз.

Я работаю, например, в vfp, но то не важно.

 

Ты говоришь, что нужно найти в б.д. пользователя. Т.е. у нас есть таблица пользователей. Не важно, одна она или разные поля разнесены по разным путем нормализации. Вопрос в другом: ЗАЧЕМ искать? Нашли мы запись пользователя, где его ник, имэйл, аватарка, дата рождения и т.д. И что дальше? Как происходит отправка сообщения? Вот здесь объясни в терминах баз.

 

Я утверждаю, что отправка сообщения - это добавление записи в таблицу. Новое сообщение - новая запись. В таблицу отдельную, не в таблицу пользвателей, естественно.

Если ключевое поле - ник, как ты и говоришь, то зачем нам искать пользователя в таблице пользователей для того, чтобы добавить новую запись в таблицу сообщений? У нас и так в поле ввода "Кому" стоит "Val".

 

Мы вставляем запись в таблицу сообщений (опять же, для простоты она одна, хотя может быть данные разнесены по нескольким).

Вводим запись с такими полями "Получатель", "Отправитель", "Тема", "Текст". Понятно, там может быть и вложение и т.д., но упрощаем.

Все. Сообщение "отправлено".

Заходя в Личные сообщения, каждый пользователь видит в разделе "Входящие" те записи, в которых в поле "Получатель" его ник, входя в "Отправленные" видит записи, в которых в поле "Отправитель" его ник.

Не важно, как это реализовано. То ли это объект Relation, который объединяет таблицу пользователей с таблицей сообщений по типу "один ко многим", то ли это вьюха на основе Select - а, где в условии выборки в where стоит нужная переменная.

Если ники одинаковы, то в любом случае увидят оба.

 

По крайней мере я бы так воял. Я примерно так делал документооборот в филиале ПИБа.

 

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

 

И это я еще молчу про то, что все это должно быть основано на SQL-командах, а не на таких навигационных, как seek или locate в фокспро. Но то уже такое... Сейчас про алгоритм.

 

Кстати, можно проверить если что )

[Valery]

Я не знаю, каким образом на форуме реализован "механизм" отсылки личных сообщений. Даже никогда не задумывался, как это выглядит в "замкнутых" локальных системах типа форума, когда не осуществляется отсылка во внешний мир. Гадать не собираюсь, это неблагодарная штука ). Поэтому готов принять твою модель построения таблиц и связей между ними, которую ты описал. Но у тебя тут есть одна принципиальная ошибка. Она делает мои рассуждения более правдоподобными, нежели твои. Итак...

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

- имя пользователя

- ник пользователя

- пароль

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

Отсюда следует что ? Логично предположить, что Ник - всего лишь один из многих, но совсем не основной атрибут учетной записи юзера ! Учетная запись юзера, опуская всякие нюансы, идентифицируется прежде всего Именем пользователя. Что же следует из этого ? А вот что.

Когда отправляется личное сообщение, следуя твоей модели, его нужно записать в отдельную таблицу и эту запись "привязать" к УЧЕТНОЙ ЗАПИСИ юзера с именем получателя, соответствующим НИКу, пусть будет тот же Вал. Но Вал не идентифицирует абсолютно однозначно учетную запись юзера, ее нужно отыскать в БД, т.е., как я и писал раньше - обратиться к БД. Ну а дальше - все, как я описывал ). Система найдет МОЮ учетную запись, ибо она ПЕРВАЯ в БД, а не запись второго Вал-а.

Как то так...