Solved

How do i force logoff if you were a user that was just deleted?

Posted on 2011-09-20
24
193 Views
Last Modified: 2012-05-12
When i as an admin go into admin area to delete someone

that is already logged into the website as a user their session does not terminate what kind of code would i use to kill there session and log them out. I do not need a good that would log me out i need a good that would log them out on there computer. Right now i am dealing with users thare are still logged into the website with deleted accounts which are valid until they either close the browser or log out.
0
Comment
Question by:U_S_A
  • 6
  • 5
  • 5
  • +4
24 Comments
 
LVL 13

Accepted Solution

by:
Hugh McCurdy earned 500 total points
ID: 36570528
I'm going to assume you are tracking them with a $_SESSION variable or some other cookie that expires when the browser closes.

I would confirm that the user is still an authorized user each time a page loads.  To accomplish this, I would write a function in a separate PHP file and then include/require the PHP file in each page.  Also I would change each page to call the function.  If the user is authorized, the function simply returns.  Otherwise, the function calls die().
0
 
LVL 1

Expert Comment

by:solarisedesign
ID: 36570612
Deleting a user from a database won't have any effect on their active session. In effect, the data that is stored when a user logs on is completely seperate from the data held about that user in the database.

What you may have to do is somehow retrieve that other user's session id, in order to restore the session belonging to that user and then call session_destroy, e.g.

if(session_id($id)){  //this, in effect, logs you in as the other user
    session_start();
    session_destroy();
}

Open in new window


This will, of course, require that you've stored that user's session id along with their details in the database. This can be achieved by e.g. when the user logs in, retrieve the session id by calling session_id and then save it to another field in the users table.

When deleting the user, first retrieve the session_id as outlined above, and destroy the session before fully removing that user's data
0
 

Expert Comment

by:JustAMod
ID: 36571510
I've requested that this question be deleted for the following reason:

This appears to be a duplicate thread of <a href="http://www.experts-exchange.com/Database/MySQL/Q_27314791.html">http://www.experts-exchang<wbr />e.com/Data<wbr />base/MySQL<wbr />/<wbr />Q_2731479<wbr />1.html</a>. EE only allows a maximum of 500 points per question, and this basically bypasses this limit. <br /><br />If ther are no &quot;significant&quot; differences between these two threads, this one will be deleted. <br /><br />Experts, please review the thread above and transfer your comments accordingly. <br /><br />I am going to start the Auto Delete process, but I am subscribed to the thread. If you feel these are totally separate, unrelated issues, please advise.
0
 

Author Comment

by:U_S_A
ID: 36571496
we have requested our other post related to this subject be deleted.  keep this one please.
0
 

Author Comment

by:U_S_A
ID: 36571511
we have requested our other post related to this subject be deleted.  keep this one please.
0
 

Author Comment

by:U_S_A
ID: 36571515
hmccurdy:

This sounds logical.  We need help writing this code.
We are using Session ID
How can we get your help to write this code, please?
0
 
LVL 13

Expert Comment

by:Hugh McCurdy
ID: 36571551
I don't know the scope of your need at this point.

I also don't know how your system is structured.

Do you need help knowing how to include a file in PHP and how to call a function (and where to place it so that it gets called early)?

Writing the function doesn't seem too difficult except I don't know what SQL query you'll need in order to see if the person is on file.
0
 
LVL 4

Expert Comment

by:MattJellings
ID: 36586523
Just to throw an alternative suggestion in here and this is not something I've tested or unfortunately could offer much help with, but wanted to mention it so you could consider it.

With PHP it's possible to have session information tracked in a MySQL database rather than the default system used by PHP (I believe it uses flat files).

If your session information is stored in the MySQL database then on your user list you could show whether the user is currently logged in, and when you delete the user you would simply need to delete their active session from the database.

I believe, the next page they try to access their session wouldn't be valid and they would be treated as logged out?

Just a thought, as it may be an alternative solution to checking if their account is valid on every page refresh.

Anyone else got any thoughts on this method?

Cheers

Matt
0
 
LVL 4

Expert Comment

by:MattJellings
ID: 36586541
This page http://shiflett.org/articles/storing-sessions-in-a-database has some details around saving session data in the database.

Typically this is often used when you have a load balancing system in place which directs users to any one of many web servers for each request.  By storing the session data in the database regardless of which server the user is redirected to their session would exist and be tracked and they would remain logged in.  But, that's besides the point and going off track a bit.

Just something to consider.

Cheers

Matt
0
 
LVL 108

Expert Comment

by:Ray Paseur
ID: 36593020
What you are asking for cannot really be done.  Here is why.  HTTP is a stateless protocol, so the concept of a user who is  "logged in" simply does not exist.  HTTP is also a client-server protocol.  In that protocol, clients make requests and servers respond.  There is nothing you can do on the server side of things to initiate an action on the client side of things.

The reason that clients may appear to be "logged in" or "logged out" is related to the way cookies work.  When a client visits your site and passes authentication, your scripts will send a cookie to the client browser (session handlers do this automatically).  The client browser will return the cookie with each client request.  Your scripts will observe the cookie and use its contents to make decisions about the behavior of the server, including allowing access to authenticated data.

Unless and until the client makes a request, you cannot change the cookie on the client machine, hence there is no way to "log him out" at all.  You can, however, prevent future requests by forcing unauthentication via a data base check at every login.  This article explains the design patterns that the professionals use for such a thing.
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_2391-PHP-login-logout-and-easy-access-control.html

HTH, ~Ray
0
 
LVL 4

Expert Comment

by:MattJellings
ID: 36594914
I think if I were in your situation I would create some custom session handling functions that not only store session information within the database but also deserialise the data before storing it so along with the session data you can store who the user is, and the IP address their requests are from (not really required but might be useful).

Then, on your user page you would be able to see who currently has an active session (is logged in) and what IP address they are coming from, then you can delete the user as you would normally, but also remove their session from the database.  Then, on their next request their session isn't valid anymore and they are essentially logged out.

The overhead of storing session in a database is, I believe negligible compared with IO access for standard session handling but you don't need a request to the DB with every page load, and you user page can show who is currently logged in.

But as Ray has mentioned, you can't actively log someone out until their next request to your site, regardless of which method you decide to go for.

Cheers

Matt
0
Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

 
LVL 108

Expert Comment

by:Ray Paseur
ID: 36595218
See the config script shown in the article here.
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_2391-PHP-login-logout-and-easy-access-control.html

At line 84 it says, "DETERMINE IF THE CLIENT IS ALREADY LOGGED IN BECAUSE OF THE SESSION ARRAY."  If you delete this control structure, it will rely on the "remember me" cookie alone.  The "remember me" cookie will trigger a data base lookup (line 92) to set the session "uid" field (line 106).  By making this change you will create a situation where your data base changes will take effect at the time of the next HTTP request, without regard to the state of the client session.  This is as close as you can get to the goal of "kill their session and log them out."

Of course if you do that, you will need to unilaterally impose the "remember me" option - just treat the rest of the scripts as if the "remember me" checkbox has always been checked.  See the login script, lines 29-32.

You may find this easier than writing a custom session handler.  Best regards, ~Ray
0
 
LVL 2

Expert Comment

by:maricksville
ID: 36599951
My approach would be to validate the credentials of a user anytime they attempt to access your database.

When a user logs into your application your system will check their credentials and see if they have permission to access the database and perform queries on the database. Each and every time they attempt a query a function is run that validates their right to do so. If they fail your validation process then their session is terminated and you evacuate them from the application.

A breakdown is like this:

User logs in > System checks if the user exists and whether they have the correct permission. Non-existent users or users with incorrect permissions are denied.

User queries the database > Prior to the query system checks if they are logged in, if they exist in the database, and if they have the correct permissions. Non-logged in users, non-existent users and users without the correct permissions are expelled and the session is terminated.

Hope this helps.
0
 
LVL 108

Expert Comment

by:Ray Paseur
ID: 36600171
... to validate the credentials of a user anytime they attempt to access your database.

This takes us back to the nature of the HTTP protocol.  HTTP is a stateless client-server protocol.  Clients make requests, Servers make responses.  Each client request and its companion response is a single action that is usually completed instantaneously by a script on the server.  The appearance that a client is "logged in" is merely apocryphal.  The server has completed the request before the human client sees the output.  It does not matter how long the human stares at the computer screen; the server has already done its work.  The cookies that have been set by the server are sent with each client request.  If a cookie is returned that tells the server that the client is logged in, then the server believes that the client is logged in at the instant of the request.  

In a good application design you do not validate credentials conditionally.  You either validate for the script or you do not validate for the script, making it completely public.  You do it once at the top of the script and that is all that is needed.  You can make it more complicated by creating multiple levels of client permissions, but the right design would still include a single point of client validation before completing the request.  Check out the access_control() function in this article to see how it is done.
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_2391-PHP-login-logout-and-easy-access-control.html
0
 
LVL 13

Expert Comment

by:Hugh McCurdy
ID: 36600303
I'm going to chime in.  This problem may be solved.  A user who has lost his account may continue as a guest (view only).  Seeing pages isn't a problem (AFAIK).  So that the user can still see the current page is quite OK.  The logout is supposed to prevent the user to updating anything.  (At least that's my understanding.)
0
 
LVL 4

Expert Comment

by:MattJellings
ID: 36600329
If this is in fact the case then it may be just a simple to re-validate the user when they access any page whereby they may be able to update anything.
0
 
LVL 108

Expert Comment

by:Ray Paseur
ID: 36600440
@hmccurdy: If by the "current page" you mean the representation on the computer screen of the server's response to the client's last request, the deed has already been done by the server and that information is on the screen.  It may or may not contain authenticated data, but there is nothing that the server can do about it any more once the response has been sent.  It can only do something when the client sends the next request.  The client will send cookies with the request.  In the response to a request, the server can issue a setcookie() command to change the client cookies.  Well-behaved HTTP clients store and return cookies correctly.  Hackers are not usually well-behaved HTTP clients, and that is why some additional security is sometimes needed.

@MattJellings: Yes, that is exactly how it is done.  The validation occurs once per request for any resource that needs to be protected.  Typically things like images, CSS and HTML do not need to be protected.  Access to the underlying data model often needs to be protected.  So the script portion of the request would look for the validation signal, which is usually a cookie.  The cookie can be a key to a data base row.  If at the time of the request the row does not exist, the request fails validation.  

That is why the "uuk" field is useful in the examples given in the article.  When the site owner wants to "unregister" a user, he simply deletes or mungs the "uuk" value in the user's row of the EE_userTable.  Any future request will send a 'uuk' value that no longer exists, and the query, "SELECT uid FROM EE_userTable WHERE uuk = '$uuk' LIMIT 1" will return a null results set.
0
 
LVL 4

Expert Comment

by:MattJellings
ID: 36600504
Thanks Ray.

I think, throwing my 2 pence worth in, depending on the exact situation I would do the following:

1) If the ability for the user to continue browsing the site after their account has been removed is OK, and the only issue is that should they attempt to update any information they need to be logged out then I would simply add code into the header of such pages that checks their account credentials against the database.  If it cannot find their account details then it has been deleted and subsequently they should be logged out, unset session variables, session_destroy() etc.

2) If the issue is that once the account has been deleted they are not able to view any further pages (.php etc, not image resources) then I would implement the custom session handler I mentioned earlier.  I learning against the idea of re-querying the database on every page request to check their account is still active, when some initial changes to error handling could prevent this extra overhead.

But, it largely depends on the exact situation at hand, the requirements on in what situation they should be logged out and on whether querying the database on each page request will cause any overhead problems.  If not, then go for this as it's a simpler solution to implement rather than customising the way sessions are handled.

Just my thoughts

Hope you manage to get it working.

Cheers

Matt
0
 
LVL 13

Expert Comment

by:Hugh McCurdy
ID: 36600521
Ray, yes the deed is done and I believe, in this case, it's OK because (AFAIK) a non-authenticated guest is allowed read-only access to all pages.  The restrictions are about updates.   The solution is to verify the user's member ID each time a page loads.

Yes, there are ways around this.  And there are countermeasures. There are countermeasures to the countermeasures.  (And it keeps going.)   It would be possible to add "bank level" security to the author's site.  This would be expensive.  The expense is the decision of the site owner (the author).
0
 
LVL 108

Expert Comment

by:Ray Paseur
ID: 36600539
whether querying the database on each page request will cause any overhead - Not ever a problem!

But I think the design concept that overarches the question is one of "resources" rather than web pages. See The Tools for Testing and the two different ways of calling the access_control() function in the article.  One kind of call is informational.  Another kind of call requires authentication.
0
 
LVL 4

Expert Comment

by:MattJellings
ID: 36600547
@hmccurdy
Sorry if I've missed something in the conversation above, but could you confirm why you believe it's OK to the logged in user to continue browsing the site as read only access?

My understanding from the original post is that once the user account has been deleted U S A want's their session terminated and the user logged out.

I believe the condition of either allowing the user to continue on a read only basis until they try to update information as opposed to immediately terminating their session and logging them out would change how a solution could be implemented?  Although, I may have mis-read or mis-understood something, sorry if this is the case.

Cheers

Matt
0
 
LVL 13

Expert Comment

by:Hugh McCurdy
ID: 36600774
Matt, I know.  I have additional information from the author that wasn't included.  (I asked a clarifying question.)

Hopefully all this activity will get the author back here so we can wrap this up.
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

These days socially coordinated efforts have turned into a critical requirement for enterprises.
This article discusses how to create an extensible mechanism for linked drop downs.
In this tutorial viewers will learn how to embed videos in a webpage using HTML5. Ensure your DOCTYPE declaration is set to HTML5: "<!DOCTYPE html>": Use the <video> tag to insert a video. Define the src as the URL of your video; this is similar to …
HTML5 has deprecated a few of the older ways of showing media as well as offering up a new way to create games and animations. Audio, video, and canvas are just a few of the adjustments made between XHTML and HTML5. As we learned in our last micr…

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now