Решил сделать активацию пользователя но не догоняю как это можно реализовать. Может кто подскажет как это можно сделать ? Код самой регистрации таков. 

создаешь в таблице столбец activateый по умолчанию равен 0... далее... после того, как заполненные поля в форме обратобались пользователю на мыло отошли сслыку для подтверждения регистрации, функция mail(), после того как пользователь пройдет по указанной сслыке обнови столбец activate на 1 и все

Неее.... Лучше создай таблицу active
id_user | hash

В первую колонку id юзера, во вторую хеш код, который отправил по мылу...
Потом в скрипте проверяй активирован ли пользователь...

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

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

Добавлено @ 09:48



Ребят, это же неудобно ^_^

Это сообщение отредактировал(а) SoWa - 6.5.2009, 09:49

Зависит от степени извращенности ума

Мне нормально, я желаю все контроллировать...

ИМХО лучше 1 раз под контролем занести данные в таблицу, и потом не писать дополнительные условия.

Я из Алгоритмов сюда пришел, у меня ум ух как извращен 

Ладно, давай посмотрим, что автор скажет 

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

Добавлено через 24 секунды

Извращенец))   

Ну да, она-то как раз и желательна для обычных людей именно со столбцом "activated"(потому что мало кто делает поиск в таблице как я  ) Но это при условии, что неактивированые пользователи тоже могут входить. Тогда тут как ни крути, что мой, что твой вариант- оба напичканы условиями, и оптиимзация сразу в голову не приходит. (Оптимизация на уменьшение числа условий и сложности кода)
А вот если пользователя, который еще не активировался- пускать нельзя, то тут имхо мой вариант приемлем. Поискать юзеря в основной таблице, не найти, и сказать ему, что "ты, дорогой мой, либо не зареган, либо не активирован(на это тоже можно условие)". 
Хотя это все может быть недружелюбным для клиента.
Философский вопрос 

SoWa, это действительно философский вопрос... "Посмотрим, что ответит автор" (С) SoWa

fakeman, почти как у SneG0K, только поле activated переименовать в right. права у юзера будут - none=0, user=1, admin=2 и т.д., в меру извращенности. После активации это поле вполне может и пригодится в обычной жизни ;-)
Правда для активации нужно куда-то запихать еще и дату авторизации, чтобы элегантно почистить всех недозарегистрировавшихся юзеров через пару дней. В принципе, эту дату тоже можно приспособить в основную таблицу, с "основным" смыслом - "дата последней активности юзера". Но тут уже на любителя, иногда удобнее и в отдельную таблицу влепить. 
Еще куда-то нужно влепить некий хеш, по которому будем идентифицировать "пришельцев" из почтовых сообщений об активизации. Потенциально, это поле тоже можно использовать в жизни зарегистрированных юзеров, для поддержки, к примеру, какого-нибудь почтового-же интерфейса общения с юзерами - рассылка новостей, там или еще чего.

более конкретное mho - добавить поле right в основную таблицу, добавить таблицу `users_online` с полями {user, hash, date} в базу и работать с комбинацией этих таблиц... В качестве hash'а можно использовать какую-то простую функцию от Session_Id.

Ждем автора