2

Is it possible to check if a certain session ID exists without starting a new one?

The reasons I'm asking this are:

  1. If every user not logged in visiting the site requires session_start(), soon the session folder will be bloated with unnecessary files (even with garbage collector cleaning up expired sessions).
    Of course this can be mitigated by destroying the sessions of such users. However, in this case, it seems there would be an overhead of creating and destroying files (unless PHP is smart enough to cancel these operations). Is this a bad practice?

  2. If the user is just a guest and doesn't require a session, there is no need to create one for him.

 

Ideal Solutions:

if( session_exist($_COOKIE['PHPSESSID']) )
{
    session_start();
}

Or:

session_start(RESUME_ONLY);

 


Follow-up

There is a PHP package that explains much better the aforementioned issue. Briefly, some interesting excerpts are:

Resuming A Session
[...]
You could start a new session yourself to repopulate $_SESSION, but that will incur a performance overhead if you don't actually need the session data. Similarly, there may be no need to start a session when there was no session previously (and thus no data to repopulate into $_SESSION). What we need is a way to start a session if one was started previously, but avoid starting a session if none was started previously.
[...]
If the cookie is not present, it will not start a session, and return to the calling code. This avoids starting a session when there is no $_SESSION data to be populated.
 
Source: Aura.Auth

 

Notes:

This question was initially posted as Checking for PHP session without starting one?.
However, IMO, none of the answers addressed properly the issue.

Mark Messa
  • 440
  • 4
  • 22
  • Using `isset()` - `!empty()` should suffice. – Funk Forty Niner Oct 24 '19 at 18:00
  • You mean `isset( $_COOKIE['PHPSESSID'] )` ? – Mark Messa Oct 24 '19 at 18:01
  • Either that or checking if a particular user's session is set already. However, I tend to think that I may not be fully grasping what it is you are asking for. – Funk Forty Niner Oct 24 '19 at 18:03
  • 1
    @FunkFortyNiner > _"Either that"_ The problem is that cookies are unreliable. The user can set any value he wants. Therefore, just because the cookie PHPSESSID exists doesn't mean that the session indeed exists. – Mark Messa Oct 24 '19 at 18:09
  • @FunkFortyNiner > _"or checking if a particular user's session is set already."_ Mind to explain? – Mark Messa Oct 24 '19 at 18:10
  • I wasn't referring to cookies but a session array, seeing you tagged as such. What I meant was something to the effect of `if(isset($_SESSION['user_var'])){...}`, or a combination of that with an `!empty()` type of thing and unsetting it if required. – Funk Forty Niner Oct 24 '19 at 18:13
  • @FunkFortyNiner > _"I wasn't referring to cookies but a session array"_ The problem of using `$_SESSION` is that you first need to use `session_start()`, which is what I'm trying to avoid in the first place as explained in the OP. – Mark Messa Oct 24 '19 at 18:22

1 Answers1

0

I think you are trying to solve the wrong problem here. To answer your question, no, you must use session_start before preforming session operations. You could also destroy the session if it isn't needed in the same request with session_destroy.

You can work around the session_start problem with some clever session storage options, but I think that is just the wrong answer to the problem you have. The size of sessions stored on the FS is really negligible when your servers installation footprint is at least 8GB. Furthermore, the default session storage location is /tmp which is commonly setup as a ramfs to avoid any disk overhead. If you are running into the limitations of FS session storage, you probably need to use a different SessionHandler like memcached, not worrying about if you need to start a session. On a related note, stop prematurely optimizing your code. Session storage is not going to be an issue until you need more than one server. In reality there are going to be many more database queries that would benefit from an additional index than obscure optimizations like this one.

Alex Barker
  • 4,316
  • 4
  • 28
  • 47
  • There is also the PHPSESSID cookie. A while ago, browsers used to popup a notification that the site wants to use cookies and asked the user for permission, which annoyed several users. Nowadays, is this still an issue? – Mark Messa Oct 24 '19 at 19:18
  • I have never seen that with the default settings in any browser. – Alex Barker Oct 24 '19 at 19:38
  • 1
    Ok, it seems like the impact of this optimization would be low. However, it still sounds weird to me starting a new session for all users visiting a page. The impact might be low, but it is still a waste of resources. An option like `session_start( RESUME_ONLY )` would solve that and doesn't seem much complicated. Now I'm wondering, why it hasn't been implemented yet? – Mark Messa Oct 24 '19 at 20:03
  • 1
    @Mark I agree that the server-side resource impact is negligible, and I also agree that from a REST perspective it would make absolute sense to keep the output as "clean" as possible. If the user isn't logged in and isn't visiting any resource that requires a session, returning a session cookie seems jucky. Alas with PHP's default session handling you simply don't have enough control over this; you'll have to write your own. – deceze Oct 25 '19 at 06:38
  • I just want to point out that if you are creating an API, session based authentication is probably the worst chose. Some type of token based authentication is going to be much easier to deal with. – Alex Barker Oct 28 '19 at 17:44