Updating PHP…with DevOps? Read thoughts on how modern DevOps approaches can benefit teams who need to update PHP, and strategies teams can apply even when managing legacy applications.

Have questions on WordPress PHP support? Get answers in this blog from our expert, including the outlook for when teams can expect WordPress PHP 8 support.

The PHP team is pleased to announce the first testing release of PHP 8.3.0, Alpha 1. This starts the PHP 8.3 release cycle, the rough outline of which is specified in the PHP Wiki.For source downloads of PHP 8.3.0 Alpha 1 please visit the download page.Please carefully test this version and report any issues found using the bug tracking system.Please DO NOT use this version in production, it is an early test version.For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive.The next release will be Alpha 2, planned for 22 Jun 2023.The signatures for the release can be found in the manifest or on the QA site.Thank you for helping us make PHP better.

IBM i modernization, even from a strategy perspective, can be convoluted and complicated. In this blog, our expert looks at efficient and cost-effective ways to modernize your IBM i applications.

Get an overview of PHP job queueing, including commonly used tools, and ZendPHP JobQueue — a new tool that can help make PHP queueing easier than ever before.

Considering hiring PHP developers vs. PHP outsourcing? Want to train your team to be experts? See the benefits of each approach in this blog.

Truncated by Planet PHP, read more at the original (another 1745 bytes)

I read an interesting thread on Hackernews in response to a post:
“Why is OAuth still hard in 2023”. The post and comments bring up a lot
of real issues with OAuth. The article ends with a pitch to
use the author’s product Nango that advertises support
for supporting OAuth2 flows for 90+ APIs and justifying the existence
of the product.

We don’t need 90 browsers to open 90 websites, so why
is this the case with OAuth2? In a similar vain, the popular passport.js
project has 538(!) modules for authenticating with various services,
most of which likely use OAuth2. All of these are NPM packages.

Anyway, I’ve been wanting to write this article for a while. It’s not
a direct response to the Nango article, but it’s a similar take with
a different solution.

My perspective

I’ve been working on an OAuth2 server for a year years now, and last
year I released an open source OAuth2 client.

Since I released the client, I’ve gotten several new features and requests
that were all contributed by users of the library, a few of note are:

• Allowing client_id and client_secret to be sent in request bodies
  instead of the Authorization header.
• Allow ‘extra parameters’ to be sent with some OAuth2 flows. Many servers,
  including Auth0 require these.
• Allow users to add their own HTTP headers, for the same reason.

What these have in common is that there’s a lot of different OAuth2 servers
that want things in a slightly different/specific way.

I kind of expected this. It wasn’t going to be enough to just implement
OAuth2. This library will only work once people start trying it with different
servers and run into mild incompatibilities that this library will have to
add workarounds for.

Although I think OAuth2 is pretty well defined, the full breadth of specs and
implementations makes it so that it’s not enough to (as an API developer) to just
tell your users: “We use OAuth2”.

For the typical case, you might have to tell them something like this:

• We use OAuth2.
• We use the authorization_code flow.
• Your client_id is X.
• Our ‘token endpoint’ is Y.
• Our ‘authorization endpoint’ is Z.
• We require PKCE.
• Requests to the “token” endpoint require credentials to be sent in a body.
• Any custom non-standard extensions.

To some extent this is by design. The OAuth2 spec calls itself: “The OAuth 2.0
Authorization Framework”. It’s not saying it is the protocol, but rather it’s
a set of really good building blocks to implement your own authentication.

But for users that want to use generic OAuth2 tooling this is not ideal.
Not only because of the amount of information that needs to be shared, but also
it requires users of your API to be familiar with all these terms.

A side-effect of this is that API vendors that use OAuth2 will be more likely
roll their own SDKs, so they can insulate users from these implementation details.
It also creates a market for products like Nango and Passport.js.

Another result is that I see many people invent their own authentication flows
with JWT and refresh tokens from scratch, even though OAuth2 would be good fit.
Most people only need a small part of OAuth2, but to understand which small
part you need you’ll need to wade through and understand a dozen IETF RFC
documents, some of wich are still drafts.

Sidenote: OpenID Connect is another dimension on top of this. OpenID Connect builds on
OAuth2 and adds many features and another set of dense technical specs that are
(in my opinion) even harder to read.

OAuth2 as a framework is really good and very successful. But it’s not as good
at being a generic protocol that people can write generic code for.

Solving the setup issue

There’s a nice OAuth2 feature called “OAuth 2.0 Authorization Server Metadata”,
defined in RFC8414. This is a JSON document sitting at a predictable URL:
https://your-server/.well-known/oauth-authorization-server, and can tell
clients:

• W

Truncated by Planet PHP, read more at the original (another 8947 bytes)

In the tenth part of this tutorial series on developing PHP on Docker we will
create a production infrastructure for a dockerized PHP application on GCP using multiple
VMs and managed services for redis and mysql.

All code samples are publicly available in my
Docker PHP Tutorial repository on Github.
You find the branch with the final result of this tutorial at
part-10-create-production-infrastructure-php-app-gcp.

CAUTION: With this codebase it is not possible to deploy any longer! Please refer to the next
part
Deploy dockerized PHP Apps to production – using multiple VMS and managed mysql and redis instances from GCP
for the code to enable deployments again.

All published parts of the Docker PHP Tutorial are collected under a dedicated page at
Docker PHP Tutorial. The previous part was
Deploy dockerized PHP Apps to production on GCP via docker compose as a POC.

If you want to follow along, please subscribe to the RSS feed
or via email to get automatic notifications when the next part comes out 🙂

Table of contents

• Introduction
  • Run the code yourself
• Additional GCP concepts
  • IPs, Networking and VPCs (Virtual Private Cloud)
  • Routers and NATs
  • IP range allocations, VPC Peering and private service access
  • Additional Service APIs and IAM roles
• Service setup
  • Cloud SQL for MySQL setup
  • Redis Memorystore setup
  • Set up the VMs that run docker containers
    • Provisioning the VMs
  • Mapping service names to VM names
• Appendix: Changes in the codebase
  • Add a make dev-init target
  • Update the gcloud targets
  • Add additional make variables
  • Use make to execute infrastructure and deployment targets in parallel
• Wrapping up

Introduction

In Deploy dockerized PHP Apps to production on GCP via docker compose as a POC
we’ve created a single Compute Instance VM, provisioned it with docker compose and
ran our full docker compose setup on it. In other words: All containers ran on the same VM
(that had to be reachable from the internet).

Truncated by Planet PHP, read more at the original (another 48489 bytes)