Действительно ли это - разумный процесс регистрации пользователя?
Вы можете попробовать:
function get(){
var table = $('table');
var data = [];
table.find('tr').each(function (i, el) {
// no thead
if( i != 0){
var $tds = $(this).find('td');
var row = [];
$tds.each(function (i, el){
row.push($(this).text());
});
data.push(row);
}
});
return data;
}
console.log(get());<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<table>
<thead>
<tr>
<th>field1</th>
<th>field2</th>
<th>field3</th>
<th>field4</th>
</tr>
</thead>
<tr>
<td>1</td>
<td>aaa</td>
<td>aaa</td>
</tr>
<tr>
<td>2</td>
<td>bbb</td>
<td>bbb</td>
</tr>
<tr>
<td>3</td>
<td>ccc</td>
<td>ccc</td>
</tr>
<tr>
<td>4</td>
<td>ddd</td>
<td>ddd</td>
</tr>
</table>10 ответов
Это - хорошая практика для проверки любого вида входа, который Вы получаете от посетителя. Эмпирическое правило состоит в том, чтобы всегда удостоверяться, что Вы получаете то, что Вы ожидаете, и ничто иное. Я сказал бы, что Вы делаете его хорошо, включая подтверждение адреса электронной почты.
Небольшой вопрос, хотя; почему делают это двухступенчатым процессом? почему бы не позволить пользователю вводить пароль сразу же? Это обычно чувствует себя намного больше комфортно для пользователя.
Кроме того, вместо того, чтобы использовать registration_confirmation_code, Вы могли бы хотеть рассмотреть использование хеша MD5 (и т.п.) адреса электронной почты пользователей. Тем путем Вам не нужно дополнительное поле, и можно даже не учесть идентификатор, если Вам нравится.
- Dave
Не доверяйте людям, даже если они являются внутренними к Вашей организации. Это звучит плохим, но если Вы не имеете дело с очень небольшой группой, Ваш метод является мудрым выбором.
Еще одна вещь, можно хотеть удостовериться, что их электронная почта уникальна.
Другой подход использует централизованную аутентификацию и пропускает целый процесс регистрации.
На первой попытке входа в систему создайте профиль пользователя из шаблона.
Аутентификация может быть сделана много путей. Идеально, что-то как LDAP (или Active Directory, если это - то, как Вы качаетесь). Также возможно использовать почтовый сервер для аутентификации, в зависимости от того, как это настроено.
Система OpenID была в основном изобретена для решения этой проблемы. В основном кто-то приезжает в Ваш сайт и говорит, что "Я - XYZ, и можно проверить это путем согласовывания с ABC". У Вас затем есть их поставщик OpenID (который, вероятно, был бы сервером в Вашей компании; если у Вас есть LDAP, Вы уже - большая часть пути там), проверяют, что они - то, кто они говорят, что они (ими входящий в сайт поставщика OpenID). Если можно доверять поставщику OpenID, и учетная запись OpenID не была поставлена под угрозу, то Вы только что проверили своего пользователя. Можно, вероятно, уйти без формального процесса регистрации..., просто отправляют их в экран установки учетной записи (предполагающий, что Вам нужны больше, чем пароль + электронная почта в Вашем примере, поскольку обоим из тех предоставляют через OpenID) на их первом входе в систему.
Обратите внимание, что OpenID может только проверить, что у пользователя есть учетные данные для данного OpenID, не, что пользователь уникален, или что они - то, кто они говорят, что они. Но это действительно не отличается, чем какая-либо существующая схема.
Это имеет преимущества не требования, чтобы пользователь дал Вам пароль, который они могли бы забыть (и они могут изменить свой пароль с поставщиком OpenID, и это будет изменено для всех их сайтов то использование OpenID). Существуют библиотеки OpenID, доступные для большинства главных языков, и прокрутка Вашего собственного не должна быть слишком сложной.
Мне нравятся сайты, которые используют адрес электронной почты в качестве идентификатора для входа в систему. Кроме того, почему бы не получить пароль впереди, когда они регистрируются?
Вы, действительно кажется, проходите очень большое усилие для внутреннего приложения? Сколько мошенничества Вы ожидаете?
Защита Вашего приложения от even-less-verified-than-usual пользователей является хорошей вещью, но еще лучше - что Вы защищаете случайных людей от того, чтобы быть массово разосланным с электронной почтой от Вашей системы. Требованием подписываются, Вы удостоверяетесь, что X не может зарегистрироваться в Вашем сервисе, утверждающем быть Y, и заставляющий электронную почту быть отправленным в Y каждый раз, когда требуется связаться с пользователем. Это также дает Y возможность сказать "что? нет, это не я" и отклонение щелчка, отправьте отчет ARF или иначе сообщите, что у кого-то есть Вы на.
При сборе адресов электронной почты необходимо всегда проверять их.
я позволил пользователю в прямо после того, как они нажимают на ссылку из электронной почты и отправляют им фиктивную передачу, которую они могут изменить позже. (используйте электронную почту для имени пользователя),
это устраняет один шаг от процесса и делает регистрацию что намного легче.
Единственное 'нападение', к которому Вы обращаетесь через электронное письмо с подтверждением, регистрирует новые учетные записи с помощью случайных адресов электронной почты.
IOW, если Вы уезжаете, которые выходят, 'взломщик', мог:
- зарегистрируйте учетные записи, использующие просто случайные адреса мусора
- зарегистрируйте учетные записи с помощью адресов других людей
К счастью, в большинстве приложений, такое нападение не является очень разрушительным. Это может помочь взломщику создать чужие идентификационные данные в приложении для социальных сетей или сделать жизнь немного легче для спам-робота, или это могло использоваться только для раздражения законного владельца адреса электронной почты - но это об этом.
Я сказал бы, сохраняют регистрационное требование на всякий случай, но фрагментируют двухступенчатый процесс (позвольте пользователям создать username+password сразу же).
Все еще необходимо отправить им подтвердить код по электронной почте.
В зависимости от приложения Вы не хотите людей регистрация с помощью адреса электронной почты коллег.