is_email()사용자 제공 이메일 주소가 유효한지 확인하는 데 사용 하고 있습니다. 예를 들면 다음과 같습니다.
$email = $_POST['email'];
if ( is_email( $email ) )
// Do something.내가 아는 한,이 함수는 데이터베이스에 정보를 쓰지 않습니다. $email함수에 전달하기 전에 소독해야합니까 ?
답변:
is_email()trac 의 기능을 살펴보면 문자열 테스트 일뿐이므로 위생 처리 할 필요가없는 것처럼 보입니다. 이 함수가 true를 반환하면 데이터베이스로 보내기 전에 소독 할 필요가 없습니다.
is_email()기능 소스는 일반적인 워드 프레스 구현하고 무엇을 완전히 작동하지 않는 RFC 6531이 있습니다. 한 가지 이유는 IETF® (Internet Engineering Task Force) 지침 에 따라 기본 PHP FILTER_VALIDATE_EMAIL상수 filter_var()가 무언가를 검증하는 데 훨씬 좋지 않기 때문일 수 있습니다 .
포인트는 것입니다 RFC 6531이 있습니다 "유니 코드 문자는 ASCII 범위를 초과" . 즉, 그것들은 (로컬 부분-앞에 @) :
- 대문자 및 소문자 영문 (a–z, A–Z) (ASCII : 65–90, 97–122)
- 숫자
0에9(ASCII : 48-57)- 이 특수 문자 :
! # $ % & ' * + - / = ? ^ _ ` { | } ~- 문자
.(점, 마침표, 마침표) (ASCII : 46)는 첫 문자 나 마지막 문자가 아니며 연속적으로 나타나지 않는 경우 (예 :John..Doe@example.com허용되지 않음)를 제공합니다.- 특수 문자는 제한이 허용됩니다. 그들은:
- 우주와
"(),:;<>@[\](ASCII : 32, 34, 40, 41, 44, 58, 59, 60, 62, 64, 91–93)- 특수 문자에 대한 제한 사항은 따옴표 사이에 포함 된 경우에만 사용해야하며 그 중 2 개 (백 슬래시 \ 및 따옴표 "(ASCII : 92, 34))도 백 슬래시 앞에 와야합니다
\(예 :"\\"및"\""). .- 주석은 로컬 부분의 양쪽 끝에 괄호로 묶을 수 있습니다. 예를 들어
john.smith(comment)@example.com및(comment)john.smith@example.com모두와 동일"john.smith@example.com"하지만john.(comment)smith@example.com유효하지 않습니다.U+007F메일 시스템이 로컬 파트를 지정할 때 사용할 문자를 제한 할 수 있지만 위의 UTF-8로 인코딩 된 국제 문자 는 RFC 6531에서 허용됩니다.
전역 / 도메인 부분의 경우 :
이메일 주소의 도메인 이름 부분은 엄격한 지침을 준수해야합니다. 문자, 숫자, 하이픈 및 점으로 구성된 호스트 이름의 요구 사항과 일치해야합니다. 또한 도메인 부분은
jsmith@[192.168.2.1]또는jsmith@[IPv6:2001:db8::1][…] 와 같이 대괄호로 둘러싸인 IP 주소 리터럴 일 수 있습니다 .
이로 인해 다음과 같이 이상하지만 유효한 전자 메일 주소가 생성 될 수 있습니다.
localpart.ending.with.dot.@example.com(comment)localpart@example.com"this is v@lid!"@example.com"much.more unusual"@example.compostbox@comadmin@mailserver1"()<>[]:,;\\@\"\\\\!#$%&\'*+-/=?^_`{}| ~.a"@example.org" "@example.org
출처 : php.net / author gt@kani.hu –이 글의 저자에 의해 수정 된 예
로컬 및 도메인 길이 제한도 있습니다.
이메일 주소의 형식은
local-part@domain경우 로컬 부분은 64 자까지 될 수있다 긴과 도메인 이름이 253 자까지있을 수 있지만 - 256 자 길이의 최대 정방향 또는 역방향 경로가 전체 이메일 주소를 제한 수 없습니다 더 이상 254 자 . [2] 공식적인 정의는 RFC 5322에 (섹션 3.2.3와 3.4.1) 및 RFC 5321 - 정보 용 RFC 3696 [3]과 관련된 에라타에 주어진 더 읽을 수있는 형태로 .
출처 : Wikipedia
그리고 이것이 WordPress에서 확인하는 것입니다.
strlen( $email ) < 3strpos( $email, '@', 1 ) === false!preg_match( '/^[a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]+$/', $local )preg_match( '/\.{2,}/', $domain )trim( $domain, " \t\n\r\0\x0B." ) !== $domain$subs = explode( '.', $domain );다음과
2 > count( $subs )trim( $sub, " \t\n\r\0\x0B-" ) !== $sub!preg_match('/^[a-z0-9-]+$/i', $sub )출처 : WP Core v4.0
위에서 언급 한 모든 사례는 is_email()false를 반환하도록 트리거 합니다. 결과는 필터링이 가능하고 (콜백을 첨부 할 수 있음) 필터에는 세 개의 인수가 있으며 마지막 인수가 이유입니다. 예:
return apply_filters( 'is_email', false, $email, 'sub_hyphen_limits' );이는 특정 검사에서 반환 된 결과를 무시할 수 있음을 의미합니다.
예를 들어 Umlaut 도메인, TLD 전용 도메인 부분 등을 허용하는 특수 검사를 추가 할 수 있습니다.
WordPress는 대부분의 경우 안전하지만 메일 서버가 실제로 RFC를 준수해야하므로 더 제한적입니다. 모든 메일 서버가 RF 6531 지침을 준수하는 것은 아닙니다.
재미는 sidefact : 두 개의 관련된 기능이 내부에 있습니다 ~/wp-includes/formatting: is_email()와 sanitize_email(). 그들은 실질적 으로 동일한 기능입니다. 나는 왜 누군가가 다른 것을 제공하는 필터에 콜백으로 하나를 추가하는 대신 함수 내용을 다른 곳으로 복사하는 것이 좋은 아이디어라고 생각했는지 전혀 모른다. 로 v0.71 이후 및 1.5 버전 이후 동일 당신이 청소 문자열을 얻을, 나는 개인적으로 나중에를 사용합니다. 참고 이 RFC를 준수하지 않는 것으로도 상태.is_email() sanitize_email() is_email()
모든 것을 소독하십시오!
기본 보안 규칙 중 하나는 사용자의 입력을 절대 신뢰하지 않는 것입니다. 일반적으로, 나는 is_email () 또는 다른 특정 함수의 구현에 신경 쓰지 않습니다. 어쩌면 구현이 언젠가 변경 될 수 있습니다. 누가 알아. 나는 그것이 타협 될 수 있다고 가정해야합니다. 가정은해야한다 항상 사용자 입력이 결국 데이터베이스 향하는 아무것도 이중 때문에, 적극적으로 적대적이라고 할 수 있으며, 일부 기능에 나눠을 해제하기 전에 사용자 입력의 모든 비트를 살균 할 수 있습니다. 이것은 일반적인 보안 위생입니다.