The session_start() function is on line 4. Like I said the script works locally.
Main Topics
Browse All TopicsI am using a timed logout script to force logout on a website after a certain amount of time. The js script contains a reference to the file used to unset session variables. The file used to unset session variables is simple and lifted below; I have the local and hosted database connection scripts listed and comment either one out as relevant. The routine works fine on my local machine and deletes the userSessionID variable. However, although the auto logout script is working on the site the delete query is not actioned. I have checked that the correct db connection is being used etc., but cannot understand why the query does not run.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Nope.
You are using file session data.
If $_SESSION is not set, then you call session_start().
Nothing wrong with that, but you do not also call session_set_save_handler to set up the DB access.
So, again, load ...
<?php
phpinfo();
?>
and check what the session entries are.
Check the directory for the sessions and make sure that location is accessible.
And check the error logs
Session information is being written to /var/lib/php/session and I the session file is recording something. For example, I logged in, allowed the auto logout to execute and then checked the session file which contains this:
MM_Username|s:2:"12";MM_Us
Not sure whether there's anything helpful in there.
One thing I didn't say is that if the user logs out using the logout link the sessionID does get deleted from the database, it just isn't happening when the auto logout redirects to the endSession page.
I am using a script made available by Phil Palmieri (http://philpalmieri.com/2
Can you show the JS code you are using which is setting the logout_url?
In looking at the code ...
var redirect = function()
{
if(opts.logout_url)
{
$.get(opts.logout_url);
}
window.location.href = opts.redirect_url;
}
I'm a little worried about the timing.
So, an additional debug could be useful...
<?php
file_put_contents('./logou
// Your logout code.
file_put_contents('./logou
exit;
?>
But I'd also add something similar to the main redirected page.
<?php
file_put_contents('./logou
// Your logout code.
file_put_contents('./logou
?>
The full JS code from the timedLogout.js file is below (copyright of Phil Palmieri). I have added the additional debug to the logout_url file (endSession.php) but cannot find the logout file on my system! However, I am not generating sessions using a cookie, why is $_COOKIE in there? Regarding the code for the main redirected page I am not sure where to put that because there is no auto-logout code on any page apart from endSession.php.
So, if you are not using session cookies, you need to be getting the session id via the URL.
So, the logout_url needs to contain the session id.
But, from the code you've supplied so far, you _are_ using session cookies. Hence $_COOKIE being present.
I'm wondering if there is a gap in your understanding of how sessions are maintained.
Every request that a browser makes to a server is completely disconnected to every other request. This is by design and you cannot alter that.
This is known as "stateless".
HTTP is a stateless protocol.
Nothing exists before or after the request which the request can expect or rely on.
To get around this, the idea of a session exists.
The issue is how do you get these disconnected requests associated with the session.
The answer, in most cases, is a session cookie.
PHP's session cookie is, by default, PHPSESSID.
Run the attached script twice.
The first time the output will be an empty array. This is expected because the cookies coming into the script will not have the session (oh. thinking about this, you MAY actually have a value there - so if you can close your browser first, that will remove any session cookies for the domain).
The second time you run the script you will have output.
The session id is maintained as a cookie - this is transparent to you normally. You _CAN_ alter it, but you have to do more work.
What I am trying to determine is if using JS location.href and / or $.get(), supply the cookie.
If not, you can't connect to the server side session and no username/id and no delete in the DB.
If you can check your cookies in your browser first. If you have any for the local domain, deleting them will be useful to prove what I am talking about.
Thanks, I am just getting to grips with sessions. I understand what you are driving at. I am using cookies rather than the url extension to manage sessions. However, I don't think the JS file has anything to do with the session variables, my file endSession.php handles the session closure (or should), so once the JS file sets the redirect to endSession.php all that file does is delete the session from the session table which then allows the user to login again if required. If the session id is not deleted from the database then the user is not permitted to login as I have set up a routine to ensure that any given user can only have a single session open.
You'll probably say $_SESSION['MM_Username']
And I'll say No.
That's a value held in the session. Not the session itself.
The JS file _MUST_ supply a cookie to allow PHP to extract the session_id, so that the correct $_SESSION is setup so you can get the MM_Username value.
So. I need you to debug the endSession.php script.
So that is why I've asked you to log the cookies it receives. That's where the session id is.
If the cookie is empty, then the JS call is NOT supplying the cookie.
Without that, you can't continue.
Really. Honestly. 20 years as a s/w developer and a PHP ZCE say so!
Really really really.
Regards.
Richard.
P.S. You're lucky to get a response. The laptop is in the kitchen. I'm cooking chicken curries. I've got a bottle of wine or two open and Billy Bragg on nice and loud!
Good times!
Most likely it is a timing issue.
On index.php and menu.php, what do you do with the session data?
As AJAX calls are asynchronous, the GET (for the logout) happens at the same time as either the index.php or menu.php.
So, if these ALSO write to the current session (the one supplied in that request's cookie), you may end up simply writing a brand new entry.
On the table, do you have an IDENTITY/AUTOINC column?
If not add one.
Let's see if the session entry in the DB is being deleted and recreated.
I have posted the full login script below. I generate a sha1 hashed session variable called userSessionID from their username (obtained from the login query) and check the database to determine whether it is already in there (no index or auto-increment for the table). If the user is already in the database then they are already logged in somewhere else and the session is destroyed (although the redirect to concurrentLogin.php doesn't seem to work). If the userSessionID is not found in the database then it is generated, inserted and the login continues to menu.php.
Once the user is at menu.php if they do nothing for the period set in the autoLogout.js script they get logged out using endSession.php which should simply delete the variable userSessionID from the database thus enabling them to login afresh.
We need to start tracking what is happening.
Obviously, the scripts are not working as expected, so some debugging is required.
The following line should help ...
@file_put_contents('./debu
I would put this line in several key places in the scripts to log what is happening.
The log file may grow very quickly.
The name (./debug.log) should be converted to an absolute filename so that if the scripts are in different folders, the same log file is written to.
So, a script like ...
<?php
// *** Validate request to login to this site.
if (!isset($_SESSION)) {
session_start();
}
$loginFormAction = $_SERVER['PHP_SELF'];
if (isset($_GET['accesscheck'
{
$_SESSION['PrevUrl'] = $_GET['accesscheck'];
}
if (isset($_POST['usr']))
{
should become something like ...
Your log file will contain a line for each debug. This will allow you to see what is going on across multiple scripts.
You will need to make sure that the web server account has write access to the file.
I'm really stuck with ...
if(opts.logout_url)
{
$.get(opts.logout_url);
}
This is saying to me ...
If there is a property of opts which does not evaluate as false, then ...
I can't see what $.get() does.
$ is jQuery - fair enough.
get() though is the CSS collector.
get( ) Returns: Array<Element>
Access all matched DOM elements.
get( index ) Returns: Element
Access a single matched DOM element at a specified index in the matched set.
Nothing to do with launching an HTTP GET request.
As I see it anyway.
Either way. Add the debugging.
You have to prove that the code works remotely by presenting a debug log file showing the calls are getting made.
I'm not convinced.
OOI, run the same debugged code locally. See what you get.
Do you have a live version I can see? I want to see what requests are actually generated? (Firefox with Firebug and Wireshark).
I have put the debugging lines interspersed between all of the code that is involved in the auto logout procedure, and I have put them into the menu.php file as that's the page that the user is taken to when they first login. However, it seems that the file isn't getting written to the disk either locally or on the host server. I have set a full url path to the root of the site so I know that the folder has read/write access.
As the site I am working on is my company's intranet we'd have to go offline with this and I could set you up a temporary account so that you can see what's happening.
Getting the debug working is pretty important.
Try this ...
<?php
error_reporting(-1);
ini_set('display_errors', 1);
echo 'Current dir:', getcwd(), ' and we wrote ', file_put_contents('./log.l
?>
Wherever you place this file you should be getting a log.log file when you run it.
Try it locally.
OK then, this is what I get when I run the file...
Current dir:/Users/kcalder/Sites/R
Right.
2 problems.
The date.timezone issue is important as you may find all sorts of issues with cookie expiry times when dst changeover happens.
The important one is the permission denied.
I would recommend creating a folder with write permissions somewhere.
Then put the absolute path in the script...
file_put_contents('/some/p
OK, ignoring the time/date issue and concentrating on the main issue, I have created the folder and set write permissions for all. I changed the debug script to include the path to debug.log and included the debug script as below. With the auto logout routine working on my local machine (i.e., the userSessionID entry is deleted) the following is what's written to the debug.log file...
1,254,399,934.8552100658 /Users/kcalder/Sites/RED/m
which quite frankly means diddly to me.
Can you change ...
@file_put_contents('http:/
to
@file_put_contents('/Users
please.
The log file should show you a LOT more detail.
1,254,399,934.8552100658 /Users/kcalder/Sites/RED/m
is broken down into ...
The time the debug line was generated : 1,254,399,934.8552100658
The fullname of the script writing the debug : /Users/kcalder/Sites/RED/m
The line number in the file : 14
The session ID as provided by the $_COOKIE['PHPSESSID'] : r6bjakk1ocb5u8bu4dnt8oedm1
So, this log file will show you which lines of code (more or less) are being executed when the auto logout process kicks in.
Once we have that, I can explain what is happening.
Yes, sorry I noticed the two lines with the wrong path in only once I had posted the code. I deleted the existing log file, logged in again and allowed the auto logout to fire. Here's the contents of the debug.log file now with the paths corrected...
1,254,403,303.2875320911 /Users/kcalder/Sites/RED/m
1,254,403,303.2877700329 /Users/kcalder/Sites/RED/m
1,254,403,303.2883310318 /Users/kcalder/Sites/RED/m
Well, this is what has been generated in the log file through two successive logins and auto logouts. The first 3 lines were generated after I was logged out automatically and the redirect failed to go to endSession.php. I can tell this because userSessionID is still in the database table and wasn't deleted meaning I had to remove it manually before trying to login again. The remaining lines were generated after a second login/auto-logout at which time the redirect to endSession.php worked.
1,254,410,155.1620330811 /Users/kcalder/Sites/RED/m
1,254,410,155.1623771191 /Users/kcalder/Sites/RED/m
1,254,410,155.1631588936 /Users/kcalder/Sites/RED/m
1,254,410,215.9074170589 /Users/kcalder/Sites/RED/m
1,254,410,215.9076359272 /Users/kcalder/Sites/RED/m
1,254,410,215.9079999924 /Users/kcalder/Sites/RED/m
1,254,410,240.7787539959 /Users/kcalder/Sites/RED/m
1,254,410,240.7790300846 /Users/kcalder/Sites/RED/m
1,254,410,240.7791829109 /Users/kcalder/Sites/RED/m
1,254,410,280.9987630844 /Users/kcalder/Sites/RED/e
1,254,410,280.9992530346 /Users/kcalder/Sites/RED/e
1,254,410,280.9993760586 /Users/kcalder/Sites/RED/e
1,254,410,281.0017800331 /Users/kcalder/Sites/RED/e
1,254,410,281.0019109249 /Users/kcalder/Sites/RED/e
1,254,410,281.0019850731 /Users/kcalder/Sites/RED/e
1,254,410,281.0026540756 /Users/kcalder/Sites/RED/e
1,254,410,281.0027580261 /Users/kcalder/Sites/RED/e
1,254,410,281.0028278828 /Users/kcalder/Sites/RED/e
1,254,410,281.0028960705 /Users/kcalder/Sites/RED/e
1,254,410,281.0032999516 /Users/kcalder/Sites/RED/e
Can you show your current endSession.php script please?
We can see the script is called WITH a valid session id. Now time to add some debugging with regard the DB DELETE.
Can you add the @file_put_content() line to any script that deals with the session/db stuff.
Trying to see the flow of things.
I'm wondering what happens after endSession is called.
With regard to ...
$query = sprintf("DELETE FROM session WHERE sessionUser=%d", $_SESSION['MM_Username']);
@file_put_contents('/Users
Is MM_Username a number cause that is what you are casting it as in the sprintf function.
Change the debug line here to ...
@file_put_contents('/Users
The full endSession script is as in the snippet below. The outcome of running the debug on it with the adjusted debug line is as follows...
1,254,494,221.2450859547 /Users/kcalder/Sites/RED/m
1,254,494,221.2454929352 /Users/kcalder/Sites/RED/m
1,254,494,221.2487909794 /Users/kcalder/Sites/RED/m
1,254,494,261.4845840931 /Users/kcalder/Sites/RED/e
1,254,494,261.4848310947 /Users/kcalder/Sites/RED/e
1,254,494,261.4853150845 /Users/kcalder/Sites/RED/e
1,254,494,261.4871919155 /Users/kcalder/Sites/RED/e
1,254,494,261.4872961044 /Users/kcalder/Sites/RED/e
1,254,494,261.4877259731 /Users/kcalder/Sites/RED/e
1,254,494,261.4892289639 /Users/kcalder/Sites/RED/e
1,254,494,261.4893510342 /Users/kcalder/Sites/RED/e
1,254,494,261.4902369976 /Users/kcalder/Sites/RED/e
1,254,494,261.4907789230 /Users/kcalder/Sites/RED/e
1,254,494,261.4914829731 /Users/kcalder/Sites/RED/e
The above was logged when the auto logout DID delete the user session information. However, I tried this once before this when it didn't delete the session informatin but the debug included the query command was output to the log. Very odd.
Sorry, let's try that again. I had amended the debug in the wrong file. Putting the query string into the debug within endSession.php gives me...
1,254,495,234.8202230930 /Users/kcalder/Sites/RED/m
1,254,495,234.8204860687 /Users/kcalder/Sites/RED/m
1,254,495,234.8212630749 /Users/kcalder/Sites/RED/m
1,254,495,250.2579410076 /Users/kcalder/Sites/RED/m
1,254,495,250.2581501007 /Users/kcalder/Sites/RED/m
1,254,495,250.2607250214 /Users/kcalder/Sites/RED/m
1,254,495,290.4283299446 /Users/kcalder/Sites/RED/e
1,254,495,290.4285249710 /Users/kcalder/Sites/RED/e
1,254,495,290.4292490482 /Users/kcalder/Sites/RED/e
1,254,495,290.4974210262 /Users/kcalder/Sites/RED/e
1,254,495,290.4975779057 /Users/kcalder/Sites/RED/e
1,254,495,290.4979400635 /Users/kcalder/Sites/RED/e
1,254,495,290.4992020130 /Users/kcalder/Sites/RED/e
1,254,495,290.4993069172 /Users/kcalder/Sites/RED/e
1,254,495,290.4998168945 /Users/kcalder/Sites/RED/e
1,254,495,290.5003309250 /Users/kcalder/Sites/RED/e
1,254,495,290.5010468960 /Users/kcalder/Sites/RED/e
Full endSession.php script in snippet below...
And is sessionUser 13 valid?
User_NAME_ ? Are you called "13"?
UseID would be fine and then I'd expect the query to use a number, not a string.
Add another column to the table. The column needs to be an autoinc/identity column. No need to change your code as the db will look after it.
There must be more code dealing with adding the session and logging the entry in the DB. Can you add the file_put_contents() line to that file please?
Either way, what it comes down to is the auto logout js script is wrong.
It shouldn't be calling 2 requests.
It should only call 1.
The endSession.php script should be doing the redirect.
Er, MM_Username is actually a reference to the primary key of the user rather than a string, I need to change it to userID or something. Can you spell out for me what an autoinc column will do? The initial login is managed on the index page so I have added the debug logging to that and the results are below (not for the auto logout); not sure what it tells us.
But it's certainly a problem if the js script is wrong since the whole shooting match is based on it (and I didn't write it), and it contains a specific line for the redirect since it doesn't manage the session.
1,254,513,956.6509370804 /Users/kcalder/Sites/RED/i
1,254,513,965.9895958900 /Users/kcalder/Sites/RED/i
1,254,513,965.9898269176 /Users/kcalder/Sites/RED/i
1,254,513,965.9905819893 /Users/kcalder/Sites/RED/i
1,254,513,966.0368568897 /Users/kcalder/Sites/RED/i
1,254,513,966.0380160809 /Users/kcalder/Sites/RED/i
1,254,513,966.0385909081 /Users/kcalder/Sites/RED/i
1,254,513,966.0390551090 /Users/kcalder/Sites/RED/i
1,254,513,966.0401389599 /Users/kcalder/Sites/RED/i
1,254,513,966.0403740406 /Users/kcalder/Sites/RED/i
1,254,513,966.0442609787 /Users/kcalder/Sites/RED/i
1,254,513,966.0444281101 /Users/kcalder/Sites/RED/i
1,254,513,966.0450160503 /Users/kcalder/Sites/RED/i
1,254,513,966.0455410480 /Users/kcalder/Sites/RED/i
1,254,513,966.0460689068 /Users/kcalder/Sites/RED/i
1,254,513,966.0466320515 /Users/kcalder/Sites/RED/i
1,254,513,966.0472300053 /Users/kcalder/Sites/RED/i
1,254,513,966.0477559566 /Users/kcalder/Sites/RED/i
1,254,513,966.0498719215 /Users/kcalder/Sites/RED/i
1,254,513,966.0499949455 /Users/kcalder/Sites/RED/i
1,254,513,966.0505158901 /Users/kcalder/Sites/RED/i
1,254,513,966.0510690212 /Users/kcalder/Sites/RED/i
1,254,513,966.0516428947 /Users/kcalder/Sites/RED/i
1,254,513,966.0864300728 /Users/kcalder/Sites/RED/i
1,254,513,966.0865991116 /Users/kcalder/Sites/RED/i
1,254,513,966.0873539448 /Users/kcalder/Sites/RED/i
1,254,513,966.0902509689 /Users/kcalder/Sites/RED/i
1,254,513,966.0904181004 /Users/kcalder/Sites/RED/i
1,254,513,970.8644230366 /Users/kcalder/Sites/RED/i
Hi.
First of all, sorry for not getting back earlier. Life intrudes on my EE time.
I'm trying to find the sequence of database updates.
So, strip out all the file_put_content() lines.
But leave them in where they are next to lines dealing directly with amending the database (INSERT, UPDATE, DELETE, SELECT).
And leave one in at the very top of the file.
This will show the order in which files are accessed and the order in which the database is updated.
Do you have a live site I can look at?
All of this is pretty simple to debug with Firefox+Firebug and Wireshark. It will show you all the requests being made and the responses.
I think the problem is that the JS code is calling 2 requests at the same time. A logout AND a redirect.
I think the logout request is being killed before it starts because the redirect is kicking in too early.
The better solution is to redirect to the endSession.php script.
The endSession script does the logout and then issues a header to redirect the browser.
That way the browser only makes 1 request.
At the end of the endSession script ...
header('Location: http://www.example.com/');
sort of thing.
Hi and thanks for getting back on this again. I have a live site but since it is a commercial intranet I'll need to set you up as a user and give you a login. This information would need to be forwarded to you outside of EE, so let me know how you would like me to do that. Meanwhile, I'll sort out the files I have been logging (index.php, menu.php, endSession.php) as indicated.
Business Accounts
Answer for Membership
by: RQuadlingPosted on 2009-09-23 at 02:37:07ID: 25401213
There is no session_start() in the script, so there is no $_SESSION, no $_SESSION['MM_Username'], no $user, so the query ends up as
DELETE FROM session WHERE sessionUser=''