Today, I came up with an issue which yields localstorage to crash.
I have username and password credentials stored in localstorage. When user refreshes the page, system programatically logins by using these credentials stored in localstorage.
But when user spams refresh button for 4 or 5 times(without letting page to be loaded), localstorage remove credentials.
To solve this problem, I've added breakpoints in every localstorage.removeItem to see if I delete this credentials by mistake, but non of them executed.
So my question is, is there any other way to remove localstorage's credentials or am I facing with some kind of bug?
I'm using Google Chrome v35.0.1916.153.
Thanks.
Related
When the logged-in user clicks on the browser back button, he falls back to the login page from the main page he entered. And this happens without being routed in any way and running the controller functions because the browser's cache is loaded. I tried to clean all cache via middleware, but it didn't happen. Then, if the user tries to fill in his information from the login page and enter again, 419 page expired error is coming. I tried to do this with session checking method. I gave a key to the session, but the controller didn't recognize the key in the session because it didn't work. I looked through the history library (history.js) but couldn't find the solution as I wanted. My aim was to log out when the user presses the browser back button and show a box like Are you sure you want to exit, and then allow him to log in again. unfortunately, I couldn't do this in laravel I really need help and I can't find solution I think it can be done with AJAX or JS but I'm not sure. I am suffering from this situation for days. Your help will be rewarded. Thank you to everyone who has already read.
I have a problem and after some research online was unable to find other people with this same issue.
I'm designing a site that has sensitive data the user's work with in the page content. It uses CodeIgniter as well as CodeIgniter's session and cookie implementations to track user activity and determine when a session has expired. when sessions expire, the user has to log in again either through a sign-in portal or through a sign-in popup.
My issue is if someones working on their computer then just gets up and walks away from the browser, the session expires, but they didn't realize the session would expire then return to their computer to finish their work. There is a regular ajax call that checks if the user has been inactive, and if the time threshold is reached their session data will be erased and the session is no longer active. There is then a popup window prompting the user to sign in again if they want to keep working.
The problem is, how do I protect any sensitive data in the HTML in the meantime? You might think if the session expires just redirect the user away from the page, but if they're in the middle of something I don't want to erase all of their work. I could try just hiding the HTML using javascript, but then someone could just open the inspector to see the HTML. is there some way I could prevent anyone from seeing the page data at all unless the sign in a popup is completed?
Thanks for any input.
I don't know of anyway to protect their work like you're asking.
I'd suggest saving the users work in a draft format, as they enter it. Then if they walk away and get logged out it doesn't matter, the work is still there when they log on next.
I have searched this for long time, unfortunately I couldn't find a helpful answer. when a user accessing my asp.net mvc 5 application and do a clear cookies from his browser, how can I detect that the cookies has been flushed and sign out the user without refreshing the page?
I have noticed this feature in Gmail. it automatically detects cookies flushing and redirect you to the login page.
Any thoughts?
Almost every login pipeline use cookie.
Usually you store some sort of userHash or even loginToken in cookies on login action.
So you don't detect that cookies flushed. You just check cookie exists on every request and if not - you redirect user.
How can I prevent the user login into my website, even if he uses another login?
I can prevent in the same browser, using session/cookies. And also I can prevent the same user, using a DB solution.
But I dont know how to prevent with another browser and/or another user.
Does anyone has any ideas? Im actually using asp and javascript, but im open to another platforms.
Tks,
MC
Actually if user have 2 different accounts and uses 2 different computers from LAN(or WiFi on that matter) based network only solution for you is to insert into database open session ID and correlated IP, date time when session got opened.
You also need to make sure that you set open session to 0 once it get closed or just times out.
Session and cookies will help you only to prevent user to use same browser from same computer.
I want to logout user if browser is closed and force it to login again on turning the browser on.
if (!(isset($_SESSION['admin']))) {
header ('Location: login.php');
}
This doesn't work - because turning off the browser does not mean drop the sessions on server - if I understand well a lot of posts on SO and outside.
Using javascript to delete sessions just before closing the browser often doesn't work because browser will not wait to execute any code if user clicks to close the browser.
Second option is keeping server session alive by sending a js code from client (setInterval - ajax).
Problem here is scenario with multiple pages open on different tabs/windows, i.e. interference between multiple setInterval functions.
I also tried this:
session_set_cookie_params(0);
session_start();
This also doesn't work - after turning off/on the browser index.php is open without redirecting to login.php.
The reason is maybe browser option to automatically restore previously loaded pages.
So, what to do ?
#Axalix wrote:
If session relies on cookies, you just need to keep expiry date empty, then when browser / tab is closed this cookie will be removed from a browser automatically. That's a standard browsers behavior. Yes, the server will still keep it, but since browser doesn't have it, user will need to relogin
You responded:
could that be a possible security issue because cookies are javascript stuff - chengable by client?
Yes cookies can be changed by the client but Axalix' answer from the comments is still the best if you intend to use $_SESSION. If you want to end session on browser exit so that a 2nd user doesn't come later and take over the old session, then you must trust the owner of the session with the session cookie.
If you really want to break access as soon as the client leaves, then $_SESSION is not the best tool to track login state. Instead you could use WebSockets. The socket remains open as long as the webpage is open. Once the socket closes, you can invalidate any login state.
This may be more trouble than it's worth though, so think hard about whether it is really that important. As an alternative, you could use SessionStorage, which is destroyed when the browser closes but it's also available to the user (so a user could just copy and save what's in SessionStorage, then recreate it later).
Basically you need to trust the user who provided you the username and password.
There are couple options but all end up same way. you can either store something in sessionStorage to check session. when browser is closed session storage will be wiped out. or you can add a hidden input field and assign a value per session. if page is newly loaded and value exists that means session is still active, so you can redirect to logout and show login page in either way. but second option may not be usefull if your app has page reloads. I think sessionStorage would be your answer. set session on sessionStorage on login, if it is empty. then check session storage on page load. if it is empty that means user first time on there, since page reload will keep the value.
When Google Chrome is configured to re-open all previous tabs, it won't delete your session cookie. See for example this question asked 5 years ago, but stil an issue (just verified, Google didn't change that behaviour). Unfortunately you can't do much about this behaviour (as far as I know). Without deleting that cookie your session still remains open (unless it is deleted server-side during clean-up).
Best solution to handle an automatic logout is to store a 'last activity time' in your session, update it in every request and in your 'is logged in check' verify that the last activity was not more than, say, 15 minutes ago. If it is more than 15 minutes ago, you could send him to the login.php.
To improve this furthermore (and if this is really an issue for you), you can use a setInterval in javascript to send keep-alive AJAX-calls to the server every 30 seconds or so. In that way you can lower the 'last activity time' (either real activity or automated) limit from 15 minutes to 2 or 1 (leave some room for network hickups).