【问题标题】:session_destroy not unsetting the session_idsession_destroy 没有取消设置 session_id
【发布时间】:2012-01-28 08:10:46
【问题描述】:

我正在开发一个在线订票系统,在成功预订后(付款后)我想清除会话 ID。但问题是我无法清除它,尽管我使用了session_destroy() 来破坏会话。

注意:我已经回显了 session_id 以检查它是否重置。

网址:http://7sisters.in/7sislabs/

function book_final_tickets()
{

    //var_dump($_SESSION);
    $session_id = session_id();


    $sql = "
        UPDATE
            tbl_seat_book
        SET
            final_book = 'Y'
        WHERE
            session_id = '$session_id'
    ";


    //session_unset();

    if($r = $this->db->executeQuery($sql)){
        if(session_destroy()){
            unset($session_id); 
            echo 'Booking successfull';
        }
    }
}

【问题讨论】:

  • 你的查询已经执行,并且打印了 echo 语句?
  • 是的...但是我想在成功订票后销毁会话。
  • 如果您的 echo 语句被打印,那么您的会话应该已经被销毁。尝试调试为什么会发生这种情况。
  • 回显显示相同的 session_id ,尽管它已被销毁(成功预订后)
  • 尝试使用session_unset()。另外,尝试在session_destroy() 之前调用session_start()

标签: php session sessionid


【解决方案1】:

使用 session_destroy() 销毁会话后,这对我有用:

setcookie('PHPSESSID',"",time()-3600,'/');

对我来说,关键是将路径设置为“/”。这是真正摧毁cookie的唯一方法。

【讨论】:

  • 谢谢!!这对我来说是最好的答案......恭喜:)
【解决方案2】:

代替

session_destroy();

我宁愿只做一个

session_regenerate_id(true);

你会得到一个新的 session_id

【讨论】:

    【解决方案3】:

    session_destroy() 单独不会删除客户端 cookie,因此下次用户访问时,他们仍然会设置相同的会话 ID(但他们的服务器端会话信息将被销毁)。

    来自文档(重点是我的):

    session_destroy() 销毁所有与当前关联的数据 会议。它不会取消设置与 会话,或取消设置会话 cookie。 ...为了杀死 session 完全一样,想注销用户,session id 也必须 取消设置。如果使用 cookie 来传播会话 id(默认 行为),则必须删除会话 cookie。

    您可以使用session_regenerate_id(true) 生成新的会话ID 并删除旧的。请注意,这会将 $_SESSION 中的所有信息保留为新会话 ID 的一部分,因此如果您想清除会话信息并重新开始,您仍需要使用 session_destroy

    例如

    <?php
        session_start();    
        $_SESSION['blah'] = true;
    
        var_dump(session_id()); // q4ufhl29bg63jbhr8nsjp665b1
        var_dump($_SESSION);    // blah = true
    
        session_unset();
        session_destroy();
        setcookie("PHPSESSID", "", 1); // See note below
        session_start();
        session_regenerate_id(true);
    
        var_dump(session_id()); // gigtleqddo84l8cm15qe4il3q3
        var_dump($_SESSION);    // (empty)
    ?>
    

    并且标头将显示客户端更改的会话 ID:

    请求标头
    Cookie:PHPSESSID=q4ufhl29bg63jbhr8nsjp665b1

    响应标头
    设置 Cookie:PHPSESSID=已删除;过期=格林威治标准时间 2010 年 12 月 27 日星期一 16:47:57
    PHPSESSID=gigtleqddo84l8cm15qe4il3q3;路径=/

    (你可以在没有setcookie() 调用的情况下离开这里,因为无论如何你都在创建一个新会话,所以 cookie 将被新 ID 覆盖,但是显式销毁旧 cookie 是一个好习惯)。

    【讨论】:

      【解决方案4】:

      session_start 之前调用session_id,并手动设置session_id

      示例 1:将使用相同的 session_id

      <?php
      session_start();
      
      echo session_id(); //4ef975b277b52
      
      session_destroy();
      
      session_start();
      
      echo session_id();  //4ef975b277b52
      ?>
      

      示例2:手动设置session_id(在session_start()之前调用)

      <?php
      session_id(uniqid()); 
      session_start();
      
      echo session_id(); //4ef975d3d52f5  (A)
      
      session_destroy();
      
      
      session_id(uniqid());
      session_start();
      
      echo session_id();  //4ef975d3b3399 (B)
      ?>
      

      (A) != (B),因此您可以手动设置 session_id,请参阅http://php.net/manual/en/function.session-id.php 了解更多信息。

      另一种解决方案,不要使用 session_id() ,只需创建新的会话数组:

      <?php
      $_SESSION['booked'] = false;
      
      if($r = $this->db->executeQuery($sql))
      {
          $_SESSION['booked'] = true;
          echo 'Booking successfull';
      }
      ?>
      

      【讨论】:

      • 使用 session_id(uniqid()); 手动设置会话 ID 是个坏主意。 uniqid() 不是很随机,因为它是基于时间戳的。让 PHP 使用 session_regenerate_id() 自动处理 session_id 的生成要好得多,因为那时您可以使用更好的熵源(例如 ini_set('session.entropy_file', '/dev/urandom');)。
      • Rich,session_regenerate_id() 有它自己的问题,甚至its own doc page 也不鼓励使用它。然而,人们仍然可以使用session_id(session_create_id()) 让 PHP 完成它的工作,至少对于 ID 生成部分。 (不幸的是,要解决可靠性问题本身,还有更多工作要做。请参阅文档页面。)
      【解决方案5】:

      试试这个:

      unset($session_id);
      session_destroy();
      

      【讨论】:

      • 我不认为 $session_id 是这里的问题......这太明显了。我认为持有会话 id 的 cookie 仍然存在,在 session_destroy();
      猜你喜欢
      • 2014-07-20
      • 1970-01-01
      • 1970-01-01
      • 2012-09-24
      • 2014-08-04
      • 2020-11-26
      • 2018-05-16
      • 1970-01-01
      • 2012-12-02
      相关资源
      最近更新 更多