d8-contrib-modules / akamai Goto Github PK

At present, it just sets a message.

Purging is handled via a Purge Purger plugin, which implements PurgerInterface.

If you look here, you can see what sort of response Purge expects in order to keep track of Purge status:

https://github.com/nielsvm/purge/blob/8.x-3.x/src/Plugin/Purge/Purger/PurgerInterface.php#L66

Akamai keeps track of Purge status in its queues. We would need to track some state to keep a log of when things are actually invalidated/purged upstream vs when the API request was made.

Set up 8.x-2.x version
-info file
-set up travis.yml
-known dependencies: expire (or some cache-level expiration tool like purge)

Class - PurgeStatusDeleteForm
Error - call to undefined function $this->getPurgeId()
on line no 65 and 74

We should make the interface consistent but allow for plugging of CCUv2 or CCUv3.

Doesn't do anything at the moment!

Current D7 behaviors are...

1. If "Expire" is enabled (soft dependency) to register Akamai with Expire and perform cache invalidations inline with Expire's operations
2. If Expire is not enabled, taps into Drupal's hook node update and hook node delete functionality to perform cache invalidation

The purpose of this ticket is to outline the appropriate cache invalidation strategy such that Akamai appropriately invalidates all pages when changes occur

Blockers for the Beta Release

1. Automated Tests.
2. Purge URL queuer or other automated queuer
3. Status tracking of purges

1. Can place block on any page (not just nodes but can be a View page or Panelizer page, etc)
2. Only shows / displays for users with "cache clear" permission
3. Renders a button that clears the page's URL

Hello,

I've got serious concerns about the security of this module. If someone puts their credentials in the UI, they're sending them in the clear, and if a large company did this, they would be exposing the company, and Akamai, to serious issues. Additionally, anyone who can see the database (are the credentials stored in the clear like Wordpress?) can access the credentials.

It would be much better to instruct people to send the credentials to the system via sftp. It may be more of an issue, but it would be better than what's being done now. It's critically important that these credentials be protected, and without HTTPS and database protection, the users should access this file as an sftp target.

Our security folks will likely have serious issues with this as well.

Kirsten Hunter
API Evangelist, Akamai

This is needed to properly integrate the upstream client. We obviously need to make sure Akamai's credentials work if we want to connect to their API. I have recently been given dev access to an Acquia partner account to test this.

It would be much more flexible and maintainable if instead of using custom code to interact with the status log, we could instead expose its data to views.

• describe PurgeStatus to views
• Package default views with the module for listing and detail views of purge status entries

The class was built on faulty assumptions per https://community.akamai.com/thread/3613

Akamai has functions to check queue status and length. Let's add those as Purge\DiagnosticChecks.

This depends on #16, obv.

CCUv2 requires that URL purges specify fully qualified URLs.

Before queueing a purge request, we should ensure that:

• URLs are valid (we can use \Url::isValid() for this)
• URLs are real Drupal paths on the existing site. \Url::isRouted() probably works for this check.

We should feedback to the user and prevent a form submit on the manual cache clear forms. Bad URLs shouldn't need to be manually checked when Purge is clearing handling.

Recommendation - Creating a DiagnosticCheck plugin to prevent your purger from even being called when it sets an ERROR.
Error - Uncaught PHP Exception GuzzleHttp\Exception\ConnectException: "cURL error 28: Operation timed out after 5590 milliseconds with 0 out of -1 bytes received

Settings form for what is currently in the D7 version's configuration form

Sample settings:
-Akamai API URL
-Cache clearing user / password
-Base path
-Timeout length
-Akamai domain (production, staging)
-Clearing action type default (remove or invalidate option)

Please leverage CMI such that configuration options can be exported by site

Diagnostics checks can run more than is necessary; for example, CredentialsCheck is running on almost every page load on my dev machine. Change the logic so the credentials are only checked when they change.

• administering Akamai settings
• running manual cache clears
• locks down the forms

I think we need to make AkamaiClient more decoupled, so it is easier to test and extend, and is more maintainable.

• It would be great to be able to enable or disable PurgeStatus logging. At present theres a hard dependency between StatusStorage and AkamaiClient
• I would love to be able to add Guzzle Middleware so that you could see the actual requests being sent. That would be great for support and debugging on live sites, and would allow us to write very comprehensive tests that ensure that requests are valid.

If a user provides a url (eg node/123) that has aliases (eg /my/friendly/url), we should queue both for purging.

Looks like Akamai have created a PHP client.

https://github.com/akamai-open/AkamaiOPEN-edgegrid-php

Examples of it in use are here: https://github.com/akamai-open/api-kickstart/tree/master/examples/php

There's also a new API in beta which apparently will offer sub 5s purge times.

The config form/object at present is inherited from D7 and tracks a whole lot of config that doesn't seem to show up in the EdgeGrid Client examples, so we need to update it to respect those.

Config keys should look something like: https://github.com/akamai-open/AkamaiOPEN-edgegrid-php/blob/master/tests/edgerc/.edgerc

[default]
client_secret = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
host = xxxxx.luna.akamaiapis.net/
access_token = xxxxx
client_token = xxxxx

We should keep reference to the mock endpoint URI.

A Drupal form that allows a site admin to manually specify...

1. List of URLs to clear
2. Akamai domain (prod, stg)
3. Clearing action type (invalidate, remove)

-Set up Drupal service

-Create a protected function for connecting to Akamai that can be invoked from the other functions of the service
--Pulls from the configuration settings by default
--Can be overridden by function parameters

-Create a public function to clear cache
--Calls the connection function
--Pass parameter of a specific page
--Pull from default settings or from the manually specified values in the manual cache clear form
--Returns response from Akamai, logs response in Watchdog