Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71539
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.216.68 as permitted sender)
MIME-Version: 1.0
Date: Sat, 25 Jan 2014 03:11:37 +0200
Message-ID: <CAPhkiZyMULFgCoTaaqtwx_34ovTX-36dTdVUgMXE_aWPd5O+WQ@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11394e6e08784c04f0c12860
Subject: Session IP address matching
From: narf@devilix.net (Andrey Andreev)

--001a11394e6e08784c04f0c12860
Content-Type: text/plain; charset=UTF-8

Hello,

ext/session lacks the option to check the visitor's IP address and this is
a much needed feature for pretty much everybody writing web applications
today. I'll call it 'session.match_ip' for now.
So much needed in fact, that I'm surprised PHP made it to 2014 without that
option, especially since there already is 'session.referer_check'.

Yes, one can write a custom session handler, but there's a number of
problems with that:

 - Most people don't know enough to do it properly, more specifically - how
to handle concurrency.

 - The documentation available is pretty limited.

 - Unless I want another type of storage, why should I bother trying to
replicate ext/session just for this one option?

And of course, there are a few pre-made handlers in PECL, but those are
afaik no longer maintaned and not feasible if you'd be distributing your
end product instead of just running it yourself.

I'd write an RFC about it, but I know it doesn't stand a good chance
without a patch to go with it and I'm not comfortable enough with my C
knowledge to do it myself. It should be simple enough in theory though ...

 - Create an MD5 hash of REMOTE_ADDR and do one of these:

    - Prepend it to the session file name
    - Create a directory named after it under session.save_path
    - Have the option to specify it in session.save_path itself, like it's
done with N and MODE

It shouldn't cause any BC breaks and the only issue I can think of is loss
of existing sessions when the option is being turned On/Off. I wouldn't be
bothered by that really, it should be expected.

So, how do you guys feel about this? Would anybody be willing to write the
patch (I'll do the RFC)?

Cheers,
Andrey Andreev a.k.a. Narf.

--001a11394e6e08784c04f0c12860--