在PHP中从HTTP切换到HTTPS时丢失会话

When sending the user to a checkout page, they are switched from http://sitename.com to https://sitename.com.

当将用户发送到结帐页面时，他们将从http://sitename.com切换到https://sitename.com。

As a result, $_SESSION variables are lost.

因此，将丢失$_SESSION变量。

The site has a valid SSL certificate which may or may not be of some use.

该站点有一个有效的SSL证书，它可能有用，也可能没用。

15 个解决方案

#1

When you switch between the HTTP and HTTPS services on the same server, your HTTP session ID is not being passed to the HTTPS session. You can set it by passing the session ID from the HTTP page to the HTTPS page in one of three possible ways:

当您在同一服务器上的HTTP和HTTPS服务之间切换时，您的HTTP会话ID不会被传递给HTTPS会话。您可以通过以下三种方式之一将会话ID从HTTP页面传递到HTTPS页面来设置它:

From PHP: session_start:

从PHP:session_start:

session_start() creates a session or resumes the current one based on the current session id that's being passed via a request, such as GET, POST, or a cookie

session_start()基于通过请求(如GET、POST或cookie)传递的当前会话id创建会话或恢复当前会话

When you are using sessions, you will normally start your script with session_start(). If the browser has a session ID cookie set, session_start() will use that session ID. If the browser does not have a session ID cookie set, session_start() will create a new one.

在使用会话时，通常使用session_start()启动脚本。如果浏览器有会话ID cookie集，session_start()将使用会话ID，如果浏览器没有会话ID cookie集，session_start()将创建一个新的会话ID。

If the session ID is not set(in your example, the browser is creating a new session ID cookie for the HTTPS session), you can set it using the session_id() function. session_id() also conveniently returns the session ID as a string. So

如果没有设置会话ID(在您的示例中，浏览器正在为HTTPS会话创建一个新的会话ID cookie)，您可以使用session_id()函数设置它。session_id()还可以方便地将会话ID作为字符串返回。所以

...

$currentSessionID = session_id();

...

sets the $currentSessionID variable equal to the current session ID, and

将$currentSessionID变量设置为当前会话ID。

...

session_id($aSessionID);

...

sets the sessionID cookie in the browser to $aSessionID. from PHP: session_id

将浏览器中的sessionID cookie设置为$aSessionID。从PHP:session_id

Here's an example with two scripts. One is accessed via HTTP and the other is accessed via HTTPS. They must be on the same server to maintain session data.

这里有一个例子，有两个脚本。一个通过HTTP访问，另一个通过HTTPS访问。它们必须在同一个服务器上才能维护会话数据。

Script 1(HTTP):

脚本1(HTTP):

<?php

// This script will create a session and display a link to your secure server address
// to transfer your session ID. In this example, the secure page to receive the session
// ID is located at http://www.yoursite.com/safePages/securePage.php

// Start a session using the current session ID stored in a cookie, or create
// a new session if none is set.
session_start();

$currentSessionID = session_id();

// Set a variable that will be retrieved with the HTTPS script.
$_SESSION['testvariable'] = 'It worked';

// $secureServerDomain is the domain of your secure server
$secureServerDomain = 'www.yoursite.com';

// $securePagePath is the path to the page that will receive and set the session ID.
$securePagePath = '/safePages/securePage.php'

echo '<a href="https://' . $secureServerDomain . $securePagePath . '?session="' . $currentSessionID . '">Click here to transfer your session to the secure server</a>';

?>

Script 2(HTTPS):

脚本2(HTTPS):

<?php

// Retrieve the session ID as passed via the GET method.
$currentSessionID = $_GET['session'];

// Set a cookie for the session ID.
session_id($currentSessionID);

// Start a session.
session_start();

// Test retrieval of variable set when using HTTP.
if (!empty($_SESSION['testvariable'])) {
      echo $_SESSION['testvariable'];
} else {
      echo 'It did not work.';
}

?>

For this to work the HTTP and HTTPS servers must use the same session data storage substrate (i.e. for the default files handler, run on the same physical machine with the same php.ini). There are some security flaws here, so I would not use this code to transfer sensitive information. It is just meant as a workable example.

为此，HTTP和HTTPS服务器必须使用相同的会话数据存储基板(即默认的文件处理程序，在相同的物理机器上运行相同的php.ini)。这里有一些安全缺陷，所以我不会使用此代码传输敏感信息。这只是一个可行的例子。

When I ran into this problem before, I came up with the above as a quick fix, but I just remembered the original cause of the problem. I was going from http://www.example.com/page.php to https://example.com/page.php (notice the lack of "www"). Make sure that http://www.example.com/page.php will link to https://www.example.com/page.php and http://example.com will link to https://example.com/page.php.

当我遇到这个问题的时候，我想出了上面的一个快速解决方案，但是我只是记住了问题的最初原因。我从http://www.example.com/page.php到https://example.com/page.php(注意没有“www”)。请确保http://www.example.com/page.php将链接到https://www.example.com/page.php, http://example.com将链接到https://example.com/page.php。

PS, I didn't actually run these scripts so there may be a typo or two that prevents them from running properly as is.

PS，我实际上并没有运行这些脚本，所以可能有一两处错误会妨碍它们正常运行。

#2

Sounds like the session cookie is set to be secure. Cookies have a "secure" flag which, if set to true, means that the cookie won't be sent to non-https sites. PHP is probably using that for its session cookies. You can change this with the session_set_cookie_params function, or with the session.cookie_secure setting in php.ini.

听起来会话cookie被设置为安全的。cookie有一个“安全”标志，如果设置为true，就意味着cookie不会被发送到非https站点。PHP可能会将其用于其会话cookie。您可以使用session_set_cookie_params函数或会话来更改它。cookie_secure在php . ini中设置的。

#3

We had this issue as well. It turned out to be because we were using the suhosin patch on our PHP installation. We fix it by setting suhosin.session.cryptdocroot = Off in /etc/php.d/suhosin.ini.

我们也有这个问题。这是因为我们在PHP安装中使用了suhosin补丁。我们通过设置suhosin.session来修复它。cryptdocroot = Off in /etc/ php.d. /suhosin.ini。

For the suhosin manual about suhosin.session.cryptdocroot see http://www.hardened-php.net/suhosin/configuration.html#suhosin.session.cryptdocroot.

为suhosin手册有关suhosin.session。cryptdocroot看到http://www.hardened-php.net/suhosin/configuration.html suhosin.session.cryptdocroot。

We originally found the fix from this blog post: http://www.yireo.com/blog/general-news/315-switch-between-http-and-https-looses-php-session.

我们最初从这篇博客文章中找到了修复方法:http://www.yireo.com/blog/generation/news/315 -switch- http-和http- looss-php -session。

#4

The following solution assumes the secure and non-secure servers have access to the same backend services (cache, database store, etc).

下面的解决方案假设安全的和非安全的服务器可以访问相同的后端服务(缓存、数据库存储等)。

We had to deal with this same issue when sending a user to our checkout flow when they were done shopping. To solve this, we put in place a caching layer and cached all the pertinent data. For example, we would glean the product ids and user id from the session values, serialize them, create a hash, and finally store the session data within cache using the hash as the key. We would then redirect user to the secure site with the hash in the url.

当用户完成购物后向我们的结帐流程发送用户时，我们必须处理同样的问题。为了解决这个问题，我们放置了一个缓存层并缓存了所有相关的数据。例如，我们将从会话值收集产品id和用户id，序列化它们，创建一个散列，最后使用散列作为键将会话数据存储在缓存中。然后，我们将用户重定向到具有url中的散列的安全站点。

When the user ended up on the secure site we would attempt to pull the data out of cache based on the hash. Then with the user id and product ids we could load all the pricing and description data out of the database and present to the user for final checkout review.

当用户最终到达安全站点时，我们将尝试基于哈希从缓存中提取数据。然后，通过用户id和产品id，我们可以将所有的定价和描述数据从数据库中加载出来，并呈现给用户进行最后的检查检查。

There is an inherit risk in that the cache data is volatile, but we have never had any issues with it as the redirect happens quickly.

缓存数据是不稳定的，这是一种固有的风险，但是我们从来没有遇到过任何问题，因为重定向发生得很快。

#5

Looks like your session cookie is created with the secure flag, but there's something with the url of your checkout page due to which the session cookie isnt being passed over.

看起来您的会话cookie是用安全标志创建的，但是由于没有传递会话cookie，所以您的签出页面的url有问题。

Or probably, your session cookie isnt secure - just that the url of the checkout page is different enough (http://mysite.com vs http://www.mysite.com) that the browser isnt sending the cookie.

或者，您的会话cookie可能不安全——只是检查页面的url不同(http://mysite.com vs http://www.mysite.com)，浏览器不会发送cookie。

If you'd like to read more on flipping over from http to https and vice versa - do take a look at at my writeup on selective ssl :-)

如果你想读更多关于从http转到https的文章，反之亦然——请看看我在选择性ssl上的文章:-)

#6

You can't pass session values between different domains. You must use http post-get or a database to pass your values. For security, you can concat all your values in a string and use

您不能在不同域之间传递会话值。必须使用http post-get或数据库传递值。为了安全起见，您可以将所有值转换为字符串并使用

sha1($string)

and post it alongside your values and calculate the sha1 for the values other page gets, then compare the hashes.

并将它与您的值一起发布，并为其他页面获取的值计算sha1，然后比较散列。

Post method on different domains cause browsers to show a security message, so don't use that.

在不同的域中Post方法会导致浏览器显示安全消息，所以不要使用它。

Using url for get method is not safe, you would need to ask for a password on the redirected page for allowing the get parameters in your system.

使用url获取方法是不安全的，您需要在重定向页面上请求一个密码，以便允许系统中的get参数。

Do not use cookies if you need security.

如果需要安全，不要使用cookie。

The way I am suggesting is, save the values in a database and generate a key, then make your redirection link using your key, forward the users page with a get parameter which has the key, then the page user is redirected to gets that key, fetches the data and removes the key. you can generate a key with sha1

我建议的方法是,将值保存在一个数据库并生成一个密钥,然后使用您房间的钥匙,让你重定向链接的用户页面,获取参数的关键,那么用户重定向到有翻页键,获取数据和删除键。您可以使用sha1生成密钥。

PAGE 1---
$key=sha1($allvalsconcat);
//insert your session values to a database also the key in a column
header("Location: page2.php?key=".$key);

PAGE 2---
// select from database where key=$_GET["key"];
// delete from table where key=$key

this is pretty secure.

这是非常安全的。

the things that can happen: a script entering random values for the parameter "key" to make your website load the data into your memory?

可能发生的事情:脚本为参数“key”输入随机值，使您的网站将数据加载到您的内存中?

This is not going to happen because you delete the entry after using it. Some common misconception is that get values are unsafe and should always be avoided.

这不会发生，因为您在使用后删除了条目。一些常见的误解是获取值是不安全的，应该始终避免。

you can set the table engine type to "memory" in mysql if you want performance perfection.

如果希望性能完美，可以在mysql中将表引擎类型设置为“内存”。

#7

I'd recommend, in addition to what most have stated here about transferring encrypted information, looking at it the same as if you were transferring sensitive information through a 3rd party API. How do you know someone isn't spoofing the request? There are many protocols for truly confirming the authenticity of the request, depending on how sensitive your setup is. You're opening yourself up to accounts being compromised if you're not careful.

我建议，除了大多数人在本文中提到的关于传输加密信息的内容之外，还应该像通过第三方API传输敏感信息那样看待它。你怎么知道有人没有欺骗你的请求?有许多协议可以真正确认请求的真实性，这取决于您的设置有多敏感。如果你不小心的话，你的账户就会被泄露。

Even though it's on the same server, consider this:

即使它在同一台服务器上，请考虑以下内容:

When someone is following the link, form action, etc. that passes over the encrypted key, what would prevent someone from sniffing it BEFORE they get to the secured version of your site? If I were at a public WIFI spot, that wouldn't be too far-fetched. I could pretend to be your site, reroute requests to my own laptop, grab the token, and redirect the visitor back to where they came. They would assume it was a glitch, and would have no idea. Now I can login as them, and possibly go buy $10,000 worth of stuff with their credit card on file and ship it somewhere else. The degree of caution you take here should match the degree of sensitivity.

当有人跟踪传递加密密钥的链接、表单操作等时，有什么可以阻止他们在到达您的站点的安全版本之前嗅探它呢?如果我在公共WIFI点，那也不会太牵强。我可以假装自己是你的网站，将请求重新发送到我自己的笔记本电脑，获取令牌，并将访问者重定向回他们来的地方。他们会认为这是一个小故障，不会知道。现在，我可以以他们的身份登录，可能还会用他们的信用卡购买价值1万美元的东西，然后把它们寄到别的地方。你在这里采取的谨慎程度应该与敏感性程度相匹配。

Also, make sure you expire your tokens (one use only, after X number of seconds, etc), but I would also consider using the Post-Redirect-Get pattern on both ends, i.e.:

此外，确保您的令牌(只在X秒后使用)过期，但我也会考虑在两端使用后直- get模式，即:

Don't show the direct link on a page or in the form of the unsecured site, but show a link that will then redirect on the backend (and handle all the token/encryption stuff). When you arrive at the secured version, do the same (don't leave a "?token=asdfjalksfjla" parameter just sitting there in the URL; redirect it).

不要显示页面上的直接链接或不安全站点的形式，而是显示一个链接，然后在后台重定向(并处理所有令牌/加密内容)。当您到达安全版本时，也要这样做(不要留下a) ?令牌=asdfjalksfjla"参数就在URL中;重定向)。

So, formal token-based systems were designed to solve this very problem, but implementing OAuth just for this might be overkill. Spend some time planning the potential vulnerabilities before executing. Just because it'd be really hard to guess the token doesn't mean it's impossible (or there couldn't be collisions, etc.), so plan accordingly.

因此，正式的基于符号的系统被设计来解决这个问题，但是实现OAuth仅仅为了这个可能有点过头了。在执行之前花一些时间计划潜在的漏洞。仅仅因为很难猜测这个标记并不意味着它是不可能的(或者不可能发生碰撞，等等)，所以要相应地计划。

You also might need a more sophisticated session management system than PHP's built-in handlers. I don't know if you can force PHP to continue a session across multiple visits (switching protocols is treated that way).

您可能还需要一个比PHP内置的处理程序更复杂的会话管理系统。我不知道是否可以强制PHP在多次访问中继续会话(交换协议就是这样处理的)。

#8

Think about using HTTPS for all pages, that's the easiest way to avoid this problem and it will improve the security of your site.

考虑对所有页面使用HTTPS，这是避免这个问题的最简单方法，它将提高站点的安全性。

If SSL for all pages is not an option to you, then you could use this approach: Switching between HTTP and HTTPS pages with secure session-cookie. The idea behind is, that you leave the session cookie unsecure (and therefore available to HTTP and HTTPS pages), but have a second secure cookie to handle the authentication. It's a good way to separate the two concerns "maintaining the session" and "authentication".

如果不是所有页面的SSL选项，那么可以使用这种方法:使用安全的会话-cookie在HTTP和HTTPS页面之间切换。背后的想法是，让会话cookie不安全(因此对HTTP和HTTPS页面可用)，但是要有第二个安全cookie来处理身份验证。这是将“维护会话”和“验证”这两个关注点分离开来的好方法。

#9

You can manage session between HTTP to HTTPS or HTTPS to HTTP:

您可以管理HTTP到HTTPS或HTTPS到HTTP之间的会话:

Transmit session ID between page using GET

使用GET在页面之间传输会话ID
POST session ID by POST

以邮寄方式发送会话ID
Use files to save sessions

使用文件保存会话
Use Cookies for sessions

使用cookie会话
Use database to save session

使用数据库保存会话

Below example can be used to transmit using GET….

下面的例子可以用来传输使用GET ....

File : http.php ……………

文件:http。php ...............

<?php

session_start();

$sessionID = session_id();

$_SESSION['demo'] = ‘Demo session between HTTP HTTPS’;

echo ‘<a href=”https://www.svnlabs.com/https.php?session=’.$sessionID.’”>Demo session from HTTP to HTTPS</a>’;

?>

File: https.php ……………

文件:https。php ...............

<?php

$sessionID = $_GET['session'];

session_id($sessionID);

session_start();

if (!empty($_SESSION['demo'])) {
echo $_SESSION['svnlabs'];
} else {
echo ‘Demo session failed’;
}

?>

IE7 : This page contains both secure and nonsecure items

本页面包含安全和非安全项

You have to use relative path for all static resource on page like css, js, images, flash etc. to avoid IE message secure and nonsecure items…

你必须对页面上的所有静态资源使用相对路径，比如css、js、图像、flash等等，以避免IE消息的安全性和不安全性。

在PHP中从HTTP切换到HTTPS时丢失会话 IE Message

即消息

#10

This may not be possible since the cookie seems to be getting lost. The browser you're using must think it's for a completely different domain.

这可能是不可能的，因为cookie似乎丢失了。你所使用的浏览器必须认为它是一个完全不同的领域。

What browser are you using specifically?

您具体使用的浏览器是什么?

#11

By default I would expect a browser to treat connections to http and https as completely different sessions. Although the convention is that http://someUrl/ and https://someUrl/ will point to the same page it isn't guaranteed. You could have completely different sites running on port 80 (http) and port 443 (https).

默认情况下，我希望浏览器将对http和https的连接视为完全不同的会话。尽管约定是http://someUrl/和https://someUrl/将指向同一个页面，但这并不能保证。您可以在端口80 (http)和端口443 (https)上运行完全不同的站点。

I don't know PHP, but generally I would not expect session variables to be freely available between secure and non-secure sessions e.g. I wouldn't expect the credit card number from my last checkout to be available to all the subsequent insecure pages I visit.

我不知道PHP，但一般来说，我不会期望会话变量在安全会话和非安全会话之间是可*使用的。

Forgive the non-authoritative answer but I thought I'd chuck in my 2c since there aren't many answers.

请原谅我的非权威的回答，我想我应该放弃我的2c，因为没有太多的答案。

#12

Do you have a dedicated IP? on some shared environments the https and the http are routed through different servers, so switching actually loses access to the cookies since they're on different domains.

你有专门的IP吗?在一些共享环境中，https和http通过不同的服务器进行路由，因此切换实际上会丢失对cookie的访问权，因为它们位于不同的域。

solutions would be: dedicated ip

解决方案将是:专用ip

forcing https on all pages at all times

在所有页面上强制使用https

#13

I had a similar problem, however, this solution was good for me, perhaps will help others in the future

我也遇到过类似的问题，但是，这个解决方案对我来说是有好处的，也许将来会对别人有所帮助

add this in your php.ini

把这个加进你的php。ini中。

suhosin.session.cryptdocroot = Off

suhosin.session。cryptdocroot =了

suhosin.cookie.cryptdocroot = Off

suhosin.cookie。cryptdocroot =了

#14

I have got a solution by this..Try it.

我有个办法。试一试。

$_SESSION['test'] = 'test';
session_regenerate_id(true);

header("Location: /");// the header must be sent before session close
session_write_close(); // here you could also use exit();

#15

-1

Don't worry this is a normal behavior because HTTPS is meant to be secure and it is doing his part.

别担心，这是一种正常的行为，因为HTTPS是安全的，它正在发挥作用。

Below are some tricks through which you can maintain the session while switching from HTTP to HTTPS.

下面是一些技巧，通过这些技巧，您可以在从HTTP切换到HTTPS的同时维护会话。

Transmit session ID between page using GET

使用GET在页面之间传输会话ID
POST session ID by POST

以邮寄方式发送会话ID
Use files to save sessions

使用文件保存会话
Use Cookies for sessions

使用cookie会话
Use database to save session

使用数据库保存会话

Hope you will get something through my reply.

希望通过我的回复你能有所收获。

#1