Currently, the JWT plugin returns a 403 status when an invalid or expired JWT token is sent in the Authorization header, but it does not stop processing the request. I think this is logically and semantically incorrect, and that no processing of the request should take place.

The current approach prevents a retry handler being used on the client side to refresh a token and re-attempt the query without deep understanding of every query or mutation that was executed, because the query or mutation may not fail, but may fail to return the expected data (for example, a customer's orders) or fail to execute the mutation in the way intended (for example, creating an anonymous comment vs a comment from an authenticated user).

Aborting the request all together is, IMHO, the path of least surprise. It allows a quick recovery when a token has expired (reducing round trip time because less processing has to be done on the 403 response), and the client is not left trying to figure out what did work, what didn't work and what had an unintended side effect.

WP REST has the [rest_authentication_errors](https://developer.wordpress.org/reference/hooks/rest_authentication_errors/) hook that authentication plugins can return a WP_Error with that will stop processing. I think that this is a good pattern to follow.

Other GraphQL implementations fail without processing the request on invalid/expired authentication credentials. Some examples: Postgraphile, Prisma

I'm trying testing expired token test via postman after login, I'm waiting for 5 minutes, for testing token expired but get a response like this one

{
    "errors": [
        {
            "debugMessage": "invalid-jwt | The iss do not match with this server",
            "message": "Internal server error",
            "extensions": {
                "category": "internal"
            },
            "locations": [
                {
                    "line": 2,
                    "column": 3
                }
            ],
            "path": [
                "generalSettings"
            ]
        }
    ],
    "data": {
        "generalSettings": null
    }
}

is there anything I'm missing for setup?

Hi. I downloaded and activated this plugin, yet nothing changed. It added a login endpoint to graphql, but all admin requests, without or without a bearer header, return an empty array for nodes, just like before the plugin. I know headers on my site are working because I was using the rest api with headers before. From what I gather, it should throw an error if the header is missing but I can query orders, and the nodes are just empty no matter if there is a valid header or not. Im not sure how I can provide further info. The site is khemlanimart.com and I followed Readme instructions.

Hi, I am using the login mutation in GraphiQL like this:

  login(input: $input) {
    authToken
    user {
      id
      name
      userId
      nicename
    }
    customer {
      customerId
      id
      firstName
    }
  }
}

I can only log in the admin. With every other user, I get the following error:

{
  "errors": [
    {
      "debugMessage": "Cookie nonce is invalid",
      "message": "Internal server error",
      "category": "internal"
    }
  ]
}

Help yould be greatly appreciated. Thanks for the great work!

When get_secret_key() gets called at line 557 of Auth.php, the function doesn't find GRAPHQL_JWT_AUTH_SECRET_KEY nor the filter graphql_jwt_auth_secret_key, so we end up with a NULL value.

Also, I think ! empty( GRAPHQL_JWT_AUTH_SECRET_KEY ) will always return true even if it's not defined, just like happens in the case above.

I am getting "Internal server error" in login mutation after upgrading to wp-graphql v 0.3.

Is it coming from 'user' => DataSource::resolve_user( $user->data->ID )?

My mutation

mutation loginAndGetTokenAndUser($username: String!, $password: String!) {
  login(
    input: {
      clientMutationId: "gonzo"
      username: $username
      password: $password
    }
  ) {
    authToken
    refreshToken
    user {
      id
      userId
    }
  }
}

The error

{
  "errors": [
    {
      "message": "Internal server error",
      "category": "internal",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "login"
      ]
    }
  ],
  "data": {
    "login": null
  }
}

After hitting activate plugin... I receive the following error.

Warning: require(/var/www/html/wp-content/plugins/wp-graphql-jwt-authentication/vendor/composer/../symfony/polyfill-mbstring/bootstrap.php): failed to open stream: No such file or directory in /var/www/html/wp-content/plugins/wp-graphql-jwt-authentication/vendor/composer/autoload_real.php on line 66

Fatal error: require(): Failed opening required '/var/www/html/wp-content/plugins/wp-graphql-jwt-authentication/vendor/composer/../symfony/polyfill-mbstring/bootstrap.php' (include_path='.:/usr/local/lib/php') in /var/www/html/wp-content/plugins/wp-graphql-jwt-authentication/vendor/composer/autoload_real.php on line 66

Hi

I'm trying to figure out how this plugin with React-Native. I believe I set it all right and I believe this has something to do with authorization. Appreciate if you guys can point me to the right direction on how to get it right with this query

query CustomerQuery($id: ID!) {
  customer(id: $id) {
    billing {
      address1
      address2
      city
      postcode
      state
      country
      phone
    }
  }
}

and here is how I set up the apollo client (apollo.ts)

import { ApolloClient, HttpLink, InMemoryCache, ApolloLink } from '@apollo/client';
import { asyncMap } from "@apollo/client/utilities";

import GRAPHQL_API_URL from './constants/Api';
import { getUserInfo, getToken, removeUserInfo, storeUserInfo } from './Utils'

// https://github.com/imranhsayed/woo-next/blob/master/components/ApolloClient.js
export const afterware = new ApolloLink((operation, forward) => {
  return asyncMap(forward(operation), async (response) => {
    const context = operation.getContext();
    const { response: { headers } } = context;
    const session = headers.get("woocommerce-session");
    const token = await getToken();

    if (session) {
      if ("false" === session) {
        console.log('invalid session', session)
        // await removeUserInfo();
      } else if (token !== session) {
        const userInfo = await getUserInfo();
        const updatedUserInfo = {
          ...userInfo,
          wooCommerceSession: headers.get("woocommerce-session")
        };
        storeUserInfo(updatedUserInfo);
      }
    }
    return response;
  });
});

const authMiddleware = new ApolloLink((operation, forward) => {
  return asyncMap(forward(operation), async (response) => {
    const token = await getToken();
    console.log('token for apollo', token);
    response.headers = {
      'Authorization': `Bearer ${token}`,
      // 'woocommerce-session': 'Session'
    };
    return response
  });
})

const httpLink = new HttpLink({
  uri: GRAPHQL_API_URL,
});

export const apolloClient = new ApolloClient({
  link: authMiddleware.concat(afterware.concat(httpLink)),
  cache: new InMemoryCache(),
});

updated to call the 'header' instead of 'set_headers' method when writing response headers to avoid overwriting all the headers such as X-WP-Total and X-WP-TotalPages which are necessary for different plugins and pieces of Wordpress to work properly

I am running the latest version of the plugin on the latest wordpress. With the plugin I am able to login a user and get an auth token. I'm facing a few issues

1. When I go to activate protected api I get the following error in my react application: Error! Network error: Response not successful: Received status code 403 Not even the login route would work anymore. How do you restrict all content in wpgraphql and allow only queryies and mutations like forgot password, login, register etc. Right now this plugin just kicks everyone out. Another strange thing is that despite this, the data is still beign returned to the console.

2. On the topic of securing routes,..I used this example: https://www.wpgraphql.com/2019/01/30/preventing-unauthenticated-requests-to-your-wpgraphql-api/ but it also does not get_current_user_id() when the user has logged in so please help

How long do tokens last until they expire? I see for the rest api JWT plugin there's a filter to increase the time before expiry. Does this plugin have something similar?

Thanks!

Hi guys,

I am receiving an Internal server error when the token expires without any other useful message that helps me identify the error's cause.

E.g:

However, if I enable the "Enable GraphQL Debug Mode", it returns the cause (invalid-jwt) of the issue but there is a warning on that option not to allow that on the production environment. Screenshot:

The status code is always 200 for both cases.

Is there anything I can do to receive the error on the production environment when sending an expired token?

Hi everybody, I'm trying to access the endpoint through the official WPGraphQL Plugin from the WP Plugin Library. The plugin features the option to disable all requests, except authorized ones:

In order to use this feature I installed this plugin wp-graphql-jwt-authentication. But with the option from above activated it doesn't allow access to the login field anymore: The field \"RootMutation.login\" cannot be accessed without authentication.

How should I deal with this? I know the plugin works, for example querying users only works with authentication through this JWT plugin. But I want to restrict access to every endpoint, including Pages, Posts, etc., except for the Authentication Enpoint. How can I achieve this, if this plugin doesn't work with the option from WPGraphQL? Thanks for any ideas! Cheers!

I have applied filter for this "graphql_require_authentication_allowed_fields". It's from the official documentation for allowing login field from the authentication. But it's not working.

`add_action( 'do_graphql_request', 'force_graphql_api_authentication', 10, 1 );

function force_graphql_api_authentication( $query ) {
if ( ! defined( 'GRAPHQL_HTTP_REQUEST' ) || true !== GRAPHQL_HTTP_REQUEST ) {
    return;
}

$introspection_query = \GraphQL\Type\Introspection::getIntrospectionQuery();
$is_introspection_query = trim($query) === trim($introspection_query);

if ( $is_introspection_query ) {
    return;
}

if ( ! get_current_user_id() ) {
    throw new \GraphQL\Error\UserError( __( 'You do not have permission to access the API', 'preachitgwl' ) );
}
}

add_filter(
'graphql_require_authentication_allowed_fields',
function( $allowed ) {
    $allowed[] = 'login';
    return $allowed;
}, 10, 1 );`

This happens only when WPGatsby plugin in installed on wordpress

wp-graphql-jwt-authentication / release-v0.5.2

Ran into this issue after trying to fetch Gql data using authToken.

File to edit: \wp-content\plugins\wp-graphql-jwt-authentication-release-v0.5.2\src\Auth.ph

This change fixed it , Now I can fetch data from Gql

try { $token = ! empty( $token ) ? JWT::decode( $token, self::get_secret_key(),array_keys(JWT::$supported_algs) ) : null; } catch ( Exception $exception ) { $token = new \WP_Error( 'invalid-secret-key', $exception->getMessage() ); }

tried passing in array('HS256') or ['HS256'] didnt work. idk why!!...

P.S. did break my head for a day .... Hope it helps someone.. #notaprogrammer

Feel free to optimize this code!!

Probably a bit niche, but this bit of code (https://github.com/wp-graphql/wp-graphql-jwt-authentication/blob/develop/src/ManageTokens.php#L345) somehow removes the Location header off of certain IndieAuth responses.

Well, this one response right here: https://github.com/indieweb/wordpress-indieauth/blob/trunk/includes/class-indieauth-authorization-endpoint.php#L273

Now, I can't say I fully understand what's going on, but that Location header "just works" again if in src/ManageTokens.php I comment out the $response->set_headers() call on line 345-355.

(Was somehow hoping that merely adding a second ("override") parameter equal to false to the $response->set_headers() call would get it to leave existing headers alone, but that doesn't seem to do much at all.)

I also noticed how just above it says, "The Access-Control-Expose-Headers aren't directly filterable for REST API responses, so this overrides them altogether."

I'm wondering if that's the case, still, as WP core seems to now set these as follows (since WP5.5, in wp-includes/rest-api/class-wp-rest-server.php):

$expose_headers = apply_filters( 'rest_exposed_cors_headers', $expose_headers );
$this->send_header( 'Access-Control-Expose-Headers', implode( ', ', $expose_headers ) );

Again, not 100% sure, but it looks like rest_exposed_cors_headers might be the filter you're looking for here. Seems it would allow one to just tack on the X-JWT-Refresh header.