| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Общие вопросы > Реализация активации аккаунта через мыло |
| Автор: KoLiZeI 26.12.2007, 11:32 |
| Помогите пожалуйста сделать активацию через мыло: 1) Что нужно отправлять пользователю на мыло, как я понял отправляется определённая сессID, которая до момента активации хранится в бд для данного пользователя 2) нужна ли она будет потом, что нужно хранить в бд что бы аккаунт был неактивным до момента активации. как лучше это сделать подскажите!  |
| Автор: MoLeX 26.12.2007, 11:43 |
| KoLiZeI я бы сделал так: 1. генерим какоето число которое в дальнейшем подставим в запрос + сохраняем его в бд. 2. после того как юзер щелкнул по ссылке делаем проверку - правильное число или нет. З.Ы. по правде тут море вариантов все зависит от твоей фантазии... |
| Автор: krundetz 26.12.2007, 11:48 |
| Попробуйте сделать вот так. Заведите параллельно к основной табличке пользователей ещё одну где будут хранится неавторизованные пользователи(хотя можно использовать и одну для) она будет отличаться от основной только полем в котором будет хранится некий уникальный идентификатор, как вариант идентификатор сессии. При регистрации пользователя вы заносите его данные в эту табличку и отправляете ему ссылку например такого вида http://mysite.ru/activation=уникальныйидентификатор. При переходе на неё происходит обрашение к табличке с неактивироваными пользователями проверяется есть ли там такой уникальный иденификатор после чего происходит занесение даных в основную табличку пользователей и уже после этого пользователю выводится предложение авторизоваться на сайте или можно его автоматически авторизовывать. |
| Автор: MoLeX 26.12.2007, 11:55 |
| krundetz а если свопадет уникальный индификатор еще 2 людей, т.е. они тоже авторизируются) можно немного модернизировать 1. id - номер зареганного юзера 2. activation - сгенерированая строка. т.е. получим http://site/auth.php?id={номер}&activation={строка}. когда скрипт получает эти данные то подставляем в запрос SELECT * FROM table WHERE id={номер}, получаем значение поля activation и сравниваем его с полученным. |
| Автор: krundetz 26.12.2007, 12:09 | ||
Тогда возможно лучше будет запрос такого вида: SELECT * FROM table WHERE id={номер} AND activation LIKE {строка} Кстати какой вариант предпочтительнее с одной табличкой для пользователей или с двумя для активированых и неакивировных пользователей. |
| Автор: MoLeX 26.12.2007, 12:20 | ||||
krundetz  толко наверное не
а строка:
???? |
| Автор: krundetz 26.12.2007, 12:29 |
| MoLeX да вы совершенно правы я имел в виду именно такой код. Можно узнать ваше мнение по поводу заданного мной несколькими постами выше вопроса? |
| Автор: MoLeX 26.12.2007, 12:35 | ||
если ты про это, то на мой взгляд: а смысл 2-таблицы? можно просто поле впихнуть дополнительно типо активирован юзер или нет. и еще лучше использовать 3-е поле - время регистрации, нам же не надо чтобы человек мог подтвердить регистрацию в течении скажем всего года, пусть это будет 24 часа или другое время. |
| Автор: krundetz 26.12.2007, 12:56 | ||
тоесть ты предлагаешь сделать поле activation в котором будет хранится либо YES либо уникальный идентификатор, и как только пользователь активируется оно меняет значение. Зачем добавлять ещё и время регистрации если обычно есть дата регистрации просто время нужно отсчитать от него дапустим не 24 часа, а трое суток. У меня возникает такой вопрос а как избавляться от неактивированиых пользователей мало ли пользователь взял да и ошибся при вводи почтового адреса. Сам сколько раз ошибался. Если переодически шерстить таблицу на предмет неактивированых пользователей у которых истек срок активации накладно может выдьте если записей много. |
| Автор: MoLeX 26.12.2007, 13:05 | ||
| krundetz а как срипт сможет отсчитать когда юзер попытался зарегаться? Добавлено через 5 минут и 8 секунд
просто скриптом смотреть и удалять их... |
| Автор: KoLiZeI 26.12.2007, 13:15 | ||
| Спасибо всем огромное за помощь, воспользовался методом krundetz с дополнительной таблицей для хранения временных аккаунтов! Добавлено через 3 минуты и 53 секунды
Тогда ещё в основной таблице надо хранить уникальный номер и активный/неактивный, плюс в моём случае это задача появилась в процессе работы, когда уже основная работа сделана, и вся выборка идёт по активным аакаунтам, и чтобы делать ещё проверку на активность, займет слишком много времени что бы всё переделывать. |
| Автор: MoLeX 26.12.2007, 13:22 | ||
если проект будет посещаемый и популярным то не следует так делать, ведь тебе прийдется переносить данные из одной таблицы в другую (или я не прав?), что наложит след на скорость работы... |
| Автор: KoLiZeI 26.12.2007, 13:24 | ||
Да но это будет проходить лишь 1 раз при активации аккаунта |
| Автор: MoLeX 26.12.2007, 13:31 |
это понятно что один раз. ладно насколько помнится MySQL уютно себя чуствует при ОЧЕНЬ большом кол-ве поситителей (точное значение не помню, так что и не буду врать), так что нечего страшного по сути не будет  |
| Автор: krundetz 26.12.2007, 14:41 | ||||||
Почему наложит? Мы же в любом случае будем вставлять данные, а при однатобличном варианте у нас потом ещё добавится один запрос на изменнение данных при активации. Тоесть таблица пользователей самая часто используемая почти во всех проектах, особенно форумах, будет испытывать при однотобличном варианте большую нагрузку на один запрос. По определению вторая таблица неактивированых пользователей должна получится меньеше значет и сделать очистку в соответствие с определенным условием будет легче. Вот так я рассуждал, может я ошибаюсь, поэтому прошу высказывать своё мнение.
Очень просто у нас есть поле в котором есть дата регистрации даем на регистрацию 3 суток создаем скрипт который будет чистить таблицу и будем его вызывать кроном в 24 часа раз за сутки. Это мой вариант.
ну я исхожу из того что у нас не выделеный и даже не виртуальный сервер а самый простой вируальный хостинг |
| Автор: MoLeX 26.12.2007, 14:52 |
| я имею в виду что при 2-х табличном варианте, когда юзер Вася перейдет из разряды нективированых в активированные то необходимо будет перенести всю его инфу из 1-ой таблицы в другую. не проще в таком варианет сделать однотибличную регистрацию с одним полем? ведь будет намного быстрее поставить в какое-то поле 1 (пусть 1- авторизирован, а 0-неавтор) чем переносить данные, особенно если они не ограничиваются 3-4 полями... |
| Автор: krundetz 26.12.2007, 15:11 |
Вобщем надо эксперементировать писать и такой и такой вариант и тест создовать нагрузочный и смотреть производительность. Может займусь в выходные, интересно же  |
