On the Laravel News site they've posted an announcement recommending all Laravel 5.6.x and 5.5.x users upgrade to the latest release (5.6.30 & 5.5.42) due to a security issue dealing with the APP_KEY value.

Laravel 5.6.30 and Laravel 5.5.42 have both been released to fix a security issue and is recommended that all users upgrade as soon as possible.

This update also includes changes to cookie encryption and serialization logic. In addition to the upgrade, they also recommend rotating the key if you believe any malicious user (or former developer/employee) had access to it. The upgrade guide has the information you need to make the update to your application.

On the SitePoint PHP blog there's a new tutorial posted showing how to fix Magento login issue with cookies and sessions. This issue can cause a redirect loop but can be fixed.

In this article are looking at how Magento cookies can create issues with the login functionality of both the customer-facing front-end and admin back-end, the reason it occurs and how it should be resolved.

This is also known as the looping issue, as the screen redirects itself to the same screen, even though the username and password is correct.

The post starts with some basic definitions of "cookie" and "session" and gets into more detail on how Magento stores sessions and the places it can store them. The tutorial then covers each of the cookies used and three reasons the login issues might be happening:

• Cookie domain does not match server domain
• Multiple subdomains used and Magento’s cookie configuration is incorrect
• Double front-end cookies causing intermittent login issues

For each several solutions are included with any code or SQL changes that need to happen to correct it.

In this post to his site Paul Jones makes some suggestions about how to handle session cookies (PHP's default session handling mechanism) and requests/responses using the PSR-7 structure.

One of the great things about PHP is its session handling capabilities. One call to session_start() and a huge amount of heavy lifting is done for you. It’s a great aid when writing page scripts.

However, as you start to need finer control over the HTTP response in your project, some of the automatic session behaviors begin to get in the way. In particular, when you are using PSR-7 to build your HTTP response, you realize that session_start() and session_regenerate_id() both automatically do the equivalent of calling setcookie() to write headers directly to the output. This means you cannot buffer those calls into the Response object for later sending.

How then can we use PHP’s session handling, when we want finer control over when and how cookies get sent?

He suggests that you do two things. First, disable PHP itself from automatically sending the cookie via some ini_set calls. The second is to do the session ID comparison manually and perform the related action (either allowing or sending a new ID on failure). He includes example code showing it in action and also mentions some of the shortcomings of the approach around cache and limiter headers.

Simon Holywell has a new post talking about cookie security in PHP, focusing on some of the PHP configuration settings that can help.

The security of session handling in PHP can easily be enhanced through the use of a few configuration settings and the addition of an SSL certificate. Whilst this topic has been covered numerous times before it still bears mentioning with a large number of PHP sites and servers having not implemented these features.

He talks about the httponly flag when setting the cookie/in the configuration, the "use only cookies" for sessions and forcing them to be "secure only".

On PHPMaster.com there's a new tutorial about working with cookies in PHP applications - an introductory look at what they are, how to set them and how to read their values.

Have you ever wondered that in spite of HTTP being a stateless protocol, when you log in to a website and buy stuff and checkout how the server can identify you uniquely? You might wonder if HTTP is stateless but your state is maintained through your interactions, isn’t this a contradiction? Welcome to world of cookies (not the ones which we can eat, btw :)), one the of primary ways to maintain user state and interaction between the web browser and the web server.

She shares a lifecycle of a common cookie and describes the parts of the setcookie method (parameters). There's also a few code examples showing how to read and write to them as well as update their values/expirations.

Philip Norton has shared a script he's created in a new post today that lets you read from a Netscape-formatted cookie file (as outputted from a curl request).

This file is generated by PHP when it runs CURL (with the appropriate options enabled) and can be used in subsequent CURL calls. This file can be read to see what cookies where created after CURL has finished running. As an example, this is the sort of file that might be created during a typical CURL call.

The file is structured, plain-text content with information on the domain, path, security, name and expiration details of each cookie. His script parses out these details and pushes them into a basic array, prime for searching and sorting (and reuse) in your application.

<> On PHPBuilder.com today there's a new tutorial from Leidago Noabeb showing how you can track your website's users with the help of sessions and cookies, the handling for which are already included in PHP.

So, why can't you maintain state with HTTP? The main reason is because HTTP is a stateless protocol, meaning that it has no built-in way of maintaining state between transactions. For example, when a user requests one page followed by another, HTTP does not provide a way for us to tell which user made the second request. In this article we will look at what maintaining state in PHP applications entails.

They introduce cookies and how they can be used to store information about the user's session on their client for a certain amount of time. This makes it much simpler for the cross-page or cross-session details to persist. There's a bit of code showing how to set and get a cookie and how to do the same with a session.

Evert Pot has a quick new post to his blog today talking about how to push encrypted information into a cookie for storage.

There have been a couple of approaches I've been considering [to replace sessions being stored in the database], one of which is simply storing all the information in a browser cookie. First I want to make clear I don't necessarily condone this. The reason I'm writing this post, is because I'm hoping for some more community feedback. Is this a really bad idea? I would love to know.

He includes some code to make it happen - a class that uses the hash_hmac function and a SHA1 encryption type (along with a salt) to convert the information into a string that can be (relatively) safely stored in a cookie. Be sure to read the comments for more opinions on the method.

On ProDevTips.com there's a quick new tutorial posted about using the Zend_Http component of the Zend Framework to fetch a remote page that requires cookie authentication - a "cookie jar".

As it happens I’m very satisfied with the performance of Zend Http when it comes to the fetching and cookie parts. [...] Note [in my example] the use of $client->setCookieJar();, that is all that is needed to manage the logged in state, awesome. Without it the second post to adv_stats.php would’ve failed due to unauthorized access.

This fetching method pulls in the remote file, parses out the table (as defined by a pattern match) and grabs the rows/columns using getRows and getColumns and manipulates the content inside.

All of you developers out there, NETTUTS.com has a question for you - are you making any of these ten PHP mistakes in your day to day development? Which ones, you ask? Read on...

Here are 10 PHP mistakes that any programmer, regardless of skill level, might make at any given time. Some of the mistakes are very basic, but trip up even the best PHP programmer. Other mistakes are hard to spot (even with strict error reporting). But all of these mistakes have one thing in common: They're easy to avoid.

Here's the list (as Glen Stanberry sees it):

• Single quotes, double quotes
• Semicolon after a While
• NOT Using database caching
• Missing Semicolon After a Break or a Continue
• Not Using E_ALL Reporting
• Not Setting Time Limits On PHP Scripts
• Not Protecting Session ID's
• Not Validating Cookie Data
• Not Escaping Entities
• Using Wrong Comparison Operators