School software signs you out automatically because your session has expired — a security measure so an unattended login cannot be reused; "page expired" means a form was submitted after its security token lapsed. In EDUBase Cloud, staff sessions expire, so sign in again with your institute code and username and re-submit the screen.
What does "session expired" actually mean?
When you sign in to any web portal, the server issues your browser a session — a temporary pass that says "this person has already proved who they are". That pass is intentionally short-lived. If it never expired, a login left open on a shared front-desk PC, or a laptop that walked out of the building, would stay usable indefinitely.
EDUBase Cloud staff sessions expire. Once that happens, the next click is bounced back to the login page. Nothing you had already saved is lost — saved records are on the server. What is lost is anything typed into a form and not yet saved.
This is standard for finance-grade software. A fee counter screen with rights to record payments, approve discounts or change salary plans is exactly the screen you do not want left open and signed in.
- Session expiry protects records you have rights to change, not just your own profile
- Saved data is never affected; only unsaved form input is lost
- Re-signing in with the institute code, username and password restores you to the same rights and campus scope
Why does the portal say "page expired" instead of logging me out?
"Page expired" is a slightly different event. Most modern web applications attach a one-time security token to every form so that a third-party site cannot trick your browser into submitting it — the general protection is called CSRF (cross-site request forgery). If the page sat open long enough for that token to lapse, the server rejects the submission and shows a page-expired message.
In practice this happens when a challan form, an admission form or a marks entry screen has been open for a long stretch — a lunch break, an overnight tab, a browser restored from a previous day. The remedy is the same every time: reload the screen so a fresh token is issued, sign in if asked, and enter the data again.
It is worth warning fee office and exam staff about this habit specifically, because those are the screens most often left open with a lot of typed-in work on them.
- Reload the page rather than pressing back and re-submitting
- Do not keep entry screens open across days; open them when you are ready to work
- For long tasks such as marks entry, save in batches rather than at the very end
Which everyday causes have nothing to do with the software?
Before treating repeated logouts as a fault, rule out the ordinary causes first. Most of them sit on the device or the network, not on the server.
Shared computers are the biggest source of confusion in school offices. If two staff members use the same browser profile and one signs in with a different account, the other is pushed out. Give each staff member their own login — EDUBase allows unlimited staff logins with per-user, per-screen and per-action rights and campus scope — and, where possible, their own Windows or browser profile.
Browsers that clear cookies on close, private/incognito windows, aggressive "cleaner" utilities and clock settings that are badly out of date will all break sessions. So will an unstable internet connection, which can make a perfectly valid session look dead mid-save.
- Two people sharing one browser profile signing in to different accounts
- Incognito or private windows, which discard the session when closed
- Browser or third-party cleaner software set to clear cookies and site data
- Device date and time significantly wrong
- Patchy connectivity at the moment a form is submitted
- An old tab restored from a previous session still holding a stale token
How should an admin check access problems before raising a request?
Work through the simple checks in order; most access complaints are resolved in the first three.
If a staff member says they cannot get in at all, rather than being logged out mid-work, the issue is usually the credentials themselves. Staff sign in with the school's institute code plus their username and password, and staff passwords are reset by an admin from the portal — nobody should be circulating a shared password. Parents are different: they log in to the Parents App with a rotating one-time code sent to the registered mobile, and the Parent App OTP Portal lets staff look up or issue that code when the SMS has not arrived.
If you need to see whether something actually changed, User Logging records who created, changed or deleted what, with the record opened and the change highlighted, and a daily summary reaches the owner.
- Confirm the institute code, username and spelling of the password
- Have the user close every tab, open one fresh tab and sign in again
- Check whether the person is on a shared device with somebody else's session
- Confirm the user's privileges and campus scope actually include the screen they want
- For parents, check the OTP portal and the registered mobile number
- Ask the in-app AI assistant, which answers how-to questions in English or Roman Urdu with links to the exact screen and tutorial video
What can the school do to reduce interruptions?
Session expiry is not something to switch off; it is the control that makes it safe to give a fee clerk or an HR officer real rights. What you can do is reduce how often it interrupts real work.
Give every staff member a personal login with only the screens they need. Beyond fewer logout surprises, it makes User Logging meaningful, and it means an approval step for payments, discounts, salary changes or admissions genuinely involves a second person.
Attendance tablets, gate devices and sender phones are handled differently: they hold their own revocable device tokens, so a lost tablet is cut off without changing anyone's password. All portal, app and integration traffic runs over HTTPS.
- One login per staff member, never a shared "office" account
- Sign out at the end of a shift on counter and front-desk machines
- Keep browsers reasonably current and stop cleaner tools from wiping site data
- Train staff to save in stages on long entry screens
Common login and access symptoms and what usually causes them
| Symptom | Most likely cause | What to do |
|---|---|---|
| Sent back to the login page mid-work | Session expired after inactivity | Sign in again with institute code, username and password; re-enter unsaved data |
| "Page expired" on submitting a form | Form's security token lapsed while the page sat open | Reload the screen to get a fresh page, then enter and save again |
| Logged out whenever a colleague signs in | Shared browser profile on a shared PC | Give each staff member their own login and, ideally, their own device profile |
| Session lost every time the browser closes | Incognito window or cookie-clearing settings | Use a normal window; exclude the portal from cleaner tools |
| Cannot sign in at all | Wrong institute code, username or password | Have an admin reset the staff password from the portal |
| Screen missing after successful login | Privileges or campus scope do not cover that screen | Review the user's per-screen and per-action rights and campus access |
| Parent cannot open the Parents App | One-time code not received on the registered mobile | Use the Parent App OTP Portal to look up or issue the code; check the number on file |
| Gate tablet stops marking attendance | Device credential revoked or removed | Check Registered Devices and re-issue a device token for that tablet |
Related
- Training & Support — Live Google Meet training, module video playlists, in-app docs and an AI assistant, with WhatsApp and phone support in working hours.
- Cloud & Infrastructure Services — Managed hosting, one database per school, backups, monitoring and secure networking for education workloads.
- Users privileges security on edubaseems.com
- Hosting security on edubaseems.com
- Parents app controls on edubaseems.com
- Ai assistant on edubaseems.com
- School setup on edubaseems.com