Программно зарегистрировать пользователя в членстве и ролях asp.net?

Я работаю над веб-приложением Asp.Net 4.0, которое использует функции членства и ролей Asp.Net.

В приложении будет три роли, у которых есть доступ к странице входа, и одна роль, у которой нет доступа.

Предполагается, что это работает следующим образом.

Внутренний пользователь (в одной из трех привилегированных ролей )создает пользователя. В коде это делается программно, а не с помощью страницы регистрации пользователя. Когда пользователь создается, ему добавляется непривилегированная роль, которая для ясности называется ролью Посетителя.

Затем внутренний пользователь создает ссылку для нового пользователя в видеhttps://www.example.com?link=cc82ae24-df47-4dbf-9440-1a6923945cf2

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

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

Вот мой код, объект «персоны» — это класс, который заполняется из базы данных, когда они попадают на страницу ссылки по умолчанию:

protected void LogUserIn(string p)
{
    SqlConnection conn = UtilityMethods.GetConnection();
    Guid par = Guid.Parse(p);
    BioProspect pers= new BioProspect(conn);
    pers.FillDetailsFromDb(par);

    testlable.Text = pers.ToString();
    Response.Cookies.Remove(FormsAuthentication.FormsCookieName);

    try
    {
        if (Membership.ValidateUser(pers.Email, pers.Pword))
        {

            FormsAuthentication.SetAuthCookie(pers.Email, true);

            Response.Redirect(Request.Url.Scheme + "://" + Request.Url.Host + "/About.aspx");
            testlable.Text = "Logged in!";
        }
        else
        {
            throw new Exception("Something went wrong");
        }
    }
    catch (Exception ex)
    {
        StringBuilder sb = new StringBuilder();
        foreach (DictionaryEntry d in ex.Data)
        {
            sb.Append(d.Key.ToString());
            sb.Append(": ");
            sb.Append(d.Value.ToString());
            sb.Append("\r\n");
        }

        AMessage(sb.ToString());
    }
}

Теперь я проверил значения имени пользователя и пароля в самой таблице базы данных, и все в порядке. Я понимаю, что пароль, хранящийся в таблицах aspnet, был засолен и хеширован, поэтому я проверяю значения во временной таблице, которую я создал для хранения открытого текста. Это правильно. Кроме того, в приведенном выше коде метод FormsAuthentication.SetAuthCookie запрашивает имя пользователя и пароль -, в данном случае имя пользователя — это адрес электронной почты. Эта информация также верна при проверке во время отладки.

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

Тем не менее, нам по-прежнему нужны преимущества платформы Asp.Net Membership, Profiles and Roles, поскольку «Посетителю» вполне может быть отправлено несколько ссылок с добавлением и изменением различных документов и версий документов с течением времени.

Может ли кто-нибудь придумать лучший способ? До сих пор я просмотрел большинство соответствующих записей здесь и здесь , но все они кажутся несколько неполными.

РЕДАКТИРОВАТЬ

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

По сути, проблема заключалась в том, что моему разделу членства в web.config нужно было указать, какой алгоритм хеширования использовать. На данный момент я понятия не имею, что такое по умолчанию, если он есть, но добавляю

в web.config, по крайней мере, позволил мне войти в систему пользователей, созданных после добавления вышеуказанной строки. Следующий шаг — понять, почему я не могу войти в систему других пользователей.

Однако я все еще получаю исключение ThreadAbortException, предложенное Джо, над решением которого я сейчас активно работаю.