Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71597 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 94683 invoked from network); 26 Jan 2014 20:27:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Jan 2014 20:27:42 -0000 Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 173.1.104.101 rproxy2-b-iv.figureone.com Received: from [173.1.104.101] ([173.1.104.101:58510] helo=rproxy2-b-iv.figureone.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1D/33-12631-CBF65E25 for ; Sun, 26 Jan 2014 15:27:41 -0500 Received: from bad.dop.co ([108.12.130.219]) by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id MVB43134 for ; Sun, 26 Jan 2014 12:27:34 -0800 Date: Sun, 26 Jan 2014 15:27:20 -0500 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <1477919782.20140126152720@cypressintegrated.com> To: Andrey Andreev In-Reply-To: References: <52E319F2.8080705@sugarcrm.com> <52E3959D.4000103@sugarcrm.com> <52E45A5D.7020807@sugarcrm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Session IP address matching From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman) > I think somebody already pointed out that this would be useful for > admin interfaces. How many applications don't have that? If you force this measure on /wp-admin or equivalent, you'll never retain customers. (Some frameworks offer this option in userland anyway -- plus the absolutely _vital_ ability for the user to turn it off him/herself.) Admin screens for a bank, maybe. But then I hope you have so many other restrictions (such as not allowing connections except over multi-factor VPN) that checking the IP is just a formality. A special case where the feature might do more good than harm is when both server and clients are on the same LAN with static IPs. If the organization is computing/scientific in nature it might be reasonable to expect inside jobs using network taps, bespoke interception boxes -- or whatever -- to intercept SSL and also hijack per-request session IDs (perhaps by timing for end-of-day or something). The extra IP check might then be practical protection. But unless the internal systems saw seriously high traffic surely a userland implementation would work just fine. (My) bottom line is that putting this feature in core is a clear recipe for disaster. Most PHP users, let alone the "app deployer" type of users, don't know s**t about HTTP or TCP/IP. The moment turning on this feature gets mistakenly documented as a best practice on some excited newbie's blog, or somebody's downvoted-but-not-deleted StackOverflow post, you've caused way more harm than good. Look at it this way: if even *Stefan* (Suhosin) recommends conservative use, take that caveat very seriously. -- S.