@dan I did not have FUSIONAUTH_APP_MEMORY set so it was just at the default value.
I upped the value to 1gb when the container had 1gb and it no longer crashed with out of memory errors however the container would still die then restart. Not seeing any logs for it.
I tried making the value smaller than 1gb but it behaved the same. I then upped the container to 2 gb of memory and set FUSIONAUTH_APP_MEMORY to 1gb. Now it seems to be working ok and not crashing. Is there some further performance tuning that I can do on it?

@dan Thanks for the reply Dan, I'll go ahead and discuss this with my team before we go any further.

Just to double check, could the FusionAuth team revise this document's flow chart of the logout request if it's no longer correct? https://fusionauth.io/docs/v1/tech/guides/single-sign-on, or perhaps specify that the Logout request is specific to the FusionAuth app, not Pied Piper? Thanks.

e27f08e0-7665-46f9-a89f-f26637003a18-image.png

Hi @luis-b !

I would use step up auth for this situation.

It is documented here: https://fusionauth.io/docs/v1/tech/guides/multi-factor-authentication#step-up-auth

Hi @vinicius-alfonso !

As documented here: https://fusionauth.io/docs/v1/tech/oauth/endpoints#userinfo we don't provide the address info, even if you pass the address scope.

Per the OpenID spec, section 5.4, it appears that supporting the address scope is optional: https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

If this is important to you, please file an issue here: https://github.com/fusionauth/fusionauth-issues/issues with details about the use case.

We are guided by our customers and community when it comes to implementation of issues. Here's our general roadmap guidance: https://fusionauth.io/docs/v1/tech/core-concepts/roadmap

@jesper What does the Security tab on your application config say?

In particular the Generate refresh tokens setting?

https://fusionauth.io/docs/v1/tech/core-concepts/applications#security

@joshua Thank you for updating the docs. I can confirm simply increasing the numberOfResults indeed returns the rest of the users!

@utahtwo Currently this requires two different configurations. We initially tried to do it all within one IdP, but each mode requires different configuration and has unique security constraints. It seemed simpler for all involved to make them separate IdP configurations.

If there is a use case that breaks due to this design decision, please open a GitHub issue and outline the use case so we can better understand your needs. Thanks!

@jw

Can you confirm if you are still having this issue?

This consent screen may be controlled by Google (and possibly unrelated to FusionAuth configuration)

Thanks,
Josh

@admin-5

Thanks for letting us know. This should now be corrected.

Thanks,
Josh
FusionAuth

@ramonsaucedo Glad you got it working!

@matt-1

I would assume that is the issue - but let us know if otherwise

Josh

@depth9mcd This is typically accomplished using a proxy (Apache, NGINX, etc) in front of FusionAuth.

https://fusionauth.io/docs/v1/tech/admin-guide/proxy-setup#proxies-and-tenants has more details.

However, please feel free to file a feature request with your suggestion for a lambda to run before the authorize page is rendered: https://github.com/fusionauth/fusionauth-issues/issues