Session Questions

[mikey_w]

This past week I had a Zen moment, and now I’m not sure where to go.

What occurred to me is that how I program my websites is VERY dependent on there being a $_SESSION variable whether the user is a logged in member or just a visitor.

For instance, right or wrong, I use the session to pass error codes to my error-handling script.

And what I discovered while spending all week tracking down an error is that if a user blocks cookies then it also kills my ability to properly use the $_SESSION variable.

Right now I’m feeling really bummed because it is almost like everything I built is trashed.

Questions:
1.) What exactly happens to the $_SESSION variable if a user blocks cookies?

2.) Is my coding style/architecture fatally flawed being so reliant on $_SESSION?

3.) If were using OOP, could I create “persistence” via objects instead?

[s_molinari]

@mikey_w

1.) What exactly happens to the $_SESSION variable if a user blocks cookies?

The session cookie should only be needed for users who are logged in. It basically saves them from constantly logging in. In this day and age, it is ok to tell the user they need cookies turned on to use your site.

@mikey_w

2.) Is my coding style/architecture fatally flawed being so reliant on $_SESSION?

No, because you have to store the user’s “state” (logged in, remember me, etc.) somewhere. This is what session persistence is for and it is actually vital to a website with authentication. Otherwise, the user would have to log in for every page they visit, which would mean you would have no users.

@mikey_w

3.) If were using OOP, could I create “persistence” via objects instead?

No, OOP doesn’t give you the persistence of the session per se. It allows you to modularize your program and also allows you to work (more) abstractly to solve problems.

Scott

[felgall]

@mikey_w

1.) What exactly happens to the $_SESSION variable if a user blocks cookies?

If you add the following at the top of the script then sessions will be able to work without cookies.

ini_set("session.use_trans_sid",1);

[s_molinari]

Be aware, the solution from felgall also removes the use of cookies completely for sessions and always adds the session id to the end of urls making them ugly and in cases of a front end controller, a possible cause for errors.

Scott

[mikey_w]

@felgall

If you add the following at the top of the script then sessions will be able to work without cookies.

ini_set("session.use_trans_sid",1);

Thanks for the suggestion, Felgall, but according to PHPSecurity, this is a bad idea…

Security Implications
When use_trans_sid is enabled, PHP will pass the session ID via the URL. This makes it far easier for a malicious party to obtain an active session ID and hijack the session.

PhpSecInfo Test Information: use_trans_sid

[mikey_w]

I don’t feel like my OP was properly address.

I am still very worried that the way I coded my current - and other - websites is screwed up.

Could someone help me get a better grasp if the way I am so dependent on sessions is a fatal design?

It sure seems like there must be a better way…

[fretburner]

@mikey_w

Could someone help me get a better grasp if the way I am so dependent on sessions is a fatal design?

Basically, no, it’s not a design flaw. Sessions are used in the majority of website log-in systems. In the situation where a user has disabled cookies, there isn’t really a secure alternative… they just won’t be able to use your site (or Facebook, or Gmail, or Discourse, etc.)

[mikey_w]

@fretburner

@mikey_w

Could someone help me get a better grasp if the way I am so dependent on sessions is a fatal design?

Basically, no, it’s not a design flaw. Sessions are used in the majority of website log-in systems. In the situation where a user has disabled cookies, there isn’t really a secure alternative… they just won’t be able to use your site (or Facebook, or Gmail, or Discourse, etc.)

Okay, BUT…

What makes my situation worse is that I use Sessions to pass error-codes from each script to a centralized error-handling script, so if Joe Blow is a new visitor to my website and is surfing around, and any error happens (e.g. database won’t load a list of products) he would get a “Page Not Found” error which would lead to lots of confusion.

What I realized is that this impacts non-members, and that is why it seems so “fatal”.

Make sense?

So I was wondering if I was using OOP - or something else - if I could somehow pass data back and forth between objects and use that approach to replace my dependence on sessions?

BTW, I thought maybe the solution was using Includes where I would just “include” my error-handling script and then I wouldn’t need to use sessions. But the problem is that my error-handling script also includes the page layout, so including page-B into page-A wouldn’t make sense.

Suggestions on a better design?

[felgall]

@mikey_w

So I was wondering if I was using OOP - or something else

What you use to code the pages makes no difference since the individual units as far as sessions are concerned are pages. The only way to reduce the dependency on sessions is to include the code directly in all the pages where it can run without having to load a new page.

[mikey_w]

@felgall

@mikey_w

So I was wondering if I was using OOP - or something else

What you use to code the pages makes no difference since the individual units as far as sessions are concerned are pages. The only way to reduce the dependency on sessions is to include the code directly in all the pages where it can run without having to load a new page.

So there is no way to share data between pages using objects?

If I knew MVC would it maybe help?

As mentioned above, the way I have things now - for example - is I have a “update-profile.php” script and then a “errors.php” script. Because I’m not sophisticated like you guys, the first script has PHP and HTML for displaying the “Update Your Profile” page and then the second script has PHP and HTML for display customized errors.

The way I have things, if I included “errors.php” into “update-profile.php” it would allow me to pass error codes thrown in “update-profile.php” to my code in “errors.php”, but it would break the display since I would have the HTML from both files being combined!

I don’t mind using Sessions for logged in members, but if my website won’t work for non-members that block cookies I think that would make my website all but unusable.

(Personally I have FireFox set to ask me if I want to allow cookies for every site, and unless I know I need to log in, the first thing I do on every new site is block the cookies!)

[oddz]

@s_molinari

No, because you have to store the user’s “state” (logged in, remember me, etc.) somewhere. This is what session persistence is for and it is actually vital to a website with authentication. Otherwise, the user would have to log in for every page they visit, which would mean you would have no users.

That isn’t completely true. A stateless application could be created passing a json web token. Any state based activity would than be stored in persistent storage. The data would be repopulated when passing in the proper json web token which is associated with the given data through a user account for instance. In this scenario one would be replacing the session id in requests with a json web token which is *completely secure (based on the modern limits of encryption breaking methodologies). Taking this further one could rewrite the session data to the db and repopulate it when a matching JWT is passed via the the request.

[John_Betong]

@mikey_w

So there is no way to share data between pages using objects?

If a user does not want to use sessions check $_SERVER and see if there are any user unique parameters that could be used to store a user filename containing session equivalent variables.

[felgall]

@oddz

A stateless application could be created passing a json web token

The it isn’t stateless as the state is maintained by the json token

[s_molinari]

@oddz

That isn’t completely true.

JWT is also used for session persistence, which is exactly what you explained. So, I don’t know how that makes my statement “not completely true”. The fact there are other methods doesn’t make my statement not true. The OP is very much correct to use (some form of) a session for user state persistence. The question wasn’t, am I wrong for using cookie sessions or should I use some other method. The question was about storing sessions in general. The fact there are other methods is another good point.

This article does a good job on explaining the differences.

https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Scott

[fretburner]

@mikey_w

The way I have things, if I included “errors.php” into “update-profile.php” it would allow me to pass error codes thrown in “update-profile.php” to my code in “errors.php”, but it would break the display since I would have the HTML from both files being combined!

If you’re willing to change your code to avoid using sessions, why not just change this so that you can include errors.php when you need to output form errors?

Another solution that might work for you is passing the errors in the URL… it’s not pretty, but it avoids relying on sessions.

[mikey_w]

@fretburner

If you’re willing to change your code to avoid using sessions, why not just change this so that you can include errors.php when you need to output form errors?

First, I don’t want to eliminate Session use for logged in users. But I think my website is poorly designed if having a non-member block cookies will screw up how my error handler works. (Thumbs down for me!)

As to your comments above, I don’t think we understand one another.

Let me explain again…

First, I have a script called “errors.php” which is in change of displaying a customized error page for every error in my website.

When a given script (e.g. update-email.php) has some error (e.g. “Email not found in database”), then it places the Error Code in $_SESSION and redirects to “errors.php” which then finds the corresponding Error Code and displays my Error Page template with the appropriate HTML.

Follow?

It seemed like a good idea when I created it years ago. However, the problem that I discovered last weekend is that if a user blocks cookies, then $_SESSION[‘error_code’] is always NULL and so “errors.php” always defaults to a generic catchall error since it can’t figure out what the Error Code is?!

That was a gigantic miscalculation on my behalf!!

In another thread on SP, I am trying to learn how to use JavaScript to check if the user blocked cookies, but even if I learn how to do that, it still doesn’t leave me much of an option because if cookies are blocked then it breaks my error-handling.

I am hoping that there are some ways I could re-architect my website going forward so that I am not dependent on Cookies or Sessions to display errors or my customized error page.

Now, by contrast, if a user is a member, and he/she blocks cookies and then can’t log in, well tough for them. But for visitors, it seems rather self-righteous on my part to demand they enable cookies just to surf my website!!

(When other websites demand that I enable cookies to surf their site I just leave!!)

Does that make more sense?

@fretburner

Another solution that might work for you is passing the errors in the URL… it’s not pretty, but it avoids relying on sessions.

Nah, I don’t like that for security reasons and aesthetics.

[fretburner]

@mikey_w

When a given script (e.g. update-email.php) has some error (e.g. “Email not found in database”), then it places the Error Code in $_SESSION and redirects to “errors.php” which then finds the corresponding Error Code and displays my Error Page template with the appropriate HTML.

If you’re using error codes to determine which message to display, then putting it in the URL shouldn’t be untidy, i.e www.mysite.com/errors.php?code=404. If you still think that’s too ugly (I can’t see any possible security issue with it), then another option is to display your error page in place of the usual page content when an error is detected. In pseudo code:

check form submission
if errors:
    set $error_code variable
    include error script that formats/displays error message
else:
    display success message / redirect / etc.

@mikey_w

That was a gigantic miscalculation on my behalf!!

I really think you’re overstating the case here. A small minority of people disable cookies. It’s extremely common practice to use sessions to persist user state between requests (read pages)… users who choose to disable cookies for a site have to expect that sites with some sort of interactivity might not function as intended.

@mikey_w

I am trying to learn how to use JavaScript to check if the user blocked cookies

And what if the user has JS disabled?

[Mittineague]

@fretburner

A small minority of people disable cookies

Yes, I think this is correct. More may disallow third party cookies, and even more may clear cookies upon browser close, but I think the vast majority allow them.

[mikey_w]

@fretburner

If you’re using error codes to determine which message to display, then putting it in the URL shouldn’t be untidy, i.e www.mysite.com/errors.php?code=404. If you still think that’s too ugly (I can’t see any possible security issue with it), then another option is to display your error page in place of the usual page content when an error is detected. In pseudo code:

I slept on it and it’s a possibility.

As far as security, I guess I don’t want hackers trying code=404, 405, 406…

@fretburner

check form submission
if errors:
set $error_code variable
include error script that formats/displays error message
else:
display success message / redirect / etc.

I think if I really understood MVC it might help here…

@fretburner

I really think you’re overstating the case here. A small minority of people disable cookies.

I guess I am in the minority again!

@fretburner

It’s extremely common practice to use sessions to persist user state between requests (read pages)… users who choose to disable cookies for a site have to expect that sites with some sort of interactivity might not function as intended.

True. And in fairness, blocked cookies wouldn’t break my site to the user as much as make my life hell because any page errors would never get logged and always show up as my catchall error as explained above. (Of course, my websire shouldn’t have many errors!)

@fretburner

And what if the user has JS disabled?

Very true!

[mikey_w]

@Mittineague

@fretburner

A small minority of people disable cookies

Yes, I think this is correct. More may disallow third party cookies, and even more may clear cookies upon browser close, but I think the vast majority allow them.

So what’s your take on my dilemma?

Do I have a really weak website design?

Could MVC help solve this issue of separating which page is served up (i.e. normal page or error page) from the same script?

Could OOP help me better organize things?

Some other solution?