Cakephp Session error on live site - session

I am having issues with using the session component in cakephp.
They worked fine throughout the site, when on a dev site on a different server.
After uploading the final version on the new server, it seems that the session will not start in certain controllers. Only on two controllers is this happening, but nothing seems to be done differently on these controllers - except possibly the fact that only these two controllers are using a custom file uploader component. Have tried disabling this and nothing changed.
The website is an ecommerce system, with the problems mainly occuring when trying to add an item to the basket, which is stored in a session. this session is remaining blank, whereas on the dev site worked a charm.
I am also using the auth component to login/logout, and although these 2 areas are not required to be logged in to function, they cause it to switch to logged out whenever they are loaded - and this then switches back by itself when any other areas of the site are accessed. The auth and session components are loaded in the appcontroller.
Thanks!

I've had a similar problem before now, and for me I was under the same impression as #starlocke that something needed kick starting. Instead of using Cake's Session component I used the session_start() command, after checking that $_SESSION was not defined. For example:
if(!isset($_SESSION)) session_start();
This was placed inside the beforeFilter() method of the AppController class.
I then also had a problem where it was saying it couldn't start the session because of there already being output to the server, this was solved for me by deleting any closing ?> tags inside controllers, as these aren't required by php and stop any unneeded output being sent to the browser like in this case.
Further reading on php closing tags:
Why I don’t use closing PHP tags
PHP closing tag

My personal experiences have shown that CakePHP's sessions are independent of Apache+PHP sessions. With that in mind, it helps to take some action to always guarantee that a CakePHP Session (instead of the usual Apache+PHP session) is instantiated early in your website's workflow , for example, adding something like $this->Session->read('foo'); inside your site's AppController's beforeFilter(). It shouldn't matter what key you try to read, and 'foo' should be enough to start your CakePHP sessions.

Related

CakePHP session inside Joomla component

I'm writing a Joomla plugin, which is basically just a wrapper around an application written in CakePHP (version 3.3; not in a good position to upgrade this at the current moment). I'm running into various issues with session data.
First problem is that Cake's Request object creates a Session object, which does not allow for the possibility that the PHP session might already have been started; it throws an error in this case. (I see no changes in this area of the code in Cake v3.6.)
My original solution to this was to have my plugin code close the Joomla session before starting up Cake, and let Cake do its own thing with its own cookie and session table. But by doing this I lose any changes that Joomla might make to its session after my code runs, which isn't ideal.
Next attempt was to hack the Session class slightly (proof of concept; a proper implementation to be made without any core changes if it works) to allow setting the _started member to true before starting the dispatcher. This works, in that Cake and Joomla data are now saved together in the Joomla session table.
However, Cake's session data includes Auth.User, the record of the user currently logged in. That record includes objects of type Cake\I18n\FrozenDate. On any page load after this has been written into the session, that class is not yet available (Cake's autoloader hasn't run) when Joomla loads the session. So those fields come in as __PHP_Incomplete_Class, which then breaks other things.
My current solution to this is to reload the entire session at this point (session_reset), first copying any uncommitted changes Joomla has made to $_SESSION, then restoring them after the reset.
In limited testing so far, this seems to be working. But I'm wondering whether I've missed some obvious problem, or obvious easier solution. Any comments, suggestions, or thought-provoking questions much appreciated. :-)
For example, is there some way for me to run Cake's autoloader before Joomla initializes the session, without hacking the Joomla core at all? That could be a simpler solution.
If this turns out well, I'll see what I can do to make the code available.

Unable to clear cookies using browser.cookies.clear

I am unable to clear cookies using watir-webdriver and browser.cookies.clear
Are there any other alternatives ?
This is as far as I know a browser based limitation, due to concerns of security and privacy.
Webdriver is interacting with the browser by javascript, and javascript is not allowed to clear all cookies (think how nasty that could be on a malicious site). In the non testing env, most JS that is executing came from the server of the site you are accessing. So the most it is allowed to do is clear the cookies for the 'current domain' e.g. the cookies belonging to the current URL. So if a web page wants to clear all its own cookies, that is OK, but it is not allowed to clear cookies belonging to other domains.
So if you want all your tests to start with fresh cookies, you will need something in the 'Before' section in env.rb that goes to the root of the site in question, and then clears the cookies
BTW the same limitation applies to setting cookies, if you want to create cookies for a specific site, you need to navigate to that site before trying to create them, or nothing gets created.
This is not an answer, but FYI only.
Suppose chrome is the chosen browser, when cucumber is running, from the output of ps -ef | grep chrome we'll be able to find the customized user data directory which is something like below.
--user-data-dir=/tmp/.org.chromium.Chromium.G2DgPo
And inside that directory, we'll be able to find the Cookies file stored under the Default folder.
Not sure directly deleting that database file could fulfill the needs or not. Cause in a normal browser session, such runtime data are stored at
~/.config/google-chrome/Default/Cookies

use both regular(4kb) session and db session in one codeigniter app?

So I have a framework we've built on codeigniter. It uses regular codeigniter sessions by default which allows up to 4kb storage encrypted on a cookie.
Its for general apps that require a registration process, which can vary in size as questions are generated dynamically through an admin panel. Registration process relies on session data as it redirects throughout process.
I have used db_sessions in the past when I knew this would be an issue on the framework, however, I'm now considering the possibility to always have registration process using db_session and the rest of the site use the 4kb cookie session.
Is this possible. It seems like it could be a really bad idea, but I don't really want to rework the dynamic registration process or really use db_session for whole site as it will eventually make the site run very slow if too many users are online at once.
so I'm think I can just set the variable in config to be true only when the registration controller is loaded(by checking the url via $_SERVER or the uri helper if I can load it in the config which I'm guessing I cant).
Does this seem plausible?
It seems like it could be a really bad idea
You answered your own question :) You'll have issues when the user switches from one page to another. What happens if they open multiple windows, press a 'back' button etc. You'll need to switch the cookie over when they start registration, and switch it back at the end. It will be very very messy for basically no gain.
but I don't really want to rework the dynamic registration process or
really use db_session for whole site as it will eventually make the
site run very slow if too many users are online at once.
The reality is; your website has to be huge to have ANY real performance issues by using a DB for your sessions. Any if you are not using the DB, then you are relying on the cookie stored on the users computer. Depending on your site, this means they might have the ability to edit that cookie and change "admin = true" or something.
Just use the DB session - I think you are overcomplicating the situation.

Blank page on Azure

I have an application running in Azure (trial account). So far so good, everything has been nice, except for a long deploy times (10-15 minutes).
I've done a deploy recently and got a lot of weird bugs I cannot trace. For example, if I log in and thus a cookie is created (I use FormsAuthentication) all I get from the application is a blank page, as in, absolutely nothing is sent to the browser. The application works fine in the ASP.NET Web Dev Server, IIS Express, even the Azure Emulator!
What could be the issue? Searching the web hasn't been much help, with only a couple of unrelated issues.
I tried logging into the site (if I correctly understood from one if the comments, the url is versulo.com) and I didn't get any blank page with 404 status code.
However, there is another problem I spotted. Your site seems to be implementing caching inappropriately. The main page, the one from which you trigger the login and which is dynamic in nature contains an Expires header set at 5 minutes after the pages first load. That means that each call or redirect to that page within 5 minutes since it was first loaded, will be served from the browser's cache.
Because of that, after I login into your application I am redirected back to the home page which looks like I am not logged in. If I force a F5 refresh on the browser, then the page will indeed show me as logged in.
If instead of a refresh I try to login again (which is what I did in my first trials, since it looked like the login didn't work in the first time), I am getting an error page with the following message:
Sorry, there has been an error on the server.
500
The page looks like an application error page and even if it displays the 500 number, it is actually served with an HTTP 200.
So, while I am not 100% sure if this is also the cause of the problem described by you, you should remove the Expires headers from the dynamic pages your application is serving.
This can be because you're combining Forms Authentication with multiple instances. Are you using multiple instances? If that's the case, could you:
Try to change it to 1 instance. Does this fix the issue?
Try to make the following change to the web.config (configure machineKey): http://msdn.microsoft.com/en-us/library/ff649308.aspx
some partial views are not rendered at all;
Do you mean some pages are working fine, but others are not? It would be better if you can point out a pattern on what’s working and what’s not? For now, please make sure all referenced assemblies (except for default .NET assemblies and Windows Azure runtime) have Copy Local set to true. For example, MVC assemblies are considered as extensions to .NET, so please set Copy Local to true. In addition, you can also try to use Fiddler to monitor the requests to see what’s returned from the server.
Best Regards,
Ming Xu.
Could you provide a link to the application, or perhaps some source code?
When you say 'blank page', what is actually returned, a 404 / 500?
Have you inspected the IIS logs, or added some trace information to your code?
Have you tried accessing the service using it's ip address rather than domain name?

Prevent a session from expiring?

We have a simple CCTV system in our office that shows a live image from each of our security cameras. The CCTV system doesn't have an API or any method of extracting the live images. You can however view the image from another browser by creating a basic HTML page with the image link:
http://192.168.1.6/media/getimage_sid.php?sid=a09c4ecb72bade3802e7bf563b0d0bd6&card=1&camera=1&width=384&height=288
This works perfectly, until the session expires and/or timesout. I don't know very much about cookies and sessions but when I inspected the page in Google Chrome I noticed the following cookie:
Name Value Domain Path Expires Size
PHPSESSID a09c4ecb72bade3802e7bf563b0d0bd6 192.168.1.6 / Session 41
there is also a HTTP column and a Secure column but both are empty.
What I am trying to figure out, is how do I keep that cookie alive or trigger it to recreate with the same value? I'm assuming that a rake task to log in to the system wouldn't work because that would reset the session ID every time.
The intranet is a Rails application, so one way would be to create a script that logs in and stores the current session ID to the database and then putting the last recorded sessions ID into the IMG links from the database. It's a bit of a long way around though, I'm hoping for a better solution.
I have read a few articles showing how to do this with AJAX but that would appear to rely on the intranet being viewed all the time. I need this to work if no-one has viewed the intranet for the weekend.
This project is so we can put a couple of live (when the page refreshes!) images on our intranet so we don't have to continuously go to the CCTV system, log in and find the right camera just to see who is at the garage door etc.
Any help would be appreciated.
It's a bit of hack but I've made a small script to pull in the latest session ID and then put it into the image links.
A random different approach: does the following URL get the right image, without having to worry about the session id?
http://192.168.1.6/media/getimage_sid.php?card=1&camera=1&width=384&height=288
The session ID used in the cookie seems to be the PHP generated one.
I don't think session ID should become stale if you 'notify' the server that you're still online.1 You should try to specify the Cookie: in your HTTP request headers. Specifying the SID via the URL is probably not be enough to indicate to the server that you're actually using it.2
If your web-pages are fetching the images directly (i.e. you have an <img src="http://192.168.1.6/..."> in the HTML page) you might work like this:
make an AJAX request (XMLHttpRequest) to a URL which returns a session ID.
any subsequent request to the server on that page should automatically include the session in the headers.3
Otherwise, if you can't specify a Cookie: header, you may choose to make the time before a session becomes stale longer. If you have access to the computer hosting the PHP interface (192.168.1.6) then you can configure PHP to do so (via the php.ini configuration file, I believe). Information about session configuration is available here, and specifically the gc-maxlifetime options seems useful:
session.gc_maxlifetime specifies the number of seconds after which data will be seen as 'garbage' and potentially cleaned up. Garbage collection may occur during session start (depending on session.gc_probability and session.gc_divisor).
Alternatively, if none of the above appeal to you, your solution to fetch (GET) a page to obtain a valid, fresh session ID seems logical and good. You could optimize this by measuring how long it takes before session IDs become stale and fetching new session IDs only at that interval.
1 I looked for a valid reference for this but couldn't find one.
2 specifically PHP uses a PHPSESSID= token in the URL whereas in your example it looks like sid=. It is also generally considered bad practice security-wise I believe (this article explains how it might be used for XSS), since you're exposing user information in the URL, though I think this has little to no effect in this case
3 according to the XMLHttpRequest spec of the send() method:
If the user agent supports HTTP State Management it should persist, discard and send cookies

Resources