I am designing a top level page which is designed by implementing a frameset. In one frame of the frameset, I will invoke JavaScript to refresh the page to post to some URL regularly (every 10 minutes). In the other frame of the frameset, I will let user do the major work -- let end user enter input for a time-consuming form (e.g., to have a written essay test).
My question is, in my scenario, I think the frame which does the major user input work will never session expire, because the other frame will refresh? Is that understanding correct? My confusion is, I am not sure whether in another frame posting to some other URL in the same web site will block the other frame from session expire?
thanks in advance,
George
You are correct, that will keep the session alive.
The server keeps track of when you last fetched a page and passed your session identifier as a cookie. When it has been longer than the session timeout interval, it will no longer accept the session identifier and considers your session expired.
By hitting the server in the background, you are maintaining the session. Note, you do not have to do a POST. A simple GET will suffice.
Note, I am assuming your session timeout is longer than ten minutes.
Related
Building a web application.
User have access trough their browser to shared resources host on a server, however if UserA is already using Resource1, Resource1 should not be available to UserB until UserA release Resource1 or until a given amount of time.
For this part : I chose to use a MySQL table with a list of tuples (resource,currentuser) and run a cron task to delete expired tuples.
Now I want to be able to notify UserA that UserB wants to access Resource1 and if get not answer from UserA, then UserA lost his lock on Resource1 and then the Resource is then available to UserB.
For this part, I guess I have to use AJAX. I have thought about the following solution :
User's browser make periodic AJAX call (let's say each minute) to prove he is still alive and upon a call, if another User has requested the same resource, he has to challenge a server request in a given amount of time(for example a captcha). If the challenge fails, it means the user is not here anymore (maybe he left his browser opened or the webpage unfocused).
The tricky part is : "he has to challenge a server request in a given amount of time (for example a captcha)". How to do that?
Am I following the best path ?
Yes, what you've outlined is fine. Using ajax is also completely fine, especially if you're simply polling every minute.
For example, let's say you have the following:
setInterval(function() {
$.get('/resource/status', function(response) {
if (response.data.newRequest) {
//This would signal a new request to the resource
}
})
}, 60000)
When handling the new request to access the resource, you could use something like reCaptcha and display that however appropriate (overlay or inline). When you do this, you could also start a timer to determine if it's exceeded the amount of time allocated or not. If it has, then you can do another ajax request and revoke this person's access to the resource, or however you want to handle that.
i would use web sockets to control all the users that need to get the resource.
this way you will know who is connected and using the resource and when he finish using it you can let the next user the resource and so on ,
(this way can tell each user an estimation of how much time it will take him to get the resource and do some progress bar)
I think there're two problems here.
How to notify users that resource becomes available?
Periodic AJAX requests might be okay, but you can also consider long-polling or websockets to get close to notifying waiting users in real time.
How to find out that resource is still used by user?
If you want to catch the moment when human user is not doing anything on page, you can track mouse movement/clicking or keyboard button pressing. If nothing is done for last n minutes, the page might be considered as not active.
If you want to make sure that page is not exploited by automated software, you can ask to fill in captcha once in n minutes when resource is being used.
I am curious about the value of PHPSESSID because, I created a simple login-type web app. When I try to login with different accounts, the value of the PHPSESSID is not changing. I got curious if it does okay or not. Because I tried to login in youtube with different account too. But their SID's differ on each user.
My question is:
1) Is what happening on my web app okay ?
2) Is yes, how can I make a session ids per account/user ?
3) If no, how can I fix it ?
I would really appreciate your suggestions.
It partly depends on exactly how you implemented "login." One way to do it is simply to change the user-identity (which, by definition, is part of the data that is stored in the session), while keeping the same session.
Another equally-valid way to do it is to first update the existing session (to show that the user, in that session, is now "logged off") (maybe...), and then to coin a completely new session-id, thus starting an entirely new session, in which you now "log on."
One advantage of the second approach ... and probably the reason why so many sites do it this way ... has to do with the possibility that the user might wish to open a new browser-window, and to log-in to the application a second time, intending to keep both logins alive at the same time. If the session-id token is part of the URL, or maybe is part of a hidden form or what-have-you, such that both session-id's can be retained independently, it becomes possible for the user to do what he has done without conflict. Two parallel sessions exist. In one, he is logged on as "joe," and in the second, he is logged on as "jeff." And so on. One set of browser-windows (somehow ...) carries the "jeff session" token; others carry the "joe session" token.
Fundamentally, a "session" is just a pool of server-side values, identified by the (PHPSESSID ...) token furnished each time by the client. Exactly how you choose to manage it, is at your discretion. It's a design-decision with no "correct" approach.
I need to implement like/dislike functionality (for anonymous users so there is no need to sign up). Problem is that content is served by Varnish and I need to display actual number of likes.
I'm wondering how it's done on website like stackoverflow. Assuming pages are cached in Varnish (for anonymous users only), so every time user votes on answer/question, page needs to be purged from cache. Am I right? Current number of votes needs to be visible for other users.
What is good approach in this situation? Should I send PURGE to Varnish every time user hits "like" button?
A common way of implementing this is to do the like button and display client side in Javascript instead. This avoids the issue slightly.
Assuming that pressing Like leads to a POST request hitting a single Varnish server, you can make the object be invalidated/replaced in different ways. Using purge and a VCL restart is most likely the better way to do this.
Of course there is a slight race here, where other clients will be served the old page while this is ongoing.
I have MVC app that is basically 1 main view and multiple partial views.
I have this tiny script on a min page that loads partials views asynchronously:
<script>
$(function () {
$('#bookmarks').load('Home/Bookmarks');
$('#calendar').load('Home/Calendar');
$('#gmail').load('Home/Gmail');
$('#weather').load('Home/Weather');
$("#news").load("Home/News");
}
</script>
When I comment them all, I get this (very fast loading):
Now I uncomment just the "Bookmarks" request (just reads small JSON file from local drive), I get this (Bookmarks takes 9ms):
Now I uncomment the "Calendar" request (Google Calendar API), I get this (why Bookmarks latency jumps from 9ms to 1.04s if the requests are async?):
Now I uncomment the "Gmail" request (Google Gmail API), I get this (Bookmarks latency jumps again from from 1.04s to 1.53s?):
Now I uncomment the rest ("Gmail", "Weather" and "News" requests), I get these insane increased latencies all over, the Bookmarks request takes now 5s to execute, instead of 9ms - why?):
You can see the increase in latency for each operation - it looks like these ajax requests are not asynchronous at all :( How is that possible, when AJAX is supposed to be async by default?
I am sure I am missing something here, may jQuery load function is not async, but it's on javascript size, and the delay is on server-side. I am now confused.
Update: obviously jQuery call are async, all load functions are executed at the same time. It's easy. The problem is on the server side. After having dome some tests, it's clear that IIS executes these request synchronously, sequentially one after another in the order it received them from the browser. I have done some additional reading on IIS, and by default IIS apppool has only 1 worker process that is being used, that can fire multiple threads for processing all these requests. But for some reason, the requests are being processed sequentially and not in parallel. I haven't found yet why (if a AppPool worker process can start many threads for simultaneous processing) the requests are still executed sequentially, and how to make these requests to be processed in parallel, and if it's even possible. If someone has any idea how to make thing work properly I would really like to hear. Thanks.
Update After some more reading, found that requests are processed sequentially if Session is enabled. The session object is a single threaded object. The session object cannot be shared by two threads simultaneously. Hence when there are two requests for the same session one is queued while the session object is in use by the other. This sucks :( Any suggestions, IIS experts? :)
Solved
Yes, Session State was the problem! I disabled session state in web.config and removed one line that used Session object to avoid runtime error. Now everything works perfect. The true problem was indeed - that Session state is bound to a single thread, therefore on the server side my app behaved like an old STA fart :)
http://msdn.microsoft.com/en-us/library/ms178581.aspx
Concurrent Requests and Session State
Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished. (The second session can also get access if the exclusive lock on the information is freed because the first request exceeds the lock time-out.) If the EnableSessionState value in the # Page directive is set to ReadOnly, a request for the read-only session information does not result in an exclusive lock on the session data. However, read-only requests for session data might still have to wait for a lock set by a read-write request for session data to clear.
After some more reading, found that requests are processed
sequentially if Session is enabled. The session object is a single
threaded object. The session object cannot be shared by two threads
simultaneously. Hence when there are two requests for the same session
one is queued while the session object is in use by the other. This
sucks :( Any suggestions, IIS experts? :)
Don't use Session. I rarely find cases that justify use of Session, and it's often easy to find storage alternatives that don't have the scalability limitations that you run into with it.
I am wondering why codeigniter session time expiration is not calculating from last user activity.This way i can retain active users. Right now even user performing activities, the session gets expired due to the limitation.
I think you are facing a bug.
Codeigniter's session stores the timestamp of your user's last activity.
The framework use this information to calculate the expiration time.
Also, I've read multiple times that Ajax calls may broke CI sessions. I've also been struggling with CI's sessions and i've been forced to pass $config['sess_use_database'] to false as a workaround.
https://degreesofzero.com/article/fixing-the-expiring-session-problem-in-codeigniter.html
https://ellislab.com/codeigniter/user-guide/libraries/sessions.html
https://ellislab.com/forums/viewthread/182755/#900523
You can check whether user is performing activity or not. If not you can ask the process to sleep for 1 sec. This way the session will never expire.
sleep(1);
In PHP this will work. This way you can make the process sleep when user is idle.