blocks|key|1303745|text|您需要实现自己的“检索”和“设置”cookie。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1303746|检索(有，获取)曲奇|1303747|创建自己的新类(任何你喜欢的地方，但我会用名称Cookie做app/Foundation/Facades/)+)。|offset|length|style|BOLD|1303748|use+\Illuminate\Support\Facades\Cookie+as+CookieStock;

class+Cookie+extends+CookieStock+{+
++++//implement+your+own+has(...);
++++public+static+function+has($key)
++++{
++++++++return+!+is_null(static::$app['request']->cookie(PREFIX+.+$key,+null));+//get+the+prefix+from+.env+file+for+your+case+APP_ENV
++++}

++++//implement+your+own+get(...);
++++public+static+function+get($key+=+null,+$default+=+null)+{...}
}|code-block|syntax|javascript|1303749|现在打开config/app.php并更改相应的别名(cookie)。|1303750|设置(制作)曲奇|1303751|创建自己的新提供者(使用技工)，并从Illuminate\Cookie\CookieServiceProvider.php复制粘贴代码并更改名称空间。再次打开config/app.php并使用新的服务提供者更改相应的服务提供者。|1303752|创建自己的新类(任何您喜欢的地方，但我会使用名称为app/Foundation/Cookie/)的CookieJar。|1303753|use+\Illuminate\Cookie\CookieJar+as+CookieJarStock;

class+CookieJar+extends+CookieJarStock+{

//Override+any+method+you+think+is+relevant+(my+guess+is+make(),+I+am+not+sure+at+the+moment+about+queue+related+methods)

++++public+function+make($name,+$value,+$minutes+=+0,+$path+=+null,+$domain+=+null,+$secure+=+false,+$httpOnly+=+true)
++++{
++++++++//+check+before+applying+the+PREFIX
++++++++if+(!empty($name))+{
++++++++++++$name+=+PREFIX+.+$name;+//+get+the+PREFIX+same+way+as+before
++++++++}

++++++++return+parent::make($name,+$value,+$minutes,+$path,+$domain,+$secure,+$httpOnly);
++++}
}|1303754|更新自己的cookie服务提供者中的代码，以使用您的CookieJar实现(第19行)。|1303755|运行$+composer+dump-autoload，您就可以完成了。|CODE|1303756|更新|1303757|自从BorisD.Teoharov提出，如果框架在主要版本之间更改了CookieJarStock的make()+(或任何其他与cookie相关的函数)的签名，我就做了一个示例存储库，其中包括一个可以按原样使用的测试，如果出现签名更改，它将失败。|1303758|它很简单：|1303759|public+function+test_custom_cookie_jar_can_be_resolved()
{
++++resolve(\App\Foundation\Cookie\CookieJar::class);
++++$this->assertTrue(true);
}|1303760|详细说明如何在对应的提交差数中进行检查。|1303761|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/Kyslik/jar-jar-cookie|1|https://github.com/Kyslik/jar-jar-cookie/commit/bb4ae0ac462d3bffeca166b72a47fce0562d1b5e?diff=split^0|0|0|U|N|0|0|0|0|I|17|0|P|M|0|0|0|2|O|0|0|Y|E|1D|6|2F|3|0|0|0|0|7|7|1|0^^$0|@$1|2|3|4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1P|8|@$F|1Q|G|1R|H|I]]|9|@]|A|$]]|$1|J|3|K|5|L|7|1S|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|1T|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1U|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1V|8|@$F|1W|G|1X|H|I]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1Y|8|@$F|1Z|G|20|H|I]]|9|@]|A|$]]|$1|W|3|X|5|L|7|21|8|@]|9|@]|A|$M|N]]|$1|Y|3|Z|5|6|7|22|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|23|8|@$F|24|G|25|H|12]]|9|@]|A|$]]|$1|13|3|14|5|6|7|26|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|27|8|@$F|28|G|29|H|12]|$F|2A|G|2B|H|12]]|9|@$F|2C|G|2D|1|2E]]|A|$]]|$1|17|3|18|5|6|7|2F|8|@]|9|@]|A|$]]|$1|19|3|1A|5|L|7|2G|8|@]|9|@]|A|$M|N]]|$1|1B|3|1C|5|6|7|2H|8|@]|9|@$F|2I|G|2J|1|2K]]|A|$]]|$1|1D|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]]|1E|$1F|$5|1G|1H|1I|A|$1J|1K]]|1L|$5|1G|1H|1I|A|$1J|1M]]]]

You need to implement your own "retrieving" and "setting" a cookie.

<h3>Retrieving (has, get) cookies</h3>

Create yourself new class (anywhere you like, but I would do app/Foundation/Facades/) with name Cookie.

<pre><code>use \Illuminate\Support\Facades\Cookie as CookieStock;

class Cookie extends CookieStock { 
 //implement your own has(...);
 public static function has($key)
 {
 return ! is_null(static::$app['request']-&gt;cookie(PREFIX . $key, null)); //get the prefix from .env file for your case APP_ENV
 }

 //implement your own get(...);
 public static function get($key = null, $default = null) {...}
}
</code></pre>

Now open up config/app.php and change corresponding alias (cookie).

<h3>Setting (make) cookies</h3>

Create yourself new provider (use artisan), and copy-paste code from Illuminate\Cookie\CookieServiceProvider.php and change namespaces.
Again open up config/app.php and change corresponding service provider with the new one.

Create yourself new class (anywhere you like, but I would do app/Foundation/Cookie/) with name CookieJar.

<pre><code>use \Illuminate\Cookie\CookieJar as CookieJarStock;

class CookieJar extends CookieJarStock {

//Override any method you think is relevant (my guess is make(), I am not sure at the moment about queue related methods)

 public function make($name, $value, $minutes = 0, $path = null, $domain = null, $secure = false, $httpOnly = true)
 {
 // check before applying the PREFIX
 if (!empty($name)) {
 $name = PREFIX . $name; // get the PREFIX same way as before
 }

 return parent::make($name, $value, $minutes, $path, $domain, $secure, $httpOnly);
 }
}
</code></pre>

Update the code in your own cookie service provider to use your implementation of CookieJar (line 19).

Run <code>$ composer dump-autoload</code>, and you should be done.

<h2>Update</h2>

Since BorisD.Teoharov brought up, that if framework changes signature of <code>CookieJarStock</code>s <code>make()</code> (or any other cookie related function) in between the major versions, I made a example <a href="https://github.com/Kyslik/jar-jar-cookie" rel="nofollow noreferrer">repository</a>, that includes a test that can be used as is and it will fail if signature change happens.

It is as simple as this:

<pre><code>public function test_custom_cookie_jar_can_be_resolved()
{
 resolve(\App\Foundation\Cookie\CookieJar::class);
 $this-&gt;assertTrue(true);
}
</code></pre>

Detailed how to can be inspected in <a href="https://github.com/Kyslik/jar-jar-cookie/commit/bb4ae0ac462d3bffeca166b72a47fce0562d1b5e?diff=split" rel="nofollow noreferrer">the corresponding commit diff</a>.

blocks|key|2597244|text|您可以根据环境设置cookie名称的前缀。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2597245|首先，将COOKIE_PREFIX添加到env文件中。|offset|length|style|CODE|2597246|COOKIE_PREFIX=dev|code-block|syntax|javascript|2597247|然后，在设置cookie时使用它。|2597248|$cookie+=+cookie(env('COOKIE_PREFIX',+'prod')+.+'_name',+'value',+$minutes);|2597249|然后，像这样检索它|2597250|$value+=+$request->cookie(env('COOKIE_PREFIX',+'prod')+.+'_name');|2597251|entityMap^0|0|4|D|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@$D|Y|E|Z|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|10|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|12|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|14|8|@]|9|@]|A|$K|L]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

You could set a prefix for the cookie name depending on the environment.

First, add <code>COOKIE_PREFIX</code> to your env file.

<pre><code>COOKIE_PREFIX=dev
</code></pre>

Then, use it when setting your cookie

<pre><code>$cookie = cookie(env('COOKIE_PREFIX', 'prod') . '_name', 'value', $minutes);
</code></pre>

Then, retrieve it like so

<pre><code>$value = $request-&gt;cookie(env('COOKIE_PREFIX', 'prod') . '_name');
</code></pre>

blocks|key|2597298|text|我已经设置了测试环境以确保，我没有遗漏任何细节。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2597299|在我以前的回答中，我认为使cookie无效对这种情况来说就足够了，但是@BorisD暗示不是这样，我已经在测试中证实了这一点。|2597300|所以有一些重要的笔记，来自我的经历.|2597301|不要将Laravel版本混入子域(+SESSION_DOMAIN+)--如果使用，您需要确保Laravel版本与(根域和子域之间)匹配，因为我已经在example.com域下试验了5.4和dev.example.com下的5.6。这向我展示了在处理Cookies时的一些不一致之处，因此在这些版本之间已经做了一些重要的更改，并且您可以确定如果混合版本，它将不能正常工作。我最终得到了Laravel5.6在两个领域的，所以我不是100%25确定这是否在Laravel5.4上有效，但我认为它应该。|ordered-list-item|offset|length|style|BOLD|2597302|确保您的所有子域都使用相同的APP_KEY+-否则，Laravel将无法解密Cookie，返回null值，因为Laravel中的所有加密/解密都使用此应用密钥.|CODE|2597303|SESSION_DOMAIN.在SESSION_DOMAIN中，我为这两个域指出了相同的根域，如example.com。有了这个设置，我可以在根域上创建一个cookie，并在这两个域中正确地检索它。在该设置之后，在子域上创建cookie也会迫使根域从子域cookie接收新值，并且它们将被重写。所以我想这里的一切都是按照原问题的要求进行的。|2597304|Cookie制作参数--如果您想在SESSION_DOMAIN中使用子域，您也可以安全地这样做。但是，您需要确保，重要的是，让我们称它们为全局cookie是以一种稍微不同的方式定义的。Cookie使语法：
Cookie+make(string+$name,+string+$value,+int+$minutes,+string+$path+=+null,+string+$domain+=+null,+bool+$secure+=+false,+bool+$httpOnly+=+true)
所以这里重要的是，您需要将这个特定cookie的根域放在创建上，例如：return+response($content)->cookie('name','value',10,null,'example.com')|2597305|结论：|2597306|使用此配置，您应该能够正确地访问子域和根域下的Cookies。|2597307|您可能需要将Laravel安装更新为5.6，这将迫使您至少升级到PHP7.1(+PHP中的cookie也有一些更改)|2597308|最后，在您的代码中，不要依赖Cookie的存在，而只依赖它的值(我不知道在您的情况下是否如此)。|2597309|entityMap^0|0|0|0|I|E|14|5P|0|0|28|1B|4|0|0|4Q|1C|B|0|0|2U|2V|3Z|6V|2Y|2V|3Z|7U|1Z|0|0|3|0|0|V|0|0|1M|0|0|1C|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|15|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|16|8|@$I|17|J|18|K|L]|$I|19|J|1A|K|L]]|9|@]|A|$]]|$1|M|3|N|5|H|7|1B|8|@$I|1C|J|1D|K|L]|$I|1E|J|1F|K|O]]|9|@]|A|$]]|$1|P|3|Q|5|H|7|1G|8|@$I|1H|J|1I|K|L]|$I|1J|J|1K|K|O]]|9|@]|A|$]]|$1|R|3|S|5|H|7|1L|8|@$I|1M|J|1N|K|L]|$I|1O|J|1P|K|L]|$I|1Q|J|1R|K|L]|$I|1S|J|1T|K|O]|$I|1U|J|1V|K|O]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1W|8|@$I|1X|J|1Y|K|L]]|9|@]|A|$]]|$1|V|3|W|5|H|7|1Z|8|@$I|20|J|21|K|L]]|9|@]|A|$]]|$1|X|3|Y|5|H|7|22|8|@$I|23|J|24|K|L]]|9|@]|A|$]]|$1|Z|3|10|5|H|7|25|8|@$I|26|J|27|K|L]]|9|@]|A|$]]|$1|11|3|-4|5|6|7|28|8|@]|9|@]|A|$]]]|12|$]]

I've setup test environments to make sure, I'm not missing any details.
As in my former answer, I thought invalidating cookies will be sufficient for that case, but as @BorisD suggested it is not, and I've confirmed that on my tests.
So there are a few important notes, coming from my experiences...
<ol>
<li>Don't mix Laravel versions in subdomains - If using SESSION_DOMAIN you need to make sure your Laravel version matches (between root and subdomains), cause I've experimented with 5.4 under example.com domain and 5.6 under dev.example.com. This showed me some inconsistency in dealing with Cookies, so some important changes have been done, between these versions, and you can be sure it will not work correctly if you mix versions. I finally ended up with Laravel 5.6 on both domains, so I'm not 100% sure if that works on Laravel 5.4, but I think it should.
</li>
<li>Make sure all your subdomains use the same APP_KEY - otherwise, Laravel will be unable to decrypt the Cookie, returning <code>null</code> value, cause all encryption/decryption in Laravel uses this app key...
</li>
<li>SESSION_DOMAIN. In SESSION_DOMAIN I've pointed the same root domain like <code>example.com</code> for both domains. With this setting, I can create a cookie on root domain, and retrieve it correctly on both domains. After that setting, creating a cookie on subdomain forces root domain to receive new value from subdomains cookie also, and they are overridden. So I guess everything works here as requested in the original question.
</li>
<li>Cookie make parameters - In case you want to use a subdomain in SESSION_DOMAIN, you can safely do that also. However, you need to make sure, important let's call them global cookies are defined in a bit different way. Cookie make syntax:
<code>Cookie make(string $name, string $value, int $minutes, string $path = null, string $domain = null, bool $secure = false, bool $httpOnly = true)</code>
So what's important here, you need to put your root domain for this particular cookie on creation like this for example:
<code>return response($content)-&gt;cookie('name','value',10,null,'example.com')</code>
</li>
</ol>
Conclusions:
<ol>
<li>With this config, you should be able to access your Cookies properly under subdomains and your root domain.</li>
<li>You may probably need to update your Laravel installations to 5.6, which will force you to upgrade to PHP 7.1 at least (there were some changes to cookies in php also)</li>
<li>And finally, in your code, don't rely on Cookie existence, but on its values only (I don't know if that's in your case).</li>
</ol>

blocks|key|2597311|text|其中一个原因是应用程序APP_KEY和APP_NAME在.env文件中都应该是相同的，这对我来说是有效的，经过两天的尝试，我在内部检查了每个库以获得这个解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2597312|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

One of reason for that is for both app
APP_KEY and APP_NAME
should same in .env file,
that worked for me after 2 days of tries, I checked each library internally to get this solution.

I am working on Laravel 5.4.30.

Imagine that we have a domain <code>example.com</code> and a subdomain of <code>dev.example.com</code>. The main domain is for master branch and the dev subdomain is for develop branch. We have cookie notice system that will be hidden after clicking on <code>Hide Cookie Notice</code> button. This works by setting a cookie forever.
We have set the <code>SESSION_DOMAIN</code> configs to each domain for each environment.

For main domain:

<pre><code>SESSION_DOMAIN=example.com
</code></pre>

For dev subdomain:

<pre><code>SESSION_DOMAIN=dev.example.com
</code></pre>

Now the issue comes from here. If we go to the <code>example.com</code> and click on hiding the cookie notice, a cookie will be set forever for main domain. After that we go to the <code>dev.example.com</code> and do the same. So a cookie will be set for subdomain as well. But this cookie has been set after previous one. (The order is important)
Now if we refresh the subdomain, we will see that notice again! (not hidden) The browser has read the main cookie because of <code>.example.com</code> set in <code>domain</code> parameter of cookie in the browser, so every subdomain will be affected. But the view still shows the notice because it cannot read any cookie for hiding.

Anyway I don't want to share that cookie across all subdomains. How can I achieve that? I think I should add a prefix for cookie name. But I don't know how to do it, that laravel automatically adds prefix to cookie name.

Any solutions?

Laravel shared cookie detection issue in domain and subdomain

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我在研究Laravel 5.4.30。假设我们有一个域example.com和一个dev.example.com子域。主域为主分支，开发子域为开发分支。我们有cookie通知系统，它将在单击Hide Cookie Notice按钮后隐藏。这是通过设置一个永久的cookie来实现的。我们已经将SESSION_DOMAIN...

问域和子域的Laravel共享cookie检测问题
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问域和子域的Laravel共享cookie检测问题EN