Make old sign-ins stop when they should
A person may leave your app but remain signed in on an old tab, shared computer, or lost phone. Learn how to check that customer information and important actions become unavailable at the right time.
before you start
Test what happens in another tab, on another device, after a long pause, and after a password change. A working sign-out button is only the beginning.
Decide exactly when remembered access should end
in plain words
Your app may remember someone after they sign in. Write down the everyday situations in which that remembered access should stop.
Picture a customer using a shared computer, a worker leaving a laptop on a desk, or a phone going missing. The app may continue to recognize that person even after they walk away. This is convenient because people do not have to enter a password on every page, but it can expose addresses, messages, payment details, or business records when the device reaches the wrong hands. Decide what should happen after sign-out, after the browser closes, after a long period without use, after a password change, and after a person is removed from a team.
Create an account that contains only made-up names and information. Open it on a phone and computer, or in two different browsers, and write down the expected result before each check. The technical name for the temporary remembered sign-in is a session. A session is simply the app accepting that a browser has already proved who is using it. You do not need to understand how it is built. You only need to confirm that the app stops accepting it at every moment your rules say access should end.
- ▸Use made-up information instead of real customer records.
- ▸Test two separate browsers or devices at the same time.
- ▸Write the expected result before performing each check.
common risk
A customer signs out on a shared computer, but another tab still displays their address and order history.
what to do now
List your required stopping points: sign-out, browser restart, inactivity, password change, lost device, disabled account, and removed team permission.
ask your AI
Review my app's remembered sign-in behavior using a test account with made-up information. In plain language, describe what should happen after sign-out, browser close and reopen, a long period without use, password change, account disabling, and removal from a team. Create safe test steps for two browsers or devices, and state the expected result for every step without changing real customer information.
Check every tab and device after sign-out
in plain words
When someone signs out, pages that were already open should not continue showing or changing their account information.
Sign in with the test account in two tabs. In both, open pages that show account details, customer information, messages, or settings. Use the normal sign-out button in one tab. Return to the other tab, refresh every page, and try a harmless action such as changing the test account's display name. The app should ask for the password again before showing current information or accepting a change. Also press the browser's Back button. An old page might remain visible from the browser's short-term memory, but it must not reveal newly loaded information or permit another action.
Repeat the check with two separate browsers or devices. Your app may intentionally keep the second device signed in after a normal sign-out, but users should understand that choice. If you offer “sign out everywhere,” every old browser should stop working. The technical name for making previously accepted remembered access stop is session invalidation. Test the visible result instead of trusting that the button worked: refresh an old page, open a protected page, and attempt a harmless change. Record which devices stopped and which stayed active so an unexpected result is easy to show your AI builder.
- ▸Refresh pages that were open before sign-out.
- ▸Use the Back button and then try to load current information.
- ▸Test both ordinary sign-out and “sign out everywhere,” if offered.
common risk
A worker signs out on a borrowed laptop, yet that laptop can still change the company's phone number from an open page.
what to do now
Run the sign-out test in two tabs and on two devices, recording whether each old page can display current information or make a change.
ask your AI
Improve my app so that after sign-out, every previously open page asks the person to sign in again before loading customer information or accepting changes. Clear browser-held account information that should not remain visible. If the app has “sign out everywhere,” make all previously signed-in browsers stop working. Give me exact tests using two tabs, two browsers, refresh, the Back button, and one harmless profile change.
Limit how long an unattended account stays open
in plain words
A forgotten browser should eventually ask for the password again, especially when the account contains customer information or can move money.
People leave browsers open while taking calls, going to lunch, sharing a family computer, or finishing a workday. Choose how long your app may remain unused before it asks the person to sign in again. Base the decision on what the account can show or do. A page containing only public material can stay available longer than an account containing home addresses, health notes, employee records, payment details, or controls that can spend money. Write the chosen period and the reason for it in plain language so future changes do not quietly replace your decision.
Test the rule instead of only checking its setting. Sign in with the test account, leave the app completely untouched for the chosen period, then refresh a page and attempt a harmless change. The technical name for ending remembered access after a time limit is session expiration. The app should clearly explain that the person must sign in again. Also test active use near the limit. Someone who is currently typing should receive a useful warning when appropriate, and unfinished, non-sensitive text may be preserved when that can be done safely. Customer information should not remain available merely because an old tab was never closed.
- ▸Choose the time according to what the account can reveal or change.
- ▸Test genuine inactivity, not only closing and reopening the browser.
- ▸Check the message shown and what happens to unfinished form text.
common risk
An employee leaves on Friday without signing out, and the next person at the desk can read customer notes on Monday.
what to do now
Choose a documented inactivity period, wait through it with a test account, and confirm that refreshing or making a change requires the password again.
ask your AI
Add an inactivity rule to the signed-in parts of my app. After the chosen unused period, require a new sign-in before loading customer information or accepting any change. Show a clear message, avoid exposing account pages through an old tab, and preserve unfinished non-sensitive form text only when safe. Tell me where to choose the period and provide a timed test using a test account.
Prepare for lost devices and removed people
in plain words
A password change or removal from a team should stop a forgotten phone, old laptop, or former worker from returning.
Use your test account to practice a lost-device situation. Sign in on two devices, change the password on one, and return to the other. Refresh account pages and attempt a harmless action. Decide whether a password change should stop every other remembered sign-in immediately; for apps holding customer information or payment controls, that is usually the safer expectation. Repeat the check after using any account-recovery process. A new password is not enough if the lost browser can continue opening current records without being challenged again.
Next, disable the test user or remove its team permission while another browser remains open. The old browser should lose the removed abilities promptly. The technical name for withdrawing access that was previously accepted is revocation. Write down who can remove a person, respond to a lost device, and verify the result. Keep passwords, payment keys, and access codes that can open information or spend money in the protected place where the app performs trusted work, never in files delivered to a visitor's browser. If your builder exposes them there, removing old sign-ins will not protect those items.
- ▸Change a test password while a second device remains signed in.
- ▸Disable the test user and separately remove a team permission.
- ▸Assign responsibility for lost-device and former-worker checks.
common risk
A former helper disappears from the team list but can still open customer records from a laptop signed in the previous month.
what to do now
Write and rehearse a response that changes the password or removes the person, checks every old browser, and records whether access actually ended.
ask your AI
Review my app's lost-device and removed-user behavior. Make password changes, account disabling, and removed team permissions stop previously remembered browser access before it can load customer information or perform actions. Keep passwords, payment keys, and access codes that open information or spend money out of files delivered to visitors' browsers. Provide safe tests with two devices and a test account, including expected results.
Repeat these checks whenever the app changes
in plain words
A small change to account pages, team settings, or where information is stored can make old browser access last longer than intended.
Repeat the complete test whenever you change sign-in screens, account settings, team permissions, browser storage, hosting, or the service that stores customer information. A visual redesign can accidentally preserve an old page, and a convenience feature can extend remembered access without making that effect obvious. Keep a short record containing the date, the name you gave the current app version, the browsers or devices used, the expected result, and the actual result. A repeatable record helps you notice a change and gives your AI builder a concrete failure to investigate.
Include an outside view in this routine, but understand its limit. VibeCodeWall checks the public app from the outside and watches for important changes over time. It does not need to see private code to point out public changes worth reviewing. This outside check cannot sign in as your test customer or confirm what an old browser can still do. Keep running your own two-device account checks as well. Together, continuous outside watching and repeated test-account checks make it more likely that a future app change is reviewed before real customer information is affected.
- ▸Retest after changes to accounts, teams, storage, or hosting.
- ▸Record the expected and actual result for every app version.
- ▸Combine outside public checking with your own signed-in tests.
common risk
After a redesign, an old account page begins loading customer information again because the earlier stopping rule was accidentally replaced.
what to do now
Add all sign-out, inactivity, password-change, lost-device, and removed-user checks to the list you complete after every important app change.
ask your AI
Create a repeatable app-change checklist in plain language. Include tests for sign-out in another tab, the Back button, a second device, inactivity, password changes, lost devices, disabled users, and removed team permissions. For each test, specify setup, action, expected result, and a place to record the actual result. Use only a test account with made-up information.
Quick checklist
- 01Create a test account containing only made-up information.
- 02Sign in to the test account in two separate browsers or devices.
- 03Sign out in one place, then refresh pages that remain open elsewhere.
- 04Close and reopen the browser without using sign out.
- 05Leave the account unused for the period your app allows, then try it again.
- 06Change the test account password and check every browser that was already signed in.
- 07Disable the test user or remove their team permission, then test old pages again.
- 08Keep passwords, payment keys, and access codes out of files sent to visitors' browsers.
- 09Repeat these checks after every important app change and record the results.
FAQ
Is closing the browser the same as signing out?
Not always. Many apps remember a person after the browser closes. Test closing and reopening separately, especially on shared devices.
How long should an unused account remain open?
There is no single correct period. Use a shorter period when the account shows customer information, payment details, or controls that can make important changes, then test the exact behavior.
Why check another tab after signing out?
A page that was already open can behave differently from a new page. Refreshing it and trying a harmless action shows whether the app still accepts the old remembered sign-in.
Should a password change sign out every device?
That is often the safer choice when an account contains customer information or payment controls. Decide the rule for your app, explain it to users, and verify it with two test devices.
Can an outside public check replace my account tests?
No. An outside check can notice important public changes over time, while your test account confirms what a previously signed-in browser can still see and do.