2009-06-03 2 views
4

Предположим, я создаю веб-приложение, пользовательские страницы которого можно найти по адресу http://example.com/NAME. Каков наилучший способ убедиться, что имя пользователя не конфликтует с зарезервированным словом (например, «около», «контакт» и т. Д.)? Я могу думать о двух путях:Лучший способ убедиться, что имя пользователя не является зарезервированным словом?

  • Ведение списка где-то в моем коде. Это здорово и все, но означает, что у меня есть еще один фрагмент кода, который мне нужно изменить, если я решит, скажем, изменить страницу «about» на «aboutus».
  • Запросите URI (например, http://example.com/someusername) и проверьте, существует ли он (не возвращает 404). Это похоже на хак, но, с другой стороны, он делает именно то, что он должен делать. С другой стороны, я не могу ничего зарезервировать, не создавая страницы для этого.

Что было бы лучшим способом сделать это? Ручная проверка имени пользователя не является вариантом. Благодаря!

EDIT: Я забыл упомянуть, имя пользователя имеет идти на корню, как это:

http://example.com/USERNAME

Не нравится:

http://example.com/users/USERNAME

Следовательно, почему я задаю этот вопрос. Это по техническим причинам, не спрашивайте.

+0

Возможно ли, чтобы URL-адрес страницы пользователя был http://www.example.com/users/NAME? Будет ли это решать вашу проблему? – Sean

+0

Нет, мне нужно, чтобы это произошло от корня по техническим причинам. –

ответ

2

В интересах полноты, если вы не можете изменить маршрутизацию. Другая возможность заключается в том, чтобы ваши маршруты пользователя, а ваши маршруты, отличные от пользователя, имели программное различие. Например, если вы приложили '_' к концу каждого из маршрутов пользователя, то вы можете убедиться, что пользователи расположены по адресу: http://example.com/NAME_ и другой маршрут не будет конца в '_'

+0

Aha! Хорошая идея, это именно то, что мне нужно. Это взломать, но я должен ожидать, что с условиями, с которыми я работаю. Благодаря! –

+11

Существует существующее соглашение от Unix, prefix ~. – MSalters

+0

@MSalters: О да, я видел это раньше. Тогда я буду использовать это. –

1

Вы знаете только, что это за «зарезервированные» слова. Поэтому лучше поддерживать список и проверять его.

Другой метод будет, если вы используете CMS, тогда все эти keywods «about», «contact» и т. Д. Будут находиться в вашей базе данных. Подтвердите это.

2

Как насчет изменения схемы маршрутизации, чтобы пользователи находились на example.com/users/NAME?

0

Вы всегда можете посмотреть и посмотреть, как работает stackoverflow.com.

+0

Это будет «Использование схемы URI, которая не соответствует той, о которой идет речь» – Quentin

+0

Кажется, я ответил, прежде чем вопрос был полностью задан. – quamrana

1

Как насчет создания резервных учетных записей сначала со всеми резервными словами? просто перечислите все возможные и создайте их.

если вы используете

www.example.com/user/name 

тогда не будет никаких проблем, но это, кажется, как вы хотели бы, чтобы URL, чтобы быть коротким.

5

Я бы настоятельно предложил использовать уникальный путь, например, http://example.com/users/NAME. В противном случае, что вы собираетесь делать, если хотите добавить зарезервированное слово, но пользователь уже принял его как свое имя пользователя? В конце концов вы столкнетесь со всеми возможными проблемами миграции.

В качестве альтернативы, если у вас должно быть что-то, что сразу http://example.com/, можете ли вы префикс всех имен пользователей? Чтобы пользователь jerryjvl перевел на ссылку http://example.com/user_jerryjvl?

Если у вас нет другого возможного решения, я бы сказал, что либо проверяйте имена пользователей, независимо от того, какой источник данных определяет, что такое «зарезервированные слова», или где-то где-то ищет файл/таблицу/структуру поиска, содержащий все зарезервированные слова.

1

Прямо рядом с текстовым полем, то например: «Пожалуйста, используйте свой личный псевдоним или настоящее имя. Имена пользователей с общими словами, указывающими на принадлежность к администрации сайта, могут быть отменены».

+1

А, да, это наверняка заставит пользователей подумать: «Я не должен использовать это имя», если они хотят использовать «плохое» имя. Или, нет, не будет. – OregonGhost

1

Ведение списка где-то в моем коде. Это здорово и все, но означает, что у меня есть еще один фрагмент кода, который мне нужно изменить, если я решит, скажем, изменить страницу «about» на «aboutus».

Ваши меню должны храниться в массиве/списке. Таким образом, вы должны редактировать только 1 часть кода, а не 2. =]

Тогда, поскольку все меню находятся в одном массиве, вы можете сопоставить имя пользователя с элементами в массиве. например

$menu = array('About', 'Contact', 'Home') 
if(in_array($username, $menu)) { 
    echo 'invalid username' 
} 
2

Я сохраняю зарезервированные слова внутри кода. Это код PERL, который я использую в http://postbit.com/ сайт, чтобы проверить, если usernamename зарезервированное слово:

# Black list of logins and sub-domains reserved keywords 
my @black_list = qw(
    about access account accounts add address adm admin administration 
    adult advertising affiliate affiliates ajax analytics android anon 
    anonymous api app apps archive atom auth authentication 
    ... 
); 

my $username_normalized = lc($username); 
    $username_normalized =~ s/\W//gs; # 'log-in' -> 'login' 

for my $this_username (@black_list) { 
    if ($username_normalized eq $this_username) { 
    die("This username is already taken. Please choose other username.\n"); 
    } 
} 

Полный список зарезервированных имен (например, «CSS», «картинки», «JS», «admin», «root», «old», «test», «www», «admin», «login», «devel» ...) с более чем 300 именами входа в систему размещены здесь:

http://blog.postbit.com/reserved-username-list.html

Смежные вопросы