Bug Report #4313
Kohana_Session throws exception when session_start was already called
| Status: | Closed | Start date: | 10/22/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | % Done: | 0% |
||
| Category: | Core | |||
| Target version: | - | |||
| Resolution: | wontfix | Points: | 1 |
Description
system/classes/kohana/session/native.php
function _read
we've got there
session_start();
so when we have some module or other third party code, which calls session_start() by itself, not relying on kohana Session::instance()
we have a trouble:
native::_read throws exception,
Session::read rethrows exception
when session is constructed, it call's $this->read, so it throws exception about session being corrupt.
however this is just because session_start was already called.
i think that we can make some additional check not to throw exception (which is just notice)
smth like
if(!session_id()){
session_start();
}
History
Updated by Dmitry Selin 7 months ago
kohana 3.2 last stable
Updated by Woody Gilk 4 months ago
- Category set to Core
- Status changed from New to Closed
- Assignee set to Woody Gilk
- Resolution set to wontfix
Kohana uses session_set_cookie_params and other functions before starting session that are required for things to work reliably. If you are running into this error, you will have to handle it manually.
Updated by Dmitry Selin 4 months ago
hey, but i suggested fix .
with check of session_id()
so we can conditionally run session_start().
in such way everything is reliable.
in other case, any external api (like facebook api) which uses its own call for session_start causes the whole site no to work (which is unreliable).
i don't want to change facebook api php class (as i should do it on every update of api)
the only way to make everything work is calling Session::Instance() prior to including facebook api php-class.
but this is also ugly and unreliable!!!
Updated by Woody Gilk 4 months ago
Your suggested fix is not reliable at all. As I mentioned before, we must use session_set_cookie_params before starting the session.
Updated by Woody Gilk 4 months ago
Dmitry Selin wrote:
the only way to make everything work is calling Session::Instance() prior to including facebook api php-class.
And that is what you should do. Kohana's sessions do more than just start a session.
Updated by Dmitry Selin 4 months ago
in such case.. may be it would be better to automatically start session from bootstrap or some core class?
or have some switch for this. almost everybody uses Sessions in their applications, so it wouldn't be a great overhead always start session .
Updated by Woody Gilk 4 months ago
If you need sessions always running, then yes, you should always start it in boostrap. Your "bug" only applies to your specific situation, not the framework as a whole.
Updated by Dmitry Selin 4 months ago
this "specific" situation will become more common, when people will begin to use more external libraries and classes with its own session handling(facebook api, openid api are only few examples) .
so this "bug" will appear more often.
if you don't want to change anything in bootstrap or Kohana_Session, may be it would be possible at least change exception string, adding there something "this exception may be fired because 'session_start' was already called"
so that when somebody will have same "bug", he will not need to make extensive debug but have information about the problem at once from exception description.
Updated by Dmitry Selin 4 months ago
and it also could be useful to add some info to documentation about kohana_session. saying that kohana sessions should be instantiated before any other [external] code could call session_start()
Updated by Zvi Shteingart 4 months ago
I spend a couple of hours on this issue too. It is not straight-forward from the bug that Session::Instance() must be called prior to session_init().
Maybe this can be a good solution:
if(!session_id()){
throw new Kohana_Exception('Session should not be started outside the Kohana framework');
}
session_start();
Regards`
Updated by Dmitry Selin 4 months ago
nice. i think such exception is better than existing one. it cleares out the reason of exception.