Podstrony
- telcocafe
- [PHP+MySQL] Problem z połączeniem mysqli('localhost', 'xxx', 'xxx', 'xxx'
- [PHP] Wyrażenia regularne. Zamienić name="info_imie" na name="{info_imie}"
- [php] Dodanie textu do pliku. Problem... :) POMOCY!!!!!!!!!!!!!
- [PHP] Skrypt cenzury Chcę cenzury!!!
- Dobre programy do edycji php Dobre programy do edycji php
- [PHP] podział na strony php: podział na strony
- [PHP i MySQL] jak pobrac liczbe rezultatow Jak pobrac liczbe rezultatow???
- jak zrobic aktualizacje php? pomocy!!!!!
- Błąd w PHP-Fusion pomocy !!!!!
- Daczego nie dziala?? skrypt php nie chce działać!!!
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- freetocraft.keep.pl
telcocafe
Dodaję opcję określającą dozwolone znaki w loginach użytkowników. Przykład: dowolne litery, cyfry, odstępy, _ . -Na forach spotykam różne kombinacje - we wzorcu zazwyczaj są umieszczone wszystkie polskie litery, jednak:
1. Takie wyrażenie nie pozwala wstawiać znaków z innych języków, np. niemieckiego
2. Z drugiej strony nie można zezwolić na wszystkie znaki UTF-8.
Rozważmy wzorzec:/[A-Za-z]*/uKażdy znak UTF-8 pasuje do wzoru, np. &$%$#%!&*. Istnieje też możliwość, że
3. Przeglądarka wyśle formularz w innym kodowaniu niż UTF-8.
Jakie jest najprostsze, a skuteczne rozwiązanie problemu?
A dlaczego nie można użyć np. niemieckiego u z kropeczkami? Przeszkadza ci to w loginie? Większość skryptów nie robi z tym problemu. Niektóre ograniczają do znaków dozwolonych dla URLi.
Pewnie niedokładnie wyjaśniłem problem. Otóż w loginie:
1. Mogą znaleźć się dowolne znaki z różnych alfabetów, w tym: polskie, niemieckie, itd.
2. Nie można zezwolić na wszystkie znaki UTF-8, czyli ograniczamy się tylko do liter, cyfr, itd.
Przedstawione wyżej wyrażenie zezwoli na każdy znak UTF-8, czyli nie spełnia drugiego warunku.
Czy to jest możliwe bez dużego nakładu kodu?
Okazuje się, że jest więcej komplikacji. W loginie nie może wystąpić znak /. Czy są inne znaki, które mogą spowodować błąd, jeżeli login zostanie umieszczony w adresie URL, np. localhost/user/Login_usera?
Użytkownik Ferrari edytował ten post 24 listopad 2009, 21:19
unikatowy slug z loginu i tak trzeba generować oddzielnie (polskich znaków nie powinno w nim być). W Pythonie jest funkcja "ord" zwracająca liczbową reprezentację dla podanego znaku unikod. W PHP powinno być coś podobnego - dopuszczasz znaki z określonego przedziału np. pomiędzy 48-127.
Współczesne przeglądarki dobrze radzą sobie z niestandardowymi znakami w URL-ach. Na pewno trzeba usuwać lub nie pozwalać na /, ?, &, # i być może inne znaki. Czy dopuszczenie innych znaków w URL spoza tych kluczowych (np. /, ?, &, #) może stworzyć luki w bezpieczeństwie lub powodować błędy?
Problem z ogonkami może być taki że czasami może coś się posypać - np. IE, albo jakaś strona, która błędnie podlinkuje wklejony link z ogonkami etc. Możliwość dodatkowych znaków jak )(*&^%$#@@!~ bezpieczeństwu nie zagrozi, ale może zmylić kod, który wywołuje odpowiedni kontroler dla danego URLa (jeżeli używa któregoś ze znaków w URLu do mapowania)
http://forum.ks-eksp...=słoń_żółw
Opera enkoduje, FF i Chrome nie. IE nie wiem :P
Użytkownik Riklaunim edytował ten post 25 listopad 2009, 02:24
Opera nie koduje, gdy znaki w atrybucie <href> są już zakodowane. W przeciwnym wypadku koduje. IE 8 na odwrót.
Lepiej nie ryzykować ze wszystkimi znakami UTF-8 w adresie. Na pewno trzeba by wycinać #, /, ?, &, =. Nawet jeśli zakodujemy & lub /, Apache je zinterpretuje i wyświetli błąd 404 bądź uzna dalszą część za QUERY_STRING.
Znaki poza A-Z, a-z, 0-9, _, -, . i spacji są raczej rzadko używane. Raczej nikt nie powinien narzekać, jeśli narzucę z góry ograniczenie, że inne są niedozwolone?
:huh: Robisz portal społecznościowy? Rozejrzyj się, w sieci do loginów używa się znaków alfabetu łacińskiego. Rzadkością są loginy z polskimi znakami, dla przykładu. Jeszcze lepiej będzie, gdy stworzysz logowanie za pomocą adresu e-mail. Wtedy szary użytkownik nie będzie musiał wymyślać loginu.
@andrzej_aa: Modyfikuję CMS-a, aby stał się bardziej przyjazny, a login jest zarazem nazwą użytkownika :)
Dokonałem odkrycia, przeglądając podręcznik PHP - PCRE - Unicode. Działa wyrażenie:/^[0-9\pL _.-]*$/uPozostaje pytanie, czy kod zawsze będzie działał bez zastrzeżeń na wszystkich systemach operacyjnych i wersjach PHP 5, czyli: nie dopuści innego znaku niż litery lub cyfry bądź nie przepuści użytkownika z poprawnym loginem.
Sugerują, aby podawać w URL-u ID zamiast loginu ze względu na wydajność. Przeprowadzę kiedyś testy.
hmm, ja używam np. czegoś takiego, przy $_POST działa:
[A-Za-zóąśłżźćńÓĄŚŁŻŹĆŃ]