0

I am using CakePHP (v 1.3), and the Auth component. Right now all the cookies are not in snyc between HTTP and HTTPS.

For example, a user can be logged in on HTTP and not logged in on HTTPS or even worse user A can be logged in on HTTP and user B can be logged in on HTTPS.

This is happening for other things as well (like items in cart)

I have no idea what is going on or how to fix it.

What do I need to do so that they have the same cookies on HTTP and HTTPS?

JD Isaacks
  • 56,088
  • 93
  • 276
  • 422

2 Answers2

0

This is probably caused by secure cookies, which are sent only when page is accessed over https. If page is accessed over https, CakePHP sets session.cookie_secure automatically.

To disable this behaviour, change ini_set('session.cookie_secure', 1); to ini_set('session.cookie_secure', 0); inside cake\libs\cake_session.php

I would recommend to deal with it at the application side and allow logging in (and all member pages) only over https.

Petr
  • 3,214
  • 18
  • 21
  • I am already doing this though, for all user pages in my beforeRender() if the page is http it redirects to https. So I am not sure what to do. – JD Isaacks Oct 28 '11 at 14:45
  • Try to do what is recommended in the accepted answer here: http://stackoverflow.com/questions/308659/session-not-saving-when-moving-from-ssl-to-non-ssl – Petr Oct 28 '11 at 14:56
  • thanks for pointing me there. I am trying confirm that it fixes the issue. :) – JD Isaacks Oct 28 '11 at 16:15
0

Modifying the core code is most of the time a bad thing and in your case, there is a possibility to do what you need, but the Cake way.

In app/config/core.php: modify the Session.save value

//Configure::write('Session.save', 'php');

//this will look for a 'mysession.php' file in app/config
Configure::write('Session.save', 'mysession');

In app/config: create a mysession.php file with the parameters you want for your session

ini_set('session.use_trans_sid', 0);
ini_set('session.name', Configure::read('Session.cookie'));
ini_set('session.cookie_lifetime', $this->cookieLifeTime); 
ini_set('session.cookie_path', $this->path);

//overwrite Cake setting already set by CakeSession 
ini_set('session.cookie_secure', 0);

Also be aware that if you set your cookies to be not secure, most of the benefit of using HTTPS is gone, because as the same session cookie is used for HTTPS and HTTP, it becomes easy to steal it and then to steal the session for HTTPS as well.

I had the case of a webapp with an admin part over HTTPS and a public part over HTTP that required session as well. I manage to separate both parts by specifying two different cookie names:

In app_controller.php:

if(env('HTTPS')
{
    Configure::write('Session.save', Configure::read('Session.save') . '_https');
}

And in app/config, create another file called *mysession_https.php* with 

ini_set('session.use_trans_sid', 0);
ini_set('session.name', Configure::read('Session.cookie') . 'S');

//cookie destroyed when users close their browser 
ini_set('session.cookie_lifetime', 0); 

ini_set('session.cookie_path', $this->path);

ini_set('session.cookie_secure', 1);

This creates two different sessions, one over HTTP and one over HTTPS, but in my case it was fine, since all sensitive or private data are over HTTPS and the part over HTTP requires a session only to get a smoother navigation.

nIcO
  • 5,001
  • 24
  • 36
  • Will they be able to see their https cookie on http? For example I do not want to show them their profile info over http, however if they are logged in, then I dont want to show a "login" link on http but instead a "my account" link. – JD Isaacks Nov 01 '11 at 13:18
  • Nope. A secure cookie is never sent to an http url to prevent its unsecure transfer. To do what you want you could maybe redirect the user just after a successful login to a special http page that would only be useful to set a http session variable to indicate the user is logged in. And use the same idea to remove this variable when a user logs out. But I'm not sure if the browser would complain if it gets a location header redirecting from https to http. – nIcO Nov 01 '11 at 21:07