Что ограничения должны я налагать на имена пользователей
Я изменил код @ andre-bernardes, чтобы использовать «|» разделители перед именами запросов и разделители ":" перед операторами SQL. Различные разделители облегчают анализ файла Queries.txt с помощью python и создание словаря запросов и операторов SQL. Затем вы можете использовать этот словарь, например, для создания представлений в таблице SQLite.
VBA-код для извлечения SQL-запросов
Public Sub ListQueries()
' Modified from André Bernardes
Dim i As Integer
Dim ff As Long
ff = FreeFile()
Open "C:\Dev\Queries.txt" For Output As #ff
On Error Resume Next
For i = 0 To CurrentDb.QueryDefs.Count - 1
Debug.Print "|" & CurrentDb.QueryDefs(i).Name & ":"
Print #ff, "|" & CurrentDb.QueryDefs(i).Name & ":"
Debug.Print CurrentDb.QueryDefs(i).SQL
Print #ff, CurrentDb.QueryDefs(i).SQL
Next
End Sub
Python-код для анализа Queries.txt в словаре
queries_file = open(data_path + '/Queries.txt')
queries = queries_file.read().split('|')
l = [x.split(':') for x in queries]
l.pop(0)
table_name_to_query = {name: query for name, query in l}
Создание представлений SQLite из запросов Access
import sqlite3
conn = sqlite3.connect('example.db')
c = conn.cursor()
for table, query in table_name_to_query.items():
try:
c.execute("CREATE VIEW `%s` AS %s" % (table,query))
print("\n\n"+ table + " passed")
print(query)
except Exception as e:
print("\n\n"+ table + " error")
print(e)
print(query)
4 ответа
Итак, давайте предположим, что вы правильно выполняете все свои задачи по кодированию строк. У вас нет SQL-инъекций, HTML-инъекций или мест, где вы ' вы не должны использовать кодировку URL. Так что нам не нужно беспокоиться о том, что символы типа «<&% \ будут магическими в некоторых контекстах. И вы используете UTF-8 для всего, поэтому весь Юникод в игре. Какие еще есть причины для ограничения имен пользователей?
Начнем со всех управляющих символов, для здравомыслия. Нет причин использовать символы от U + 0000 до U + 001F или от U + 007F до U + 009F в имени пользователя.
Затем отклоните или нормализуйте неожиданные пробелы. Вы можете разрешить пробел в имени пользователя, но вы почти наверняка не хотите разрешать ведущие пробелы, конечные пробелы или более одного пробела в строке. Они могут отображать то же самое в HTML, но, вероятно, являются ошибкой пользователя это запутает.
Если вы намерены разрешить использование этого имени пользователя для входа в систему через базовую аутентификацию HTTP, вы должны запретить использование символа : , потому что схема Basic Auth кодирует пару «имя пользователя: пароль» без экранирования, если в имени пользователя или пароле есть двоеточие. Таким образом, по крайней мере одно из имени пользователя и пароля должно иметь исключенное двоеточие, и лучше, чтобы это было имя пользователя, потому что ограничение выбора паролей людьми намного хуже, чем имена пользователей.
Для базовой аутентификации вы также можете отключить все не -ASCII, поскольку они по-разному обрабатываются в разных браузерах. IE кодирует их, используя системную кодовую страницу; Firefox кодирует их с помощью ISO-8859-1; Opera кодирует их с помощью UTF-8. Пользователи должны быть по крайней мере предупреждены перед тем, как выбирать имена, отличные от ASCII, если HTTP Auth будет доступен, так как на самом деле их использование будет очень ненадежным.
Затем рассмотрите другие управляющие последовательности Unicode, такие вещи, как переопределения биди, и другие перечисленные там символы, не подходят для использования в разметке. Вероятно, вы собираетесь поместить их в разметку, и вы не хотите, чтобы кто-то с RLO в своем имени переворачивал загрузку текста на вашей странице назад.
Кроме того, если вы разрешите Unicode выполнять нормализацию строк Вы получаете. В противном случае у кого-то может быть имя пользователя с составным символом о-умлаут ö , и он может удивиться, почему он не может войти в систему на Mac, который по умолчанию будет использовать отдельный символ o , за которым следует сочетая умлаут. Обычно в сети нормализуется к составной форме NFC. Вы также можете выполнить декомпозицию совместимости, используя форму NFKC; это позволит пользователю Крису войти в систему с японской клавиатуры в режиме ромадзи на всю ширину, набрав Ｃｈｒｉｓ. Это общие проблемы, которые хорошо решить для всех входных данных вашего веб-приложения, но для идентификаторов, таких как имена пользователей, может быть более критичным исправить это.
Наконец, убедитесь, что длина подходит для размещения в базе данных без изменения тихого усечения имя, особенно если вы храните как байты UTF-8, которые вы не хотите обрезать на полпути через последовательность байтов. Усечение имени пользователя также может быть проблемой безопасности в целом.
Если вы используете имена пользователей в качестве уникального средства идентификации, у вас есть гораздо больше поводов для беспокойства: уже упомянутая проблема двойников, таких как Крис (с кириллицей Es С ). Их слишком много, чтобы вы могли с ними справиться; либо ограничиваться ASCII, либо иметь дополнительные средства идентификации пользователей. (Или все равно, как это не так;
Я никогда не видел смысла в добавлении ограничений для имен пользователей. Если ваш код устойчив к атакам с использованием sql-инъекций, позвольте им вставлять все, что они хотят.
Единственное ограничение, которое я бы добавил, - это ограничение максимальной длины, чтобы его можно было сохранить в таблице БД.
Разрешить им использовать любой символ Unicode в своем имени пользователя. Добавление ограничений на разрешенные символы, вероятно, просто раздражает людей, использующих язык, отличный от ascii.
Зависит от многих вещей, например, если у пользователей будет собственный URL-адрес, вы должны быть осторожны, чтобы кто-то, создавший имя пользователя "% 41llan", не конфликтовал с Пользователь назвал "Allan", хотя использование косой черты может вызвать проблемы. Обратите внимание на ограничения такого рода.
Защита от SQL-инъекций является обязательной, но она, вероятно, должна быть в вашем коде, а не в ограничениях имени пользователя. Определенные символы обязательно следует экранировать, например \,% и т. Д.
Это будет зависеть от того, на каком сайте вы работаете, но я думаю, что некоторые нецензурные ограничения на слова сделают ваш сайт более профессиональным, несмотря ни на что. Если кто-то увидит, что людям разрешено использовать "РУКОВОДСТВО" в качестве имени пользователя, ваш сайт будет выглядеть по-детски. Это все равно, что позволить подросткам разбегаться по вашему книжному магазину. ИМХО. Вам, вероятно, не нужно становиться более разборчивым, хотя это полностью зависит от вас.
Это немного не по теме, но, как еще один совет по имени пользователя, отличная функция любого веб-сайта позволяет пользователям изменять их Имя пользователя с течением времени. Вы можете просто использовать число в качестве первичного ключа, и позволив им это сделать, можно сэкономить много нытья и людей, создающих новые учетные записи, потому что они хотели изменить свое имя пользователя. : D