Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73232
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZzRZSRH3LWQqL=mik1KJ8i=19QNatFPoK7TXZMru5SKZA@mail.gmail.com>
References: <CAPhkiZzAxQnQpWOh7xhAM4h3r7xCYjD_P3d9mWmDX4Sr0Qc9Ng@mail.gmail.com>
 <CAGa2bXZHYJzcV2E-SDN7-u1_SLrW8Tr7hwkQG5JSnD-7oh-Xvg@mail.gmail.com> <CAPhkiZzRZSRH3LWQqL=mik1KJ8i=19QNatFPoK7TXZMru5SKZA@mail.gmail.com>
Date: Tue, 18 Mar 2014 06:09:10 +0900
Message-ID: <CAGa2bXaGRk0PipbF_DYSgcPNwLvs=8nb8yHG9XFawrNFUVmdyQ@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c33ef21601d704f4d3d709
Subject: Re: [PHP-DEV] Session: deprecating create_sid() method and add createSid()?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c33ef21601d704f4d3d709
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

On Mon, Mar 17, 2014 at 8:10 PM, Andrey Andreev <narf@devilix.net> wrote:

> On Mon, Mar 17, 2014 at 12:51 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > Hi Andrey,
> >
> > On Mon, Mar 17, 2014 at 7:23 PM, Andrey Andreev <narf@devilix.net>
> wrote:
> >>
> >> There's no SessionHandler::create_sid() or
> >> SessionHandlerInterface::create_sid() documented (see your own link to
> >> the docs) ... since when is this available?
> >>
> >> I'm not sure if exposing it is a good idea anyway, why is it necessary?
> >
> >
> > This change is not mine. It was added about 10 years ago, IIRC.
>
> And for 10 years is has not been documented? Really, are you sure that
> it is exposed to userland at all?
>

It may be, but chances are rare. I suppose.
Nobody is using it actually. This would be the reason why it is not
documented
for a long time.

> Having createSid() could be useful. For example, user may have certain
> > prefix for session
> > IDs. User ID prefix is especially useful to know how many active sessions
> > are there.
> > (Note: I advise to use MD5('user_id'.'random_secret') for user ID
> prefixing
> > if user_id
> >  shouldn't be exposed.)
>
> Surely that prefix can just be prepended to the $session_id that gets
> passed to read(), write(), destroy() methods. This argument was given
> to me when I proposed a session.match_ip feature. Why not add this as
> an option to session_start()? Example:
>
> session_start(['id_prefix' => 'foo_']);
>
> (could be an ini setting, for optimization purposes)
>

It could be easier with save handler. Users may register handler like

function session_create_sid( args here ) {
  if (!empty($_SESSION['user_id'])) {
     return create_session_id(md5($_SESSION['user_id']));
  } else {
     return create_session_id();
  }
}

then they may call

session_regenerate_id()

to get prefixed session ID.


>
> > I've added session_create_id(). Therefore, if user start using it, it
> does
> > not hart much.
> > If users do not need modified session ID, they may call
> session_create_id()
> > simply.
>
> Again with the "I've added this", that I opposed previously for
> session_serializer_name(), session_gc() ... What's session_create_id()
> useful for? How would you utilize it?
>

You are asking to write RFC for all additions for _new_ release.

I think session_gc() is must have API. IMHO.
Periodic GC is better than probability based GC even with expire timestamp
(I mean
time stamp for session manager, not save handlers)


>
> > The reason why this is added is Stefan Esser's strict session patch had
> > this, I guess.
> > However, his patch was not fully merged and session remained weak until
> > 'use_strice_mode'
> > patch.
>
> Now I'm confused ... is it added to the core, or just supported as a
> part of the suhosin extension and/or hardening patch?


Stefan proposed strict session patch and it wasn't merged fully. That's all.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c33ef21601d704f4d3d709--