I've been working on an automatic log-out functionality for my web page. As a part of that, I implemented the window.location.reload(true) in 3 different places in my code. Two of them are automatic, one is attached to a link. The link always works, but the automatic ones don't always work, and I don't understand why.
For the automatic logouts, one set by a debouncer:
var userActionTimeout = debounce(function(e) {
console.log("inaction timeout, reloading page");
window.location.reload(true);
},15000;);
$(document.body).on('mousemove keydown click scroll',userActionTimeout);
Which theoretically should reload the page after a certain amount of inactivity.
The other two uses happen after certain types of AJAX data submission (e.g. blatantly wrong data sent that could only happen if the client was modified) trigger a log out. Of course, any further AJAX submissions are ignored by the server, and the next page the server will serve the client is a login page. In the event this happened inadvertently, AJAX sends the client an error message that includes the following:
refresh to continue session
I also implemented a timeout that also happens if this link is served, which happens after the AJAX response is received:
if (typeof response._forceRefresh !== 'undefined' && response._forceRefresh) {
console.log('reload firing');
/*
some code to insert the link into a spotlight here
*/
setTimeout(function(){console.log('reloading in 3s...');},7000);
setTimeout(function(){
console.log('reloading...');
window.location.reload(true);
},10000);
}
However the issue I'm having is this: Most of the time, the debounce page reload works (tested in firefox & chrome), however occasionally it doesn't. The link always works, but the AJAX response reload is about 50/50. I know it receives the response from the server since the link shows up, but quite often it doesn't actually automatically reload the page.
What is going on?
When ever I get inconsistency on a web page, it usually involves caching that I didn't realize was happening. If you haven't already, look through your project with that in mind and see if there is an effected location that you can force it not to cache a page.
Another idea might be to try using the meta refresh element. There is another thread where this is suggested: auto logout idle timeout using jquery php
Related
I have a blog post edit page on my Next.js project.
My post pages are using the Incremental Static Regeneration feature with a revalidate: 1 second (currently for testing). I'll later be using something like revalidate: 300 (5 minutes).
To update a post, this is what I do:
As an admin, I visit /admin/post/edit/my-post-slug, change whatever I need and save.
After saving, I'm doing a route.push to the post page, to see the new version in /post/my-post-slug.
Here is the code:
const savePost = async (post: BlogPost, router: NextRouter) => {
await savePostAPI(post);
cons POST_ROUTE = "/post/my-post-slug";
router.push(POST_ROUTE);
};
It's all working as intended, with one little caveat.
This is the flow I'm getting:
- I'M ON ADMIN POST EDIT PAGE AND I SAVE
- I GO TO POST PAGE VIA router.push() AND I SEE THE OLD CONTENT (THIS IS EXPECTED)
- WAIT A LITLE
- I HIT REFRESH (F5) ONCE AND I RELOAD THE PAGE AND STILL SEE OLD CONTENT (NOT EXPECTED)
- WAIT A LITLE
- I HIT REFRESH (F5) AGAIN AND SEE THE NEW CONTENT
I'm okay with seeing the old content after router.push(). Next.js is supposed to always serve cached content, even a stale one, before regenerating the new version. But why don't I see the new content right after pressing F5 for the first time? Why do I need to refresh it twice to see the new content? Doesn't router.push trigger a new server request and let the server know that it should regenerate the page (given the fact that is obviously stale, since revalidate:1 will make it stale after 1 second)? Why is that happening?
Instead of using router.push() should I just use window.location.href = "https://www.example.com/post/my-post-slug" to make sure I'll send that request that will trigger the regeneration of the page?
After further investigation, I can confirm.
router.push() implements a client-side transition, and that does not trigger a new getStaticProps call. It only fetches a JSON object with previously generated page props.
I.e: This means that the page will not be revalidated no matter how my client-side transitions you perform.
Either get the fresh data using client-side code, or do a full page reload from time to time. At least 2 will be necessary. The first one will return stale data and will trigger the revalidation process. The 2nd one will get the fresh data.
Yep two page reloads seems required per Next.js docs (which is annoying and not intuitive from a user perspective):
After the 10-second window, the next request will still show the cached (stale) page
Next.js triggers a regeneration of the page in the background.
My solution to this is to use ISR together with SWR which will revalidate the data on mount. This enables the data to stay fresh even on normal routing without the need of full page reloads.
While testing a way in Firefox to reload an HTML page without caching, I've included the following snippet in my code:
<script>
window.setTimeout(function () {
location.reload(false);
}, 5000);
</script>
This reloads the page after 5 seconds, however I get shown the prompt: "To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier."
If there a way to do a silent refresh via Javascript, one that doesn't show any prompt? For instance, if I used the refresh Meta tag (HTML), my browser silently refreshes. I want to approximate that same experience, but via JS (and no cache). BTW mine is a Django web app, and I inject the JS code in my Django template.
This is standard behaviour to protect people from submitting form information more than once (eg, prevent double payments in an ecommerce system). Try telling the Javascript to direct to a 'new' page:
Try using this, setting the url to your own;
window.location = "my.url/index.html?nocache=" + (new Date()).getTime();
Answer borrowed from here where there is also an explanation given for why this works -> How can I force window.location to make an HTTP request instead of using the cache?
Have you tried location.reload (true) ? If set to true, it will always reload from server. Set to false it'll look at the cache first.
You are getting this prompt because you ask to reload a POST request. You should always get this prompt when reloading a POST request, as it is not a safe method
However, if you wish, you can explicitely resend a POST request (though you might have difficulties to find back the POST data previously sent). Or explicitely send a GET request to the same URL.
Im experiencing an extrange behaviour with window.location :
I have an AJAX login, where the user gets redirected after login. The thing is that the process takes less than a second to call window.location='admin/newPage.php', but then the new page status on google dev Net screen says 'pending' for over 7 seconds, then it gets finally loaded.
The server runs fine, internet is fast and window .location gets called fast, I have tried on chrome and firefox and same problem on both ... so Im ruling out all this problems.
Anyone else has experienced this?
OK, I found the problem, Its actually the page being loaded after login.
This page has to run several server side scripts from the google server, then authenticate a user to get some google analytics data, and its being extremelly slow on that.
I just got very confused because the page didnt show for a long time. For me the spected behaviour would be :
redirect instantly -> show blank page for 7 seconds -> show contents
instead of
stay on login for 7 seconds -> show redirect page
After the page loaded again, javascript will trigger to load another page.
So it takes like 2x times to get to the destination if you use javascript redirection.
my requirement is bit of complicated .
an user is accessing the data base using the web browser, while accessing the data base if the user is closed the active page instead of log out the session - that session needs to be log out automatically.
can some one guide me how to make this ?
i am used jquery - in the master page.
onbeforeunload - i am getting message leave the page or stay with this page.
even i am getting this messages while login and and view the home page too.
This is the sample code
window.onbeforeunload = function () {
return 'You want to leave?';
};
see demo here
I think its possible to send an ajax request and you can saw your server that the user closed the browser's tab.
Also this a jquery plugin called jquery.idle, which is used to identify if the user is active.
Refer this Detecting idle time in JavaScript elegantly will gives you more idea.
You man close the browser or navigate to different page within website? If its closing the browser then the session automatically dies.
Also look into global.asax 's sesson_onEnd event.
I want to remove a temp file from the server after the user close the page (I assumed I don't have this callback on the server by default),
I tried to call a server side method using (ICallbackEventHandler implementation) when the user close the page, but the problem is that the server side method doesn't fire in this case (closing the page), it only response if the page still opened. and I don't prefer to stop closing the page until the server response and send its call back to close the page manually.
In case I must stop closing the page, kindly help me with the best way.
Thanks in advance
You can't really know when user is closing the page.
Best you can achieve is using the JS onunload event and in there send AJAX request:
<body onunload="SendRequest();">
And the JavaScript: (jQuery is most simple way)
function SendRequest()
{
var sURL = "http://localhost/Log.aspx?action=unload&t=" + (new Date()).getTime();
$.ajax({ url: sURL });
}
This event will be triggered whenever user navigates away from the page: F5, Back, Forward, clicking a link, submitting a form etc... you can improve the code to ignore cases like clicking something in the page let me know if relevant and I'll edit with proper code.
I think it might just be more prudent to delete the file after some time period, say 24 hours, on a recently-accessed basis. That is, all files who haven't been touched in 24 hours get deleted.
Alternatively, you could poll with AJAX, and as soon as you don't receive a request with the user's identifying token within some time threshhold > the polling interval, delete the relevant file.
In a similar situation in my first job, I left the copy on the server and whenever that temp directory was called again from that page, I deleted any files older than 72 hours. Not very good, but was accepted in that situation.
If you need to delete it on the server when you know the user doesn't require it any more, you could use a session listener, see this question.