Codeigniter - Session variables mysteriously disappearing - codeigniter

I am using Codeigniter 2.1.0 and CI_session for session handling.
I assume that this
Page A sets some variables in the session using $this->session->set_userdata().
Page A redirects to Page B
Page B is expected to retain the session variables that were set in Page A.
However this is what happens to me
Page A sets some variables in the session using $this->session->set_userdata().
Page A redirects to Page B
Page B does not retain the session variables that were set in Page A.
I have code in Page A to save and record the contents of $this->session->userdata in a log before redirection to Page B. The log shows that the values that are set in session exist.
However, using var_dump() on $this->session->userdata on Page B shows that those values don't exists.
I don't really know how this could be. I have double checked that I am not unsetting the values in Page B. It's like CI_Session is somehow unsetting them behind the scenes.
Any ideas?
EDIT: Yes, I am using the database to save session data. The field type is TEXT.

From what I understand from networks, the cookies and sessions are stored in client machine and not server. So HTTP basically adds cookies and sessions to your request headers and sends the request.
But in this case you are setting the sessions and then redirecting from the same page in server. Normal PHP might handle this differently but codeIgniter does not use native PHP sessions. (Refer http://ellislab.com/codeigniter/user-guide/libraries/sessions.html)
This is my guess. But it would be helpful if I take a look at your code.

Related

Forcing a logoff from a Joomla admin session

In Joomla! 3.6, we're trying to force a user to the login screen from the admin section if their session has expired, but without any user input. By default, Joomla! will send people to the login screen if they attempt to load a page after their session has expired. This is something we want automated so if someone walks away and forgets to lock their system, the current page(s) can't be accessed if the session times out.
My initial attempt around this was to run a timed JS loop in administrator\index.php and have it make an AJAX call to an external PHP file that could query the session table. However, including jQuery at such a high level causes many other references to break due to it being included more than once. Due to how the default redirect action works, all this really needs to do is force a page refresh.
Is there a better way or location to do this without breaking existing code?
This required two things to fix.
1) Add
// jQuery needed by template.js
JHtml::_('jquery.framework');
2) Change $.ajax to jQuery.ajax

Is it right to check session using ajax and redirect page?

I am planning to validate session for secure content using ajax. This will prevent access to secure page after logout or using browser cache.
Is this right approach to implement java script in html body tag to validate the session for every page load?
I tried with $( document ).ready(). But the browser cache retains the old value which says session alive.
Any suggestion on this?
The usual approach is to assign the session value to a method inside your controller. Then when you require the session value, call the method.

Apache Wicket Session Timeout; Logging back in and returning to the page

I'm not sure how to implement this and I'm quite new to Wicket, but the behavior I'm trying to aim for is; when a session timeout occurs, the User is redirected to the login page to relog, when he relogs, he is then redirected to the page he was viewing before.
Any help is appreciated.
The functionality you want only works when the server can identify which page you want to act on. So only stateless form submissions, and bookmarkable URLs will do this. Wicket does this out of the box, but only in the stateless/bookmarkable variations.
Wicket stores the page information (sort of) in the session. When the session has expired this information is no longer available. Then only requests that are not relative to the session/require information that used to be in the session will have the desired effect.
Have you tried the following code in your WebApplication.init() method?
IApplicationSettings asSettings = getApplicationSettings();
asSettings.setPageExpiredErrorPage(PageErrorSessionExpired.class);
Substitute your own WebPage class for my PageErrorSessionExpired here.

PHP session and Ajax

I've created a session variable and stored a value "123456" in it.
I need that value on another page that is called using ajax. I cannot access the session variable when making the ajax call. session_start() is in top of both pages. I even tried to write the actual session value to a txt file from the page that the ajax function calls, but the file turned out blank.
What to do?
You cannot access PHP session info from Javascript (I'm assuming that this is what you're trying to do). You can pass it in as a hidden field or in the JS (dynamically added with PHP) to the second page, add it to a regular cookie, or provide it from PHP as a response to an AJAX request, but I think those are your only options.

IE6 accessing MVC3 web app loses session state

I’m investigating a bug in my MVC3/.NET 4 site which runs on IIS7.5 with integrated pipeline that only manifests itself when accessed using IE6.
The process in pseudo is:
Browser requests Page A; server sets
a Session[] value and responds with
the page.
Enter data onto Page A and
http post the form back.
Server tries to get value out of Session[]
previously set in (1) but returns
null >> but only in IE6, 8(.
In IE7, IE8, IE9, Firefox 3.6, Safari 5.0.3, Chrome 10 the same code works without change.
In my global.asax code I put a Session_Start handler in and noticed some strange behaviour.
In IE6 this handler is fired upon every request made BUT the Session.SessionID value remains the same. All the other browsers mentioned above only have this handler fire the first time they make a request. So for IE6 even though the session ID is the same each time it is called it would seem that the fact that it is “start”ing a new session seems to have the effect of clearing the data for the Session ID and starting it again hence the null value.
One theory I had was that because some items on the page (images etc…) would be accessed with HTTP whilst the page itself is HTTPS could be why IE6 is causing this behaviour (new session per protocol perhaps?) but I turned off the code that forced HTTPS to be used on the page in question, so all requests would be HTTP. Unfortunately the same behaviour is still observed on IE6.
After a lot of Googling I found things that said stuff like underscores in the domain can cause this (no underscores present in mine), ensure IE6 is accepting cookies (my test VM was set like to accept all session cookies).
Finally in a last ditch attempt:
I turned every privacy and security setting I could find in IE6 to as low as it would let me
I added my test site (http://<my machine name>/MyApp) to the list of trusted sites
Clear temporary internet files and cookies
Still I get the same issue. I have thought of a way to fix it that involves not using Session for this case but I would rather not make changes due to IE6 when it works in all of the other browsers including decendant versions of IE.
Edit: Some further testing on another page and when accessed via IE6 the session value is correctly retrieved after being stored by access to another page. More specically:
Working Page - Search:
Do a search, results are display and
criteria are stored in session.
Click on one of the results to view it, details page gets criteria in order to build querystring for breadcrumb trail link.
Failing Page - 2 stage login:
Go to 1st stage login page, enter username and password, assuming correct store encrypted http only cookie value with username in.
Redirect to 2nd stage login page, store 3 index values (List<int>) into a "secret" word in Session
Enter 3 characters from a secret word and post back.
Access session to get 3 index values - get nothing.
The reason for the failure is evident due to the observations made in the more generic description above. This is just getting weirder by the minute (and more frustrating).

Resources