Using codeigniter running locally on WAMP and dealing with sessions. I tried the default session handler, db session, native session and now db session. They all result in the same issue and I can't for the life of me figure it out.
The problem is that I am trying to set a session variable using a variable. I have confirmed the variable and have echoed it out and all is well in the controller. The controller calls on a view and the variable is there as well. The view calls on a uploader file and this is where the variable randomly gets set to "style.css" for some reason. If I set the session statically, say to "randyval", then it sticks. It's only when trying to use a variable that it breaks.
Using db session allows me to set using:
$some_val = $some_otherVal;
$_SESSION['sess'] = $some_val;
Only in the final page does echo $_SESSION['sess'] result in "style.css".
If however I do:
$_SESSION['sess'] = 'test';
Everything works as should.
Wouldn't ask unless I was at my wits ends... thanks for any input.
Color me stupid. :\ Turns out there was some bad html that was causing the problem(?). It had to do with, yeah, you guessed it, the header and more specifically where the "style.css" file was being called. Not sure why that was wrecking the session, but it indeed was. So, sorry for wasting everyones time, you can go home now.
You should work with CI sessions using Session Class
For any of you who stumbled upon this page, see here for the solution :
I solved it this way : Losing a session variable between one page with codeigniter session library
Related
I am going crazy and need some tips and help. Working with custom cms and php programming language. I am working on online site on server.
Problem is next:
Session start is ok, In functions.php I start session['lng'] and put _LNG constant in it and it's ok, passing alright.
When I call session['lng'] in my other files I always get the same language constant (en) but I am passing (hr) or (de)?? I checked 10 time if session is set somewhere else but it isn't.
How can I check where's the problem...I really don't know what to do next
Did you place this at the start of other files before accessing session variables. It's required to access session vars.
<?php
session_start();
As silly as it sounds, I'm baffled by this behavior:
In my PHP code I am calling session_start(); before anything else (not even a space before it is called). I can test this by setting a session variable and then echoing said variable.
If I run the following code on one of my pages I get an expected session ID back, but if I run it on one of post pages used for ajax then it comes up empty. Only sessions that I set on the ajax post page specifically can be seen, not session variables set from another page.
$a = session_id();
var_dump($a);
I know I'm going to get responses telling me to make sure my session_start(); has been called from the beginning, but I swear up and down it is (if it wasn't, sessions wouldn't work locally on that page).
What in the world could be causing this strange behavior?
FWIW, adding ini_set('display_errors', 1); error_reporting(E_ALL); doesn't give me any info other than telling me I have an undefined variable when trying to dump a session var that was set from another page.
How do you navigate between the pages? If you're using header, the session data isn't always written before leaving the first page. I had to use
session_write_close();
header('Location: page2.php');
If you say that session_start() is implemented correctly and $a shows on some pages but not on specific pages, I would say it is most likely because session variables are super global and maybe on those pages you have a global variable $a.
This ended up being caused by my /tmp partition being full. I have a headless dropbox installation on this server and it decided to update itself overnight last night to a new version and not clean up behind itself. I should have gotten a notification that the /tmp partition was full but I did not for some reason so I didn't even think about it being the cause.
Let this be a warning to others who find they have the same problem I did. I'm still not entirely sure why I was able to set a new session variable on the problem page or even set the session vars for the other pages to begin with if the /tmp was full.
I appreciate everyone's willingness to help out though!
I´m having some serious trouble debugging this particular problem and I hope someone has a clue what i´m doing wrong.
I have a Custom CMS system working that uses Paragraphs as building blocks that get updated using Ajax(prototypejs) calls and functions that parse the HTML chunks in given order, clean them up and save this data in associative arrays in a Session variable.
Users log in, Session is created and I can check for this session without problem in every page I need it. The system works directly on the definitive websites, so the user can see his updates on realtime and browse the site as a normal user would do, but editing.
So, nothing new here. But here is the weird thing.
Enduser site on edit mode(admin user logged in): path "/"
After the logged status is verified, a function processes the editable content and saves an associative array to session, it also starts some javascript objects for editing every paragraph. Data is actually saved, I can use an external script to check if it´s there after this php script ends.If I load a new page(new content), Session gets updated with new data)
Admin User modifies a paragraph using an Inplaceeditor and this HTML chunk is send via Ajax to a php script that starts the named session, reads the present session data, checks if a paragraph should be modified, appended or deleted and reassigns values to existing array keys in $_SESSION. if i make a var_dump() o print_r to $_SESSION after assigning new data is there.After that the script echoes the processed html, and ajax updates the original paragraph on the calling page.
This script is in /admin/cms/...etc, that means at least 4 directories inside the root of the site.
When the script ends, I check using the same session dump script to see if data was really written/commited, but no, $_SESSION has only the original data from the calling page.
Same ID, same session name, same session_start() but no data gets written.
This whole operation is very quick, so I though it could be a speed problem, scripts ends before session_write_close can make his work.
But if I add a new key to $_SESSION array and put some data there, data gets updated and written. If i don´t output anything on this script and just process data and set session variables it also get´s updated and written.
It´s like some members of $_SESSION array are getting blocked to update.
What i did to track this error and what i´m sure i´m not doing wrong.
1.- register_globals are off of course
2.- session_name() and session_start() are always present and in the given
order. I used to have multiple
session_start() -close on a same page
to use several named sessions, but to
refine the problem this is not longer
so.
3.- I use session_write_close() after session data is processed. Also
tried without, letting php decide
when to commit data, but no luck.
4.- I`m using only cookies for SID.
5.- sessions are stored on /tmp, i can see the data getting updated.
I also tried using a custom save
handler on DB, but same problem,
"_write" got only called when no output as present.
I searched php.net, stackoverflow, google, etc for this subject. I never ask without investigation, this is my first time in many years...but it´s just so unlogical it must be something tiny a haven´t thought of.
The most weird thing is that when I just process data without output $_SESSION gets updated ok. But if i modify this script afterwards by adding the output and try again, instead of just having the new(last) value present I get the original value back, the one created by the calling page at first place, sometimes after playing around a few times! PHP can´t cache values between scripts or?I dont have globlals on.
I´m really clueless. This system worked flawless on PHP4.3, since i´m using 5.3.3 for two moths my users where caliming data where getting mixed up, so i checked and yes, there are serious problems. Today I updated to (5.3.6) and I can´t get this session values commited.
Script code called via Ajax:
<?
session_cache_limiter('nocache');
session_name("CMS_ses");
session_start();
include('../htmLawed/htmLawed.php');
include("utils_cms.php");
include("../../../php/utils_array.php");
$value=$_POST['value'];
$editorId=$_POST['editorId'];
$clase=$_POST['clase'];
$editorId=str_replace("pre","",$editorId);
$value=html_entity_decode(stripslashes($value),ENT_QUOTES);
if (strlen(trim($value))==0)
{
die();
}
$value="<div id=\"$editorId\" class=\"$clase\">$value</div>";
$newXHTML=$value;
$retorno=CMS_nuevoBloque($newXHTML,$editorId);
$_SESSION['data']['CMSeditores']=$retorno[1];
$_SESSION['data']['CMScont']=$retorno[2];
session_write_close();
print_r($retorno[0]); //Offending part...without everything works
?>
really nothing strange here....main page code is even simpler, no strange php directives, etc.
Here is the header of the caller page
include 'php/db.php';
$len=$_GET['len'];
$sec=$_GET['sec'];
$cont=$_GET['cont'];
$admfin=$_GET['admfin'];
$fecha=$_GET['fecha'];
$token=$_GET['token'];
$cur=$_GET['cur'];
$PHP_SELF=$_SERVER['PHP_SELF'];
session_cache_limiter('nocache');
session_name("CMS_ses");
session_start();
$passvar='';
unset($adm);
if ((!empty($_SESSION['cms_logged'])) and (!isset($admfin)) )
{
$nivelpermisos=$_SESSION['cms_logged_group'];
$useractual=$_SESSION['cms_logged'];
$adm=1;
}
elseif (empty($_SESSION['cms_logged']))
{
unset($useractual);
}
//.........rest of the code
UPDATE: I did late night tests and found someting i don´t understand.HElP please:
It has not only to do with Sessions but also with Mysql Querys. Same code, but instead of trying to write to $_SESSION array i made a simple update to a Innodb table using the session_id. When i Output some code, the update does get executed,(i can output the query string and no mysql_error() or notice) problems, but checking the database the row doesn´t get updated. Letting the output out if the script and Query does get commited. Only common thing is sessions are started and output is made.
I restarted Apache, etc(who knows) but no luck. Then i made something really stupid, because this is a server side thing. I changed my browser to Firefox(using safari) and everything works! Ok, recheck, back to safari, nothing works. Both running side by side, same issue. PHP is server side, how can different browsers handle code different, can a browser say to apache rollback, request not handled or call the same script twice without notice(checked safaris developer console and the script is called only once) ? Can safari resubmit data silently because it "thinks" ajax failed? I checked headers using firebug and Safaris developer tools , nothing strange but whenever i make a Ajax call with safari, the caller page reloads data(Aka conection to server...).
I really don´t understand nothing.
I had a similar problem to this (if I have understood correctly). I needed to force session data to be written (for a custom session driver) after scripts have finished running. A shutdown function can be registered which should run after scripts have finished.
Maybe this will solve (or help you to solve) your problem.
http://php.net/manual/en/function.register-shutdown-function.php
Thank's for your help. I was doing everything in the right order and still session data was not being written. Session names where necesary because sometimes we test many sites on the same domain using the same custom CMS. So, finally, after making lots of test and no luck, i found that register globals was active on this server(we never use it, code was written having this option off in mind of course), but it messes with sessions!. Switching this off made a huge change. No more problemas. I also made a custom session handler in DB, so i could track the problems in an more centralized way.
Conclussion: Never use register globals + named sessions, an complex data in sessions.
Anyway, i will give this issue more time and more tests. Ajax calls are also sometimes too fast, i had to put a sleep command so writing the session data was really done.Thanks
I am not sure but few suggestion i think may be helpful.
delete session cookies before refreshing the page for testing purposes :)
Ensure that you're not assigning any arrays with a key containing the pipe character (|). This will prevent the session data from being serialized and saved.
Do session_regenerate_id(true); many cases session_write_close doesn't seem to matter with out session_regenerate_id. or just do session_start() after session_write_close() if you are relying on SID ; and in your case i think this is what is causing problem to you as you are ending the current session every time and not re starting it for the next page. hope u get my point. Further more To Make sure data is actually flushed out to the browser use ob_end_flush();
i could not understand the connection between
$_SESSION['data']['CMSeditores']=$retorno[1];
$_SESSION['data']['CMScont']=$retorno[2];
and
$nivelpermisos=$_SESSION['cms_logged_group'];
$useractual=$_SESSION['cms_logged'];
i think you need to paste some more code where the data part is causing problem instead of admin login part.
i hope this helps you.:)
Is there any reason you're establishing the session name twice? I've had issues in the past where I would establish the session without a name, then another piece of script (not mine) was naming the session. Even at the end of the script I was able to print out the session variable, but once I went to a new page my session had been forgotten. It wasn't until I copied the name included in the 2nd script into my session call that it was solved.
Check that there's no other session names being used; also, maybe try only naming the session once, at the first call to the session?
Question: Are you calling session_start() first thing... before ANY output to the browser and before any variables are assigned?
Sounds silly but give it a try.
Also, why are you using session names? Really not necessary unless you have a lot of session variables with the same name serving different purposes and if thats the case then you need to fix that first!
I had a similar problem but it was having with ie few years back. IE manipulates the header on its own way and that causes strange php bugs that you can find in php.net archives.
#Diego Pino Navarro, please see this help page and find Safari and it's issues with php.
I also found "Safari "forget" http-authentication's logon-information".
I have an application with multiple regions and various incoming links. The premise, well it worked before, is that in the app_controller, I break out these incoming links and set them in the session.
So I have a huge beforeFilter() in my app_controller which catches these and sets two variables in the session. Viewing.region and Search.engine, no problem.
The problem arises that the session does not seem to be persistant across page requests. So for example, going to /reviews/write (userReviews/add) should have a session available which was set when the user arrived at the site. Although it seems to have vanished!
It would appear that unless $this->params is caught explicitly in the app_controller and a session variable written, it does not exist on other pages.
So far I have tried, swapping between storing session in 'cake' and 'php' both seem to exhibit the same behaviour. I use 'php' as a default. My Session.timeout is '120', Session.checkAgent is False and Security.level is 'low'. All of which should give enough leniency to the framework to allow sessions the most room to live!
I'm a bit stumped as to why the session seems to be either recreated or blanked when a new page is being requested. I have commented out the requestAction() calls to make sure that isn't confusing the session request object also, which doesn't seem to make a difference.
Any help would be great, as I don't have to have to recode the site to pass all the various variables via parameters in the url, as that would suck, and it's worked before, thus switching on $this->Session->read('Viewing.region') in all my code!
Try setting the security setting in your /app/config/core.php file to medium or low. That solved a session problem I had.
i had the solution or at least that work for me
you try to pass from controller reviews action write to controller userReviews action add right???
check that your controller userReviews must end whit php tag "?>" and NO MORE SPACE
SO if you have someting like this
line
999 //more code lines
1000 ?>
1001
your session fail
you have to had this
line
999 //more code lines
1000 ?>
sorry for my bad english
soo you
It would appear that unless
$this->params is caught explicitly in
the app_controller and a session
variable written, it does not exist on
other pages.
That sounds like the proper behavior unless you are posting data from page to page. If you want any variable to persist, it should either be set in the model (where it will persist with the association), or passed on in a function, or set in the session explicitly using the session component:
$this->Session->write('Viewing.region');
(see: http://book.cakephp.org/view/398/Methods)
On a related note, I've had most success with sessions stored in the database. Run the file from app/config and set it to db. See if that helps.
Also, do the Cake core tests for the session work?
Might it be this problem? Essentially, cake's session resets if the user-agent changes
It's a shame that I ran into this very problem you mention a few days ago and now I cannot find the link that helped me solve it.
Also: are you using database or plain php sessions?
I'm going to go out on a limb here without being able to look at your code, but might it be possible that your "reviews" controller (or whatever) has its own beforeFilter() and doesn't call its parent's beforeFilter() explicitly?
This has burned me before...
I got some issues like this. Session set using some controller was not available in another , controller . I could clear the issue after spending few hours . There was a white space afer the end of php tag at the bottom . After clearing the line and white space after the last ?>
tag worked fine .
I had this problem when moving a CakePHP site. My problem was that the session directory wasn't writeable. You should make sure the folder app/tmp and all it's subfolders (including sessions) have permission 777.
So I'm doing some maintenance on a PHP site that is using $_SESSION variables. I started seeing some very very weird behavior and after hours of debugging I just figured this out. As an example, lets say I have a session variable setup like this:
$_SESSION['user']['id'] = 123;
$_SESSION['user']['firstname'] = 'John';
$_SESSION['user']['lastname'] = 'Doe';
At one point in a script, a call to a MySQL table is made using some Zend classes:
$sql = "SELECT whatever FROM table";
$user = $db->fetchRow($sql);
Now here is where the weirdness starts... After this database call is made, my $_SESSION['user'] array value is all of the sudden changed to be the object that is retrieved from the database call...
Basically: $_SESSION['user'] is now the same as the object that was retrieved using the fetchRow DB method that was supposed to be stored in the variable $user. I've never seen this before.
The only thing I can figure out is because the variable name $user is the same as the $_SESSION['user'] array key name, its acting as like a shortcut or something.
Is this some sort of weird PHP Session shortcuts that I've never heard of before?
On a side note, I know that accessing $_SESSION vars directly is not the best practice. I didn't build this website. My job is just to fix some stuff and add some features.
UPDATE: Sure enough, register_globals is on. Thanks for the quick help guys. No wonder I was seeing such weird behavior.
Sounds like you have register_globals set to On in PHP.ini. Turning it off should fix this.
If you don't have access to change PHP.ini an alternative solution is discussed here
Check if register globals is turned on. Accessing $_SESSION is the only way to access session data safely.
Register globals is an old feature that turned global variables into local variables. The issue with that was you could not safely know where the data was coming from. Something you expected from a session could be set with a get, post or a cookie variable. So it was very easy to bypass security.