Posts made by joshua

@williamjeanmireault

It sounds like you would like to be able to read state or similar in a lambda (we don't currently allow this)

In a populate lambda, you do have access to

• Entity Data (https://fusionauth.io/docs/apis/entities/entities) (entity.data)
  This means that you can set any custom field you would like on your entity and use that in a populate worklfow
• .fetch() https://fusionauth.io/docs/extend/code/lambdas/#using-lambda-http-connect

So you could access custom data attributes or call out to another system in the lambda

If you have access to a support contract, you can also log a support ticket if you would like or open a feature request outlining your requirements
https://fusionauth.io/docs/operate/troubleshooting/technical-support

@dan Also, depending on the workflow, if a user does NOT federate but does NOT check "trust this computer" they will NOT establish "MFA trust". Without trust, a user will be prompted to MFA again. Of couruse, With "MFA trust", they will not be prompted. This answer is implicit to this conversation, but MFA policies and FusionAuth center around this check box and trust (with the current edge case of Federation noted).

I'm seeing this message:

exec /usr/local/fusionauth/fusionauth-app/bin/start.sh: exec format error

when I try to upgrade FusionAuth. I'm running containers.

@dan continuing in a support thread.

Note for future folks -

Resolved under this issue https://github.com/FusionAuth/fusionauth-issues/issues/1742

And in version 1.44

https://fusionauth.io/docs/v1/tech/release-notes#version-1-44-0

@imsurya2442

Thanks for the question.

This may be related https://github.com/FusionAuth/fusionauth-issues/issues/2019. If it is, there is a workaround listed that you could attempt.

Thanks,
Josh

@lambert-torres replied out of band to this forum. This may have been addressed in version 1.38.0 and beyond.

Thanks,
Josh

@david-cheal

Since FusionAuth hosts each customer on their own servers (you are not sharing hosts with other customers as in a traditional SaaS model), you can determine when (or if) you want to upgrade your server in FusionAuth Cloud.

• https://fusionauth.io/docs/v1/tech/installation-guide/cloud#upgrade-duration

If you would like to further weigh your options, you can reach out to our sales team for advice on what may best support you.

https://fusionauth.io/contact

Thanks,
Josh

@stefan-0

Thanks for the question -- I don't think that this will work in the way that you intend.

I would have to test to be sure, but if FusionAuth cannot make the user (based on your chosen user provisioning policy), then this user will not be created and thus not linked, and therefore this event will not fire.

https://fusionauth.io/docs/v1/tech/events-webhooks/events/user-identity-provider-link

Depending on your desired outcome, it might be best to change your linking strategy (to create this user when linking) and then use user.create webhooks. You could fail this transaction if certain requirements are not met (thus the user will not be created and linked).

I hope this helps!

Thanks,
Josh

@quent Thanks for the question!

To note, each IdP will handle logout differently. It would be hard for FusionAuth to know how to log each user out of disparate systems. Killing each user session is specific to that IdP implementation. In the FusionAuth logout process, we will call a logout endpoint of your choosing. In that endpoint, you could have your integration call the IdP to remove the user's session.

I hope this helps!

Josh

@paul-fink marking this thread as being addressed out of this forum band.

-Josh

@zradick

Thanks for the question - if you remove the quotes from your args, that may resolve the issue.

- FUSIONAUTH_APP_ADDITIONAL_JAVA_ARGS=-Djavax.net.ssl.keyStore=/fusionauth/example.p12 -Djavax.net.ssl.keyStorePassword=****

Our documentation may need to be updated to address this

https://fusionauth.io/docs/v1/tech/admin-guide/securing#custom-keystore

Josh

@david-moreno

Is this still an open issue for you? If so, including the debug information (and turning on debug for the SAML IdP can be helpful) as you complete the SAML handshake.

• Josh

@leandro-menagonzalez Sorry - I was traveling for a bit and then under the weather.

Were you able to resolve this?

If not, my understanding is that this would be a mapping problem. Essentially, Google would have to be instructed to send over a profile pic url, and FusionAuth would consume that in the AuthN response. Further, a reconcile lambda can be used to grab this URL attribute and store on the user, etc. Let me know if I am misunderstanding the issue.

Josh

Hi @leandro-menagonzalez

Thanks for the question. If I am understanding correctly, if you are expecting a certain attribute to be returned in an AuthN response, this would require additional configuration on the part of Google. Is there a configuration tool on that side to add an additional attribute to be sent in an AuthN response?

Thanks,
Josh

Hi @josh-dura -

Is this still an open issue for you? The event logs are stored in the DB, so you should be able to access them by navigating in the admin UI ( system > events log ) to get a better idea of what might be occurring.

Thanks,
Josh

Hi @lambert-torres

Can you please provide some context as to what you are looking to achieve?

Are you storing this data on the user.data.* fields? How are you storing this data/arrays programmatically?

Thanks,
Josh

Hi @cgonzalez

Can you confirm how quickly you are completing the exchange for a token using the code?

"auth_code_not_found"

The code may not be available if:

1. It has expired or
2. It as already been used to obtain a token.

Thanks,
Josh

@tashi This failure is related to how you are asking FusionAuth to complete the login.

For apple, you must complete a hybrid grant.

At a high level, here is how you will use the FusionAuth IdP Login API with Apple when you are not using our hosted login pages.

1. Begin the Authorization Code grant with Apple using a hybrid grant response_type=code id_token.
2. Collect the two tokens code and id_token sent to you by Apple on the redirect URL specified by the redirect_uri query parameter.
3. Send these two values to the FusionAuth IdP Login API. Do not complete the Authorization Code exchange with Apple using the Token endpoint.

Please also note that Apple has a separate configuration for Web and Mobile-based authentication. There are a few open issues that may be worth reviewing as well and could be influencing the behavior you are seeing

• https://github.com/FusionAuth/fusionauth-issues/issues/778
• https://github.com/FusionAuth/fusionauth-issues/issues/1248

Josh