@david-cuen This is really weird. I was not able to replicate it. There is one more thing I may try later if I get some time. That is to make one template that big and try that.

In the mean time, I went back to look at the error message. "Premature EOF" and the fact that it was working on a windows box has be back to believing that a funky character or something is causing the error on the linux box. I wish we could narrow it down. Have you tried to install into another linux environment, EC2 for example, and see if you get the same issue? (That may tell us if it is a linux thing or if it is your one specific environment.) Also, someone mentioned to ask if you have any proxies running in front of FusionAuth?

@tim-clark Can you please point to the community discussion where this comes up? I could not find it in the issues.

@hemanth18pages raising the support ticket is the way to go for sure. It will be good to know if anyone else is experiencing this too.

@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)

@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.

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