verbb / consume

A Craft CMS plugin to create HTTP requests in your Twig templates to consume JSON, XML or CSV content.
Other
4 stars 1 forks source link

Client won’t work, ad-hoc client in template does #1

Closed jannisborgers closed 1 year ago

jannisborgers commented 1 year ago

Describe the bug

We used the Fetch plugin before to make HTTP requests to external APIs.

Before going all in, I wanted to try Consume on a smaller project. I’m trying to add newsletter subscribers to a MailerLite account with a front end form.

Their API reference describes the basic setup. We need to authenticate with an API token.

This works:

{# Get form submission data and save as form_data #}
{% set form_data = {
  email: craft.app.request.getParam("email") ?? null,
  firstName: craft.app.request.getParam("firstName") ?? null,
  lastName: craft.app.request.getParam("lastName") ?? null,
} %}

{# Set up client manually #}
{% set mailerlite_client = {
    base_uri: "https://connect.mailerlite.com/api/",
    headers: {
        "Authorization": getenv("MAILERLITE_API_KEY"),
        "Content-Type": "application/json",
        "Accept": "application/json",
    },
  } %}

  {% set mailerlite_request = consume(mailerlite_client, "POST", "subscribers", {
    query: {
      "email": form_data.email,
      "fields": {
        "name": form_data.firstName,
        "last_name": form_data.lastName,
      }
    }
  }) %}

{# Returns the response from the Mailerlite API #}
{{ d(mailerlite_request) }}

When I change the consume() function too use the string mailerlite (the handle of the client I have set up in the control panel,) the request returns null.

Have I made a mistake in the client setup? The client is enabled and looks as follows:

consume-mailerlite-client consume-mailerlite-provider

Steps to reproduce

  1. Set up client in control panel
  2. Make request
  3. Receive null instead of valid response

Craft CMS version

4.4.6.1

Plugin version

1.0.0

Multi-site?

No

Additional context

No response

engram-design commented 1 year ago

There should be any errors logged in /storage/logs/consume.log - is there anything useful in there? One thing I did want to check is if your $MAILERLITE_API_KEY was actually Bearer xxxx not just xxxx, as that'll be required for the header.

I've just tested this myself with MailerLite using both methods, and that seems to work.

image
{% set mailerlite_request = consume('mailerlite', "POST", "subscribers", {
    query: {
      "email": form_data.email,
      "fields": {
        "name": form_data.firstName,
        "last_name": form_data.lastName,
      }
    }
  }) %}
engram-design commented 1 year ago

I should also mention that when using CP-based clients, caching wasn't properly being cleared, and POST requests were being cached too, which is addressed in 1.0.1, which might add to the confusion of responses.

jannisborgers commented 1 year ago

Hi @engram-design, thanks for looking into this so quickly.

The logs showed a cUrl error 3 (URL using bad/illegal format or missing URL). I changed the base URL for the client to https://connect.mailerlite.com/ (without /api/) to follow the MailerLite docs exactly and used api/subscribers as my endpoint. Don‘t know if that should make a difference, but: The response comes through.

Now it returns an 401 Unauthorized error. The response: {"message":"Unauthenticated."}

The environment variable $MAILERLITE_API_KEY is Bearer xxx. When I remove it from the client in Consume and type that directly into the client header field, the request goes through. As soon as I change it back to using an environment variable, it reverts to the 401 error.

engram-design commented 1 year ago

I actually had some strange issues with their API. I've tested it before with Formie but using the same account and API key didn't work with their docs. I had to migrate the account to their new system. I'm not sure if that's a factor on your end, probably refer to this:

image

And yeah, that shouldn't make any difference with the base URI including that or not.

But, I believe I know the issue. Those settings don't support .env variables correctly. Refer to 1.0.2

jannisborgers commented 1 year ago

I can confirm that 1.0.2 fixes this issue and the request goes through successfully.

Thanks @engram-design!