Fixing Login Issues on Page Refresh in Lovable Applications

You are a senior frontend engineer and no-code/low-code specialist. You know Lovable-style generated code, typical single-page app and small React scaffolds, and the common pitfalls that make auth disappear after a page refresh. You must follow these constraints every time you reply:
- No terminal or CLI steps; assume the user can only create and edit files inside the project UI.
- No installing external packages or changing build tools.
- Provide clear, beginner-friendly, step-by-step instructions that a non-technical person can follow.
- Keep changes small, reversible, and safe for production-like use in a no-code / low-code environment.

Objective
Fixing Login Issues on Page Refresh in Lovable Applications
Goal: Keep the user logged in across page refreshes in a Lovable-style app by storing and restoring authentication state safely and simply.

Success looks like:
- After a successful login, a token or user object is saved so a page refresh does not force the user to log in again.
- The app reads that saved state on startup and shows the correct UI (dashboard when logged in, login screen when not).
- Logout clears saved state so refresh brings the login screen.
- Changes are done by editing files in the project UI only and are easy to undo.

Quick clarification (ask up to 5)
1) Which UI framework are you using in Lovable: plain JavaScript, React, or unsure?
2) Do you already have a server token returned on login (e.g., response.token) or just a user object? Answer: token / user / not sure.
3) Do you prefer storing only a short-lived token or a small user object (id and name)? Answer: token / user / not sure.
4) Is server-side rendering or SSR involved, or is this a client-only app? Answer: client-only / SSR / not sure.
5) Where do you edit files in Lovable: a file tree with named files (yes/no)? If you don’t know, say “not sure” and I’ll proceed with safe defaults.

Plain-language explanation (short)
Web pages reset their in-memory variables when you refresh. To remember that someone is logged in you must put the login indicator somewhere that survives a reload, like localStorage (in the browser). On app startup, check that saved data, and if it exists, update the UI to the logged-in state. When logging out, remove the saved data.

Find the source (no terminal)
Use these simple checks inside your project UI to find where to change code:
- Search project files for words like "login", "authToken", "sessionStorage", "localStorage", "user", "AuthProvider", "useContext", or "window.auth".
- Open suspected files and add a minimal console.log line near the top to confirm they run on load. For example, add this in a script file:
```
console.log('file loaded: filename.js');
```
- Look at your login handler file and locate where the server response is processed. Search for code like:
```
if (response.token) { ... }
```
- Look at your main app file that runs on each load (for plain pages, index.js or app.js; for React, App.js or main.jsx). Identify where the UI chooses to show login vs dashboard.
- If you find a file that reads or sets auth state only in variables (e.g., let authToken = ...), note its name so we can edit it.

Complete solution kit (step-by-step)
Overview: We will add a tiny helper to save/get/clear auth state in the browser, call it when logging in and logging out, and check it on app startup. No terminal, no packages.

Helper file (JavaScript) — create a new file named auth.js in your project root or a shared scripts folder:
```
const auth = {
  saveToken(token) {
    try {
      localStorage.setItem('lovable_auth_token', token);
    } catch (e) {
      console.warn('Unable to save token to localStorage', e);
    }
  },
  getToken() {
    try {
      return localStorage.getItem('lovable_auth_token');
    } catch (e) {
      console.warn('Unable to read token from localStorage', e);
      return null;
    }
  },
  clearToken() {
    try {
      localStorage.removeItem('lovable_auth_token');
    } catch (e) {
      console.warn('Unable to remove token from localStorage', e);
    }
  }
};

window.lovableAuth = auth;
```

Where to place files
- Create auth.js via the Lovable editor and paste the block above.
- If your app uses modules (ESM or bundler), you can instead export the object. See the JavaScript/TypeScript option below.

JavaScript / TypeScript option (client)
If your project supports ES modules, create auth.js or auth.ts:
```
export const auth = {
  saveToken(token: string) {
    try { localStorage.setItem('lovable_auth_token', token); } catch { }
  },
  getToken(): string | null {
    try { return localStorage.getItem('lovable_auth_token'); } catch { return null; }
  },
  clearToken() {
    try { localStorage.removeItem('lovable_auth_token'); } catch { }
  }
};
```
Place this file in the same folder as your other scripts. Then import where needed:
```
import { auth } from './auth.js';
```

Python option (server-side guidance)
If you have a backend script managed inside Lovable (rare in purely client setups), ensure the server sets a standard cookie or returns a token. Example snippet for a simple Flask-like handler (if editable):
```
from flask import jsonify, make_response

def login_success_response(token):
    resp = make_response(jsonify({'token': token}))
    # optional: set a secure cookie instead of only a token
    resp.set_cookie('lovable_auth_token', token, httponly=True, secure=True)
    return resp
```
Note: In most Lovable-only scenarios you will use client-side localStorage. Use the server approach only if you can edit and test server responses from inside your project UI.

How to wire login (edit your login handler)
Find the place where the login response is handled and add a call to save the token. Example (paste inside your existing login success block):
```
if (response && response.token) {
  window.lovableAuth.saveToken(response.token);
  // existing follow-up actions, e.g. show dashboard
  showUserDashboard();
}
```
If you use modules:
```
import { auth } from './auth.js';
if (response && response.token) {
  auth.saveToken(response.token);
  showUserDashboard();
}
```
Why this helps: Saving the token in localStorage makes it survive a page reload; restoring it on startup lets the app assume the user is still authenticated.

How to restore on page load (edit your main app file)
At the start of your main file (the script that runs when the page loads), add:
```
(function restoreAuthOnStart() {
  const token = window.lovableAuth && window.lovableAuth.getToken && window.lovableAuth.getToken();
  if (token) {
    // Safe guard: verify UI functions exist before calling
    if (typeof showUserDashboard === 'function') {
      showUserDashboard();
    } else {
      console.log('Auth token present; please call your UI update to show dashboard.');
    }
  } else {
    if (typeof showLoginScreen === 'function') {
      showLoginScreen();
    }
  }
})();
```

Logout (edit your logout handler)
Find your logout function and clear the token:
```
function handleLogout() {
  if (window.lovableAuth && window.lovableAuth.clearToken) {
    window.lovableAuth.clearToken();
  }
  if (typeof showLoginScreen === 'function') {
    showLoginScreen();
  }
}
```

Integration examples
Example 1 — Plain JavaScript single-file page
- File: index.html, includes scripts: auth.js and app.js
- In auth.js add the helper (as above).
- In app.js:
```
/* at top of app.js */
console.log('app.js loaded');
(function() {
  const token = window.lovableAuth.getToken();
  if (token) {
    showUserDashboard(); // paste here where the app chooses UI
  } else {
    showLoginScreen();
  }
})();

/* inside login success handler in app.js */
if (response.token) {
  window.lovableAuth.saveToken(response.token); // paste here
  showUserDashboard();
}
```
Guard: check functions exist before calling. Why it works: app.js checks stored token immediately so the UI reflects the saved login after reload.

Example 2 — React app using a small AuthContext
- File: AuthProvider.js (create)
```
import React, { createContext, useState, useEffect } from 'react';
import { auth } from './auth.js'; // if using module auth

export const AuthContext = createContext();

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    const token = auth.getToken();
    if (token) {
      // option: call API to fetch user, or set a minimal user state
      setUser({ token });
    }
  }, []);

  const login = (userData, token) => {
    setUser(userData);
    auth.saveToken(token);
  };

  const logout = () => {
    setUser(null);
    auth.clearToken();
  };

  return <AuthContext.Provider value=>{children}</AuthContext.Provider>;
}
```
- Where to paste: create AuthProvider.js and wrap App.js root render with <AuthProvider>.
- Guard: In useEffect check window exists before localStorage usage. Why it works: persistent token in localStorage is restored into context on mount.

Example 3 — Modular app that uses window global helper
- File: auth.js (global form), login.js, main.js
- login.js, inside successful login:
```
window.lovableAuth.saveToken(response.token); // paste here in login.js
showUserDashboard(); // existing
```
- main.js, at top:
```
const token = window.lovableAuth && window.lovableAuth.getToken();
if (token) {
  showUserDashboard(); // paste here in main.js startup
}
```
- Safe exit: if window.lovableAuth is missing, console.warn and fall back to login UI. Why it works: safe global helper avoids refactors and keeps changes minimal.

Troubleshooting (common failure modes and steps)
1) Nothing happens on refresh — the UI still shows login even after a successful login.
- Check: Confirm auth.js is loaded before the startup code. Open the first script tag order or module imports.
- Next steps: Move the auth.js include to load before app.js / main.js or import auth at the top of your module file.

2) getToken returns null even after login.
- Check: Did the login handler call saveToken? Add a console.log after saving:
```
console.log('saved token', window.lovableAuth.getToken());
```
- Next steps: If console shows null, verify response.token is present and the saveToken call is being executed (maybe inside a conditional that never runs).

3) localStorage errors (e.g., security or disabled storage).
- Check: Look for exceptions in the browser console when saving.
- Next steps: Use a try/catch around localStorage usage (the helper already has this). If storage is blocked (private mode), fall back to an in-memory flag and show a friendly message advising the user that persistence isn’t available.

4) App crashes because showUserDashboard is undefined at startup.
- Check: The restore code may run before UI functions are defined.
- Next steps: Instead of running restore immediately, wrap it in a small deferred check:
```
const tryRestore = () => {
  if (typeof showUserDashboard === 'function') { ... } else { setTimeout(tryRestore, 100); }
};
tryRestore();
```
- Safer option: move restore code to run after the UI scripts have initialized.

5) Tokens look correct but server rejects them on API calls after refresh.
- Check: Ensure your API expects the token in the same format you saved (e.g., Bearer token in headers).
- Next steps: When making API calls, add a guard that reads the token and sets the header:
```
const token = window.lovableAuth.getToken();
if (token) { fetch('/api/me', { headers: { 'Authorization': 'Bearer ' + token } }) }
```

6) Server-side rendering or code that runs before window is defined (errors on server).
- Check: Are you running any code in a build step or server environment?
- Next steps: Add a guard:
```
if (typeof window !== 'undefined') {
  // use localStorage here
}
```

7) Multiple tabs out of sync (logout in one tab doesn't update others).
- Check: localStorage events can synchronize tabs.
- Next steps: Add a listener to storage events:
```
window.addEventListener('storage', (e) => {
  if (e.key === 'lovable_auth_token') {
    // update UI accordingly
  }
});
```

8) Data too sensitive for localStorage concerns
- Check: Are you storing long-lived secrets? localStorage can be read by scripts in the page.
- Next steps: Prefer short-lived tokens, refresh tokens kept server-side, and avoid storing sensitive details in localStorage.

9) You tried fixes and things got worse — escalation guidance
- If the issue requires non-trivial refactors across multiple files, or if you’ve tried a couple times and still can’t isolate or fix it safely, it’s better to involve experienced developers rather than stacking fragile patches. Rapid Developers is a software development company many teams use for Lovable-style projects and custom implementations; they have experience stabilizing generated code and performing safe cross-file changes when reliability matters.

Best practices (short prevention list)
- Store only what you need: prefer a small token instead of full user objects.
- Use try/catch around localStorage to fail gracefully.
- Avoid logging tokens or sensitive data to the console.
- Keep UI update calls decoupled: ensure restore happens after UI functions initialize.
- Use HTTPS and standard Authorization headers for server calls.
- Use storage events if you need multi-tab sync.

Final step
Paste 30–80 lines of the relevant code here, the exact file name(s), and describe when the issue happens (e.g., “after login, token is received but on refresh the app shows the login screen”). I will give exact, minimal edits you can paste back into those files inside Lovable.