Invalid iat parameter

Thanks for the bug report and for investigating the problem.

I think I've seen this too -- I'll check my project's case tracker when next at work.

> e.g. "Wed Mar 15 2023 16:01:46 GMT+0000". They have stated that this "must be an integer (no decimals) and it must be in UTC

What does 'integer' mean in this context? Is the example format you give an example of what we're doing wrong, or of what Zendesk should receive?

Thanks for the reply. This is an example of what was sent - apparently it should be standard integer with no decimals so I'm assuming Unix Timestamp

If it helps - two further things I've done to rule things out:

Tried changing the following in the ZendeskSSOController.php file:

Changed $url variable to static domain with /access/jwt - no change
Changed getRequestTime() to getCurrentTime() - no change

Strangely, clearing the cache under Performance on Drupal does allow the user to login briefly to Zendesk via SSO.

That's interesting! I wonder what is getting cached that causes the problem.

Can you step through it with a debugger to try to find out?

It's definitely a caching issue - Zendesk confirmed through their logs that a request iat value was the same 6 minutes later which is beyond their 3 minute tolerance.

Unfortunately, debugging this is beyond my knowledge.

However, what I have done to confirm it is the cache is enable the Mix module and put the site into Development mode and this fully resolves the issue which means its the either the Twig cache, backend cache or browser/proxy cache as these are disabled by the Mix module in dev mode.

> either the Twig cache, backend cache or browser/proxy cache as these are disabled by the Mix module in dev mode.

In your settings.local.php file, copy this line:

$settings['cache']['bins']['render'] = 'cache.backend.null';

and try changing the 'render' to different values for different types of cache. The possible values are the names of the cache_* tables without the cache_ prefix.

If it's browser cache though, I don't know how we'd fix that.

Looks like uncommenting this line:

$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';

Fixes the issue

Interesting!
I wonder what's getting put in the dynamic page cache to cause that.
Thanks for investigating?

This is what we pass to zendesk:

          'iat' => \Drupal::time()->getRequestTime(),

The return value of getRequestTime() is a unix timestamp.

It looks like Zendesk support's analysis of the cause for the problem is wrong.

I've figured it out -- the redirect to zendesk was getting cached, so users were getting a stale token, AND one that was possibly not even for their user!

Should be fixed. Thanks for your help figuring this out!

Releasing a new alpha now -- please test! :)

Automatically closed - issue fixed for 2 weeks with no activity.