• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 204
  • Last Modified:

Has my user done a runner?

null
0
acsmith
Asked:
acsmith
  • 6
  • 3
  • 3
  • +1
1 Solution
 
acsmithAuthor Commented:
..and checking to see if the user's details are already loaded into the dll when they log on is not really an option, because we'll be running several servers (therefore several dll's obviously!)
0
 
idtCommented:
<HTML>
<HEAD>
</HEAD>
<SCRIPT LANGUAGE="JavaScript">
<!-- Begin
function leave() {
//you could do some kind of post back to server here
alert("DON'T LEAVE ME!");
}
// End -->
</SCRIPT>
<BODY onUnload="leave()">
</BODY>
<HTML>

Let me know if this helps
-iDT
0
 
acsmithAuthor Commented:
thanks for that, but I've been told that the onunload event doesn't always get triggered if they forcefully kill the browser. If nobody else can offer any suggestions,  i'll ask you to repost an answer so you can get the points. Thanks.
0
Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

 
MasseyMCommented:
In ASP There is a function that is called "isclientconnected".  It will check state to see if the client is connected.  I am not 1005 sure how you would implement this, but you could use code like this:

<%
If Not response.isclientconnected then
  ShutdownID = Session.SessionID
  shutdown(ShutdownID)
End If
%>


0
 
idtCommented:
sigh,
you are right, onUnload probably will not fire on netscape if shut down, on IE it does, forgive my premature ejaculation
0
 
MasseyMCommented:
man, I totally passed over the last part of the question...

But, why not just use an include statement in each page on the site that includes that code.  So it checks everytime they go to a different page.
0
 
acsmithAuthor Commented:
MasseyM, yeah I knew about the isclientconnected, but it seems a bit pointless. You can only use it when an asp is processing. For the asp to be processing, the user must have requested the page, and therefore must be connected. I guess you could use it if you have an asp which takes forever to run to test whether it's worth continuing the processing, but what if a client has requested a page, received it, and then shuts down the browser. No asp would be running, so you can't use response.isclientconnected. Any other ideas? the more I think about this, the more convinced I am that there is no solution :(
0
 
acsmithAuthor Commented:
sorry, must have been still typing while your last comment was posted. Can you expand a bit more on the include statement idea?
0
 
MasseyMCommented:
Well, I was just thinking about two things.

1) You could have a hidden frame field that refreshes every x seconds that will check the isclientconnected variable.  ?  Sounds like a good idea, but I am not sure how feasible it would be.

2) In every HTML page, just check the isclientconnected variable.  This was, they would not have to be on an ASP page.

0
 
acsmithAuthor Commented:
1 sounds reasonable, but i'm not sure how much extra load that would put on the server. I'll try it and see. I can't see how 2 could work though, the isclientconnected thingy can only be checked from within an asp (AFAIK). Actually, thinking about point 1, that wouldn't work either. If the client has killed the browser, the hidden frame won't get refreshed, so I still can't check if they're connected. I really don't think this is possible :((
Thanks for your ideas anyway.If nobody else can help, repost as an answer to get the points.
0
 
idtCommented:
would the overhead of constant posts by clients more than offset the savings of caching the data in the dll in the first place?

I think a better solution might be to have the dll regularly flush its data back to the server,  something likeif data has changed, and no activity for n minutes (less than the session time out), the flush back to server.

Just an alternative.

-iDT

"time waits for no man, but it has been reported to wait for turtles"
0
 
acsmithAuthor Commented:
yep, regular post back to the server cause big queues, and the request wait time goes sky high.The dll currently only writes back when something has changed, and it looks like i'm going to have to be happy with that. I'll split the points (check the authoring topic). thanks for the input.
0
 
gate14Commented:
doh!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

  • 6
  • 3
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now