Hi all,
This was discussed before.
I've created RFC for more discussion.
https://wiki.php.net/rfc/session-lock-ini
Please comment if any.
Thank you.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
This was discussed before.
I've created RFC for more discussion.https://wiki.php.net/rfc/session-lock-ini
Please comment if any.
I would like to setup vote for this RFC soon.
(Hopefully, prepare the patch soon)
Most issues are already discussed. If you have comments, please
send mail. Especially, if you have better INI names, I appreciate it.
Thank you.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
This was discussed before.
I've created RFC for more discussion.https://wiki.php.net/rfc/session-lock-ini
Please comment if any.
I've added session_discard() to RFC that discards changes made to
session data and close session.
Since there is session_commit(),
http://www.php.net/manual/en/function.session-commit.php
session_abort() may be better name for it.
Any comment?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I've added session_discard() to RFC that discards changes made to
session data and close session.Since there is
session_commit(),http://www.php.net/manual/en/function.session-commit.php
session_abort()may be better name for it.
Any comment?
Since session_commit() is an alias for session_write_close(), the new
function should probably also have "close" in its name (although oddly
we "start" a session, rather than "open" it).
Both "discard" and "abort" also sound a bit like destroying the session
itself to me, rather than just ignoring the current changes to it.
Perhaps something like session_revert_close() - "revert" being a closely
analagous action in version control systems.
Regards,
--
Rowan Collins
[IMSoP]
Hi all,
On Fri, Jan 3, 2014 at 11:23 AM, Rowan Collins rowan.collins@gmail.comwrote:
I've added session_discard() to RFC that discards changes made to
session data and close session.Since there is
session_commit(),http://www.php.net/manual/en/function.session-commit.php
session_abort()may be better name for it.
Any comment?Since
session_commit()is an alias forsession_write_close(), the new
function should probably also have "close" in its name (although oddly we
"start" a session, rather than "open" it).Both "discard" and "abort" also sound a bit like destroying the session
itself to me, rather than just ignoring the current changes to it.Perhaps something like session_revert_close() - "revert" being a closely
analagous action in version control systems.
session_revert_close() sounds reasonable if session_write_close() is main
function.
Rather than session_start(), session_open() would be better name, since
there is session_write_close().
IIRC, session_write_close() was considered odd name and session_commit() is
made as alias of it later. Expect-able/consistent function names may be
better as main function and document them for new release. We should be
careful not to have too many aliases, though.
Main functions
session_start() (or session_open()?)
session_write_close()
session_revert_close()
Aliases
session_open() (or session_start()?)
session_commit()
session_abort()
Introducing session_revert_close() only seems good to me, but I don't mind
to have session_open()/session_abort() at all. Any comments?
Choosing good names is difficult ;-)
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
On Fri, Jan 3, 2014 at 11:23 AM, Rowan Collins rowan.collins@gmail.comwrote:
I've added session_discard() to RFC that discards changes made to
session data and close session.Since there is
session_commit(),http://www.php.net/manual/en/function.session-commit.php
session_abort()may be better name for it.
Any comment?Since
session_commit()is an alias forsession_write_close(), the new
function should probably also have "close" in its name (although oddly we
"start" a session, rather than "open" it).Both "discard" and "abort" also sound a bit like destroying the session
itself to me, rather than just ignoring the current changes to it.Perhaps something like session_revert_close() - "revert" being a closely
analagous action in version control systems.session_revert_close() sounds reasonable if
session_write_close()is main
function.
Rather thansession_start(), session_open() would be better name, since
there issession_write_close().IIRC,
session_write_close()was considered odd name andsession_commit()
is made as alias of it later. Expect-able/consistent function names may be
better as main function and document them for new release. We should be
careful not to have too many aliases, though.Main functions
session_start()(or session_open()?)
session_write_close()
session_revert_close()Aliases
session_open() (or
session_start()?)
session_commit()
session_abort()Introducing session_revert_close() only seems good to me, but I don't mind
to have session_open()/session_abort() at all. Any comments?
Choosing good names is difficult ;-)
BTW, I'm not the one who named session_write_close()/session_commit().
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
While I agree with the rationale for wanting more advanced behaviour
from the session management functionality in PHP, I don't think adding
more functionality to the built in session_* functions will give a
result that is satisfactory.
The problem is that most of the information about how the sessions
should be managed lives at the application level. It will also vary
within an application depending on what the user is doing. Some
examples, from the RFC:
Session locking - If an application knows that it won't be writing any
data to the session, it should be able to read the session data
without ever locking the session data.
There are also session write operations that just don't need any
locking at all. For example if you want to just record the number of
pages a user has viewed since they logged in:
$_SESSION['pagesViewed']++;
With a Redis storage backend for the session data, this can be done
without any locking at all, if the application is written without
assuming that the session data will be locked.
Race condition around regenerated session IDs - The proposal to allow
clients that try to use a session ID that has recently been
regenerated would not be acceptable for all clients. Some clients
would probably prefer to send a HTTP error code (419 Authentication
Timeout?) indicating that the client should resend the request with
the new session ID.
It's also likely that applications would want to allow recently
regenerated session IDs to be allowed for read operations, but not for
write operations.
The previous discussions about improving security for sessions are
another example of where the logic isn't simple and what exactly
happens when the client changes either I.P. address or useragent
during a session is totally dependent on the application.
i.e. for a banking application, if the user ever changes IP address,
then it would be acceptable to instantly terminate that session.
For a shopping application, if the user changes IP address to one that
is within a close geographical aread as the original IP address, then
the application could let that session continue, and only terminate
the session if the new IP address appeared to be physically far away
from the original IP adress.
Also there are already 26 ini settings for handling the sessions in
PHP (ignoring the ini settings related to tracking upload progress).
This a pretty clear indication that the handling of sessions is
already too complex to be controlled through ini settings alone.
At the risk of setting myself up for a fall, I'm going to make a proof
of concept userland session manager to try and implement as many of
the features under discussion in the various session related RFCs that
are open as possible, and will try to publish it in a week or so. It
probably won't be anywhere near production ready, but hopefully will
provide a basis for discussing moving the session handling from the
session_* functions to something that allows people to define the
logic in code, rather than being forced to tweak a huge number of
config settings.
cheers
Dan
Hi all,
This was discussed before.
I've created RFC for more discussion.https://wiki.php.net/rfc/session-lock-ini
Please comment if any.
Thank you.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Dan,
At the risk of setting myself up for a fall, I'm going to make a proof
of concept userland session manager to try and implement as many of
the features under discussion in the various session related RFCs that
are open as possible, and will try to publish it in a week or so. It
probably won't be anywhere near production ready, but hopefully will
provide a basis for discussing moving the session handling from the
session_* functions to something that allows people to define the
logic in code, rather than being forced to tweak a huge number of
config settings.
I would like to write patch for this RFC now.
Do you have any date for your patch? (PHP script?)
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net