This is an automated email from the ASF dual-hosted git repository. guoqi pushed a commit to branch revert-1612-p4 in repository https://gitbox.apache.org/repos/asf/apisix-website.git
commit 8fe0788c9a786de072f78e98ab3acb0fbc2f395f Author: Qi Guo <[email protected]> AuthorDate: Fri Jun 9 16:30:19 2023 +0800 Revert "docs: fix images in two blogs (#1612)" This reverts commit edf1092c1dbbd3bcc9de0640d73c451ec867c15e. --- blog/en/blog/2022/11/23/poor-man-api.md | 2 +- blog/en/blog/2023/03/02/security-policy-auditable.md | 2 +- blog/en/blog/2023/03/16/grpc-client-side.md | 4 ++-- blog/en/blog/2023/03/23/mtls-everywhere.md | 4 ++-- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/blog/en/blog/2022/11/23/poor-man-api.md b/blog/en/blog/2022/11/23/poor-man-api.md index 353111ab760..c8feaf45fe9 100644 --- a/blog/en/blog/2022/11/23/poor-man-api.md +++ b/blog/en/blog/2022/11/23/poor-man-api.md @@ -345,7 +345,7 @@ curl http://apisix:9080/apisix/admin/global_rules/2 -H 'X-API-KEY: 123xyz' -X PU Send a couple of queries and open the Grafana dashboard. It should look similar to this: - + ## Conclusion diff --git a/blog/en/blog/2023/03/02/security-policy-auditable.md b/blog/en/blog/2023/03/02/security-policy-auditable.md index 1ccee58b212..b89ed0180da 100644 --- a/blog/en/blog/2023/03/02/security-policy-auditable.md +++ b/blog/en/blog/2023/03/02/security-policy-auditable.md @@ -14,7 +14,7 @@ keywords: description: > Last week, I wrote about putting the right feature at the right place. I used rate limiting as an example, moving it from a library inside the application to the API Gateway. Today, I'll use another example: authentication and authorization. tags: [Ecosystem] -image: https://static.apiseven.com/uploads/2023/06/08/pzULiHZO_opa-horizontal-color.svg +image: https://blog.frankel.ch/assets/resources/security-policy-auditable/opa-horizontal-color.svg --- >Last week, I wrote about [putting the right feature at the right >place](https://blog.frankel.ch/right-feature-right-place/). I used rate >limiting as an example, moving it from a library inside the application to >the API Gateway. Today, I'll use another example: authentication and >authorization. diff --git a/blog/en/blog/2023/03/16/grpc-client-side.md b/blog/en/blog/2023/03/16/grpc-client-side.md index ad3797dd6d2..c44fc172364 100644 --- a/blog/en/blog/2023/03/16/grpc-client-side.md +++ b/blog/en/blog/2023/03/16/grpc-client-side.md @@ -15,7 +15,7 @@ description: > XML has schema validation out-of-the-box: an XML document can declare a grammar that it must conform to. SOAP, being based on XML, benefits from it too. Other serialization alternatives have a schema validation option: e.g., Avro, Kryo and Protocol Buffers. Interestingly enough, gRPC uses Protobuf to offer RPC across distributed components: tags: [Ecosystem] -image: https://static.apiseven.com/uploads/2023/06/08/DOxFlzQc_grpc.svg +image: https://blog.frankel.ch/assets/resources/grpc-client-side/grpc.svg --- >Most inter-systems communication components that use REST serialize their >payload in JSON. As of now, JSON lacks a widely-used schema validation >standard: [JSON Schema](https://json-schema.org/) is not widespread. Standard >schema validation allows delegating the validation to a third-party library >and being done with it. Without one, we must fall back to manual validation >in the code. Worse, we must keep the validation code in sync with the schema. @@ -145,7 +145,7 @@ We shall use Maven to generate the Java boilerplate code: After compilation, the structure should look something like the following: - + We can package the classes in a JAR and use it in a web app project. The latter is in Kotlin, but only because it's my favourite JVM language. diff --git a/blog/en/blog/2023/03/23/mtls-everywhere.md b/blog/en/blog/2023/03/23/mtls-everywhere.md index 0527c7830ea..87805ed8953 100644 --- a/blog/en/blog/2023/03/23/mtls-everywhere.md +++ b/blog/en/blog/2023/03/23/mtls-everywhere.md @@ -13,7 +13,7 @@ keywords: description: > Security in one's information system has always been among the most critical Non-Functional Requirements. Transport Secure Layer, aka TLS, formerly SSL, is among its many pillars. In this post, I'll show how to configure TLS for Apache APISIX. tags: [Ecosystem] -image: https://static.apiseven.com/uploads/2023/06/08/JXRmK9nZ_keys.jpeg +image: https://blog.frankel.ch/assets/resources/mtls-everywhere/data-key-gcce68039d_large.jpg --- >Security in one's information system has always been among the most critical >Non-Functional Requirements. Transport Secure Layer, _aka_ TLS, formerly SSL, >is among its many pillars. In this post, I'll show how to configure TLS for >[Apache APISIX](https://apisix.apache.org/). @@ -143,7 +143,7 @@ The certificate infrastructure is ready; let's look at Apache APISIX. [Apache APISIX](https://apisix.apache.org/) is an API Gateway. By default, it stores its configuration in [etcd](https://etcd.io/), a distributed key-value store - the same one used by Kubernetes. Note that in real-world scenarios, we should set up etcd clustering to improve the resiliency of the solution. For this post, we will limit ourselves to a single etcd instance. Apache APISIX offers an admin API via HTTP endpoints. Finally, the gateway forwards calls from the client to an upstre [...] - + Let's start with the foundational bricks: etcd and Apache APISIX. We need two certificates: one for etcd, in the server role, and one for Apache APISIX, as the etcd client.
