When viewing the cookies on my Magento 1.7 site homepage the "frontend" cookie is shown twice.
Examples of the cookies being produced
frontend=stpvj4gep5c2h9qu4mhcdlru40;
expires=Wed, 04 Feb 2015 02:21:23 GMT;
path=/;
domain=.example.com.au; HttpOnly
frontend=stpvj4gep5c2h9qu4mhcdlru40;
path=/;
domain=example.com.au
How do you make it so that only one cookie is being produced?
You need to set a cookie domain in the Admin Panel. You can find the setting under System -> Configuration -> General / Web / Session Cookie Management: Cookie Domain.
Related
I have a Laravel APP deployed on Vapor(AWS Lambda). I am trying to send an API request to it from a React app running locally.
Below are the set-cookie headers from the API response.
XSRF-TOKEN=eyJpdiI6IlVSZGJrT2duOEo4dzFkaHNsb1pIS3c9PSIsInZhbHVlIjoiaXdlQmo2QmtsVjByUnFkREt1UE5XYWIvQTc1b3pVZlFLL09rWDhEY1FIL3JiYUg1Z2lBZUdQeVp1MEhyay80RG00SHJZNytSN1paZ0VKNjBBSzQxOEF6Y2tGSGF5SHZpa3QrbkVQWjErKzMzeXFJaUwrUTBqVi9iTklaRnBROXQiLCJtYWMiOiIzNTgxOGFiZGRkZTRlYTE5MzY1MDY4Y2UzMzA5YzdkYzk5NWUxMzdjMDdkMTY4NDI5YmFiNGQ4NTg4NGIzNTQxIiwidGFnIjoiIn0=; expires=Fri, 17-Sep-2021 16:00:35 GMT; Max-Age=7200; path=/; domain=localhost; samesite=lax
hylo_session=eyJpdiI6InEzK0Q3aytCWGM2T1dVSFdTSy80L2c9PSIsInZhbHVlIjoiYUpwd2tKV09GbTMrc2Z1WUdoM0hSc1V4TGFDQjR4elNxeFJudGpMMWM0M2kyUzZlY3JnNzRRc3BvRWk0S1J2S1RwOFRrSndzcFI2Vjh0c1Ewd1JiM1E5bHhXRDBkbnlLRlI4czdqTUsrRXViZXRHcUV2NklOekQvYk5iSWpraUQiLCJtYWMiOiI1OGExZGFiNzdkNzVlY2U3MjFkZGJjMTNjYTE3ZmVhYWQ4MjM5NzZkMDkxNWRkZDQ2Mjk4YTlhYTYzMTdlOGQ0IiwidGFnIjoiIn0=; expires=Fri, 17-Sep-2021 16:00:35 GMT; Max-Age=7200; path=/; domain=localhost; httponly; samesite=lax
Somehow the cookie is blocked. I am getting the following warning in the Network Tab:
The attempt to set cookie via set-cookie is blocked because its domain attribute is invalid with regards to the current host URL.
I am using Laravel Sanctum for Auth. Following are my env related to session:
SESSION_DRIVER=redis
SESSION_LIFETIME=120
SESSION_DOMAIN=localhost
SANCTUM_STATEFUL_DOMAINS=localhost:3000
CORS_ALLOWED_ORIGINS=http://localhost:3000
I even tried setting same_site value to none in sesison.php but it is still sending samesite as lax.
Any clue how to get this working?
I wrote a program that set a cookie. it work well in http mode, but when I use https protocol, header of cookie add automatically add secure flag to it.
set-cookie: val=is; expires=Sun, 16-Feb-2025 07:26:50 GMT; Max-Age=90000; path=/; secure
my code is:
<?php
header('Set-Cookie: val=is; expires=Sun, 16-Feb-2025 07:26:50 GMT; Max-Age=90000; path=/');
What makes this happen?
I'm experiencing a strange issue on a WooCommerce installation my company has taken over. It's not us who built it and unfortunately it's pretty crappy built so I'm not so sure what's actually going on in there.
It suddenly started to "force" https connections, but as far as I know nothing has changed in nether the code nor from the admin. We are running Git on the server and nothing has changed in the working tree, and I searched the uploads folder for suspicious files with no results. It's very unlikely some kind of malware. The site is not set up with https/ssl so this does of course trigger a timeout.
I checked the database and both home_url and site_url are set to "http://...". The WooCommerce option "force ssl" is set to false. Also we are running the plugin "Better WP Security/iThemes Security" which also offers a "force ssl"-option but that one is set to false too.
I tried setting both the constants FORCE_SSL_ADMIN and FORCE_SSL_LOGIN to false in wp-config.php - still no luck. Also I tried using .htaccess rewrite rules but that didn't help either.
It seems to be connected with a request header; HTTPS: 1 (tested with $ curl -I -H"HTTPS: 1" http://...). When that one is set to 0 this does not happen. However Chrome seems to send it by default, which is not the case for other browsers. I tried clearing cookies/data etc. Problem appears in my colleague's browser as well (and she has never visited the site before). Hosting company says this is not related to server configuration.
Has anyone experienced this before, or know to what it could be related to?
Update:
Running curl -I -H"HTTPS: 1" http://www.example.com/wp-admin/ pretty much confirms this has something to do with Wordpress. The cookies are set by WPML which indicates Wordpress is initialized. Check the Location: header:
HTTP/1.1 302 Moved Temporarily
Server: Apache
X-Powered-By: PHP/5.6.11
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Set-Cookie: _icl_current_admin_language=sv; expires=Wed, 22-Jul-2015 16:06:25 GMT; Max-Age=7200; path=/wp-admin/
Set-Cookie: _icl_current_language=sv; expires=Thu, 23-Jul-2015 14:06:25 GMT; Max-Age=86400; path=/
Set-Cookie: PHPSESSID=xxx; path=/
Location: https://www.example.com/wp-login.php?redirect_to=https%3A%2F%2Fwww.example.com%2Fwp-admin%2F&reauth=1
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8
Date: Wed, 22 Jul 2015 14:06:26 GMT
X-Varnish: nnn
Age: 0
Via: 1.1 varnish
Connection: keep-alive
http://develop.woothemes.com/woocommerce/2015/07/woocommerce-2-3-13-security-and-maintenance-release/
Updating Woocommerce to 2.3.13 fixed it for me
#Zertuk's solution is correct: upgrading to the latest WooCommerce should fix the issue because of the change that #Zertuk has linked.
To give more detail: Chrome has implemented the Upgrade Insecure Requests specification from the World Wide Web Consortium (W3C). Section 3.2.1 of that specification is The HTTPS HTTP Request Header Field which states
3.2.1. The HTTPS HTTP Request Header Field
The HTTPS HTTP request header field sends a signal to the server
expressing the client’s preference for an encrypted and authenticated
response, and that it can successfully handle the
upgrade-insecure-requests directive in order to make that preference
as seamless as possible to provide.
This preference is represented by the following ANBF:
"HTTPS:" *WSP "1" *WSP
WooCommerce's is_ssl() function before version 2.3.13 was incorrectly rewriting all the URLs in the response if the HTTPS: 1 header was set.
Upgrading to the latest version of WooCommerce (currently 2.3.13) fixes the bug.
I fixed this issue by turning off the Force SSL setting within WooCommerce Settings, and then explicitly setting these 3 WooCommerce pages to use SSL via the checkbox provided as part of this plugin (on the Edit Page screen).
The pages that needing SSL according to WooCommerce are:
1. Checkout
2. Checkout -> Pay
3. My Account
and also try,
<?php
if (is_ssl()) {
//action to take for page using SSL
}
?>
Returns true if the page is using SSL (checks if HTTPS or on Port 443).
Kirby is right.
I did a quick fix modifying the Wordpress core function is_ssl().
I return false at the beginning of the function because some of my websites do not have SSL.
It's not recommended modify the core of Wordpress because of the updates, but I can control that.
I happen to notice that when I make a request to my API (written in Laravel framework), there is Set-Cookie:
Set-Cookie: laravel_session=eyJpdiI6IlF5SDNLeGlRRTBFSlVJbXROSEZMWlE9PSIsInZhbHVlIjoiRlZXWVJrZERJN0tPRDU1TG40MGpJeURDQjRncUFYWGk4MjRBeFhMVHc3S2w5aW8yRFc1TCt4UWUzTEJnMTRpNkpYYkV6bnZ6Yk85RWF0MGIxaVhXYkE9PSIsIm1hYyI6ImRmNTc0MzRkZGM1ZDg0YWZkMWZjZThjOGI4Y2FlNTI2NjRhN2JjOGU0OTVkMWEwNTMwYTNlZmYxY2Y2ODNiMzkifQ%3D%3D; expires=Fri, 09-Jan-2015 20:49:47 GMT; Max-Age=7200; path=/; httponly
How can I get rid of it or block my Laravel API to not use it? It is possible can add a script in that laravel_session value.
Also, how do I avoid my app to consume the cookie set by the request?
You can disable session cookies for the whole application by changing the session driver to array
In app/config/session.php:
'driver' => 'array'
I am experiencing intermittent issues when using the Pingdom monitoring tool to check the status of my website.
Every 10-15 minutes I get an alert to say that a 302 has been found. What I can't understand is - i'm not doing any 302 temporary redirects. I am, however, doing 301 redirects (in certain circumstances).
Could this be a false positive from Pingdom?
Also, I have a redirect in code that does this. Would not specifying the HTTP response code
cause an issue here?
header('Location: http://www.ayrshireminis.com');
exit();
The Pingdom data:
Request 1
GET / HTTP/1.0
User-Agent: Pingdom.com_bot_version_1.4_(http://www.pingdom.com/)
Host: www.ayrshireminis.com
Received header
302 Found
Date: Tue, 24 Jul 2012 13:13:25 GMT
Server: Apache
Set-Cookie: prev_session_id=2a7001f5caa79bd36995953bf4853675; expires=Thu, 23-Aug-2012 13:13:25 GMT; path=/; domain=ayrshireminis.com
Location: http://www.ayrshireminis.com/
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Looks to me like a cookie is being set on the response, then redirecting you to the same page. Because Pingdom uses a number of different monitoring sources, that cookie redirect behavior will cause a lot of problems. Then again, you may need it for actual website visitors.
Rather than monitor the root of the webpage, I would recommend creating a separate /status page just for Pingdom that:
Doesn't set or use cookies
Performs a cheap end-to-end health check of the application and backing services
Returns a 200 response code only if everything checks out OK