Hey there, let's break down why your session variables are showing up empty in the second file—this is a super common gotcha, so let's walk through the most likely fixes step by step:

1. You're Regenerating the Session ID Too Early #

The biggest red flag here is your order of operations in the second file:

session_start();
session_regenerate_id(); // This is causing issues!
var_dump($_SESSION);

session_regenerate_id() creates a new session ID, and while the default behavior doesn't delete the old session, it can create a race condition where the new session hasn't finished loading the old data yet. Even worse, if you ever pass true as an argument (to delete the old session for security), you'd lose all your saved variables immediately.

Fix: Move the session regeneration to after you've verified your session variables exist:

session_start();
// First confirm your session vars are present
if(!isset($_SESSION['user']) || !isset($_SESSION['role'])) {
    header(':', true, 401);
    exit;
}
// Now regenerate the ID to block session fixation attacks
session_regenerate_id(true); // True deletes the old session for extra security
var_dump($_SESSION); // This should now display your user/role variables

2. Session Cookie Configuration Mismatches #

If your two PHP files live on different paths or subdomains, your session cookie might not be getting passed between them. Check these critical settings (either in your php.ini or override them with ini_set() in code):

• session.cookie_path: Set this to / (the root) so the cookie is accessible across all parts of your site. If it's locked to a specific subdirectory like /login/, files outside that path won't see the cookie.
• session.cookie_domain: If your files are on subdomains (e.g., login.yoursite.com and api.yoursite.com), set this to .yoursite.com (note the leading dot) to share cookies across all subdomains.
• session.cookie_secure: If your site uses HTTPS, this should be On—but if you're testing over plain HTTP, setting this to On will prevent the cookie from being sent entirely.

3. Session Storage Permissions #

If your server can't write session data to the storage directory, your variables never get saved in the first place. Here's how to verify:

• Run phpinfo() to find your session.save_path (usually /tmp/ on Linux systems).
• Check that the web server user (like www-data or apache) has write permissions to that directory.
• In your first file, add session_write_close() right after setting session variables to force immediate saving:

  session_start();
  $_SESSION['user'] = $row['user'];
  $_SESSION['role'] = $row['role'];
  session_write_close(); // Force the server to save session data right away
  

4. Accidental Output Before session_start() #

Even a single space, newline, or HTML tag before the opening <?php tag in either file will send HTTP headers early, which breaks session cookie setup. Double-check both files:

• No characters (even invisible ones like spaces) before the opening <?php tag.
• No echo/print statements, error messages, or whitespace output before session_start().

5. Disabled Cookies (Unlikely But Worth Checking) #

If your browser has cookies disabled, or your server has session.use_cookies set to Off, the session ID won't be passed between requests. Test this by checking if $_COOKIE[session_name()] exists in the second file—if it doesn't, cookies are the root issue.

内容的提问来源于stack exchange，提问作者benNek