@david-cuen perfect. I was copying themes, but will us that one and let you know what I find.

@alexandros-nafas , were you able to figure it out?

@johnmiller It looks like the issue is that the 'retrieve a user via JWT' functionality was removed in 1.60.0. (It appears the User API JWT authentication method was deprecated in version 1.50.0. An issue has been filed to remove it from the client libraries.

Thank you from bringing this to light.

@bernardo-munz Did you play with the SameSite setting?

@simon-chrzanowski can you please share the code you using? (please be sure to hide anything sensitive like your API Key)

@mark-robustelli Thanks, I think that's resolved it!

@dan said in Error getting list application due to sql error (mysql):

@traperwaze said in Error getting list application due to sql error (mysql):

MariaDB server

I believe the issues is that we don't support MariaDB.

This is a known issue: https://github.com/FusionAuth/fusionauth-issues/issues/367 poki

Do you see the same issue with a supported version of MySQL or PostgreSQL?

Thanks for confirming. That lines up with what I’m seeing as well. We are indeed running MariaDB, and it looks like the JSON operator (->>) used in that query isn’t supported the same way in MariaDB, which would explain the syntax error.

We haven’t tested this yet on a supported database, but based on the linked issue and your comment, it does appear to be a MariaDB compatibility problem rather than a misconfiguration on our side. We’ll plan to test against a supported version of MySQL and/or PostgreSQL to confirm.

Appreciate you pointing us to the GitHub issue — that helps clarify things a lot.

@dalamenona We had the same error with Prometheus.
The following opened FusionAuth issue contains information about the topic

https://github.com/FusionAuth/fusionauth-issues/issues/3082

Best regards.

@dan said in Claims to check when using google as an idp for google workspace:

You should start by checking the relevant google documentation.

As of writing, this is what their doc says:

Using the email, email_verified and hd fields, you can determine if Google hosts and is authoritative for an email address. In the cases where Google is authoritative, the user is known to be the legitimate account owner, and you may skip password or other challenge methods.

Cases where Google is authoritative:

email has a @gmail.com suffix, this is a Gmail account. email_verified is true and hd is set, this is a Google Workspace account.

Users may register for Google Accounts without using Gmail or Google Workspace. When email does not contain a @gmail.com suffix and hd is absent, Google is not authoritative and password or other challenge methods are recommended to verify the user. email_verified can also be true as Google initially verified the user when the Google account was created, however ownership of the third party email account may have since changed.

So in this case, you want to check that hd is set as well as that email_verified is true.

With FusionAuth, you can check this using a reconcile lambda and looking at the id_token:

https://fusionauth.io/docs/extend/code/lambdas/google-reconcile https://fusionauth.io/docs/extend/code/lambdas/openid-connect-response-reconcile

Thank you from bringing this to light.

@Ruka , this seems like something that should be reported as an issue.

@patrick_ag Is this just when you are loading the page or are you trying to take some action?