@dan said in Having trouble using Gmail SMTP for email sending:

Found a way to solve it.

You really need to use 16-char app passwords with Google SMTP, as it is suggested here https://support.google.com/accounts/answer/185833/tunnel rush

It works fine then.

🤠 😊

@srikanth-bussa Great.

If you need to customize the JWT, I'd suggest looking at the populate lambda and lambda HTTP connect as well.

Hiya,

Yes, you complete a login after the user has logged in at the SAML provider. That's implied, but maybe we should make it a bit clearer.

From https://fusionauth.io/docs/v1/tech/apis/identity-providers/samlv2#complete-a-saml-v2-login

This API allows you to complete a SAML v2 login after the user has authenticated with a SAML v2 identity provider. If you are using the FusionAuth login UI with the SAML v2 button you will not utilize this API directly.

The idea is:

you call start SAML login (the FusionAuth API) you direct the user to the IDP you get the SAML response you pass the SAML response to the complete API call (again, FusionAuth API)

Why not just integrate SAML directly into your application? It's an instance of the identity broker pattern, and having FusionAuth in the middle can allow for a standard interface across SAML and other remote IdP providers.

How you handle steps 2 and 3 is not documented for two reasons.

It might vary widely, depending on the SAML IdP and your configuration. It is expected that as someone who is using the start/complete API and not the FusionAuth hosted login pages, you are familiar enough with SAML to take care of them.

Hope this helps!

@dan Thanks, this is the use-case I was expecting.

The easiest way is to add the required header to the ngrok connection.

Here's how you can do it:

./ngrok http --request-header-add 'X-Forwarded-Port:443' 9011

That should fix the issue.

@joshua okay thank you for reply.

@duke said in UpdatinG User with JSON-PATCH method:

@dan It was abit confusing because looking at the original body of the group, there was no parameter/ field called roleIds but it was used in the request.

To update the User we used this.

// To remove language let body = vec![Testing { op: "remove".to_string(), path: "/user/preferredLanguages/0".to_string() }];

thanks my issue has been fixed.

@ken Did you get this resolved?

@ken Hiya,

I don't think this is currently available via API. The closest issue I could find was this: https://github.com/FusionAuth/fusionauth-issues/issues/1515

I can't commit to a timeline for this feature being built out, however.

Please upvote that and/or add a comment illustrating your use case.

@2kayush-125 It's in the tenant settings.

The UI is documented here: https://fusionauth.io/docs/v1/tech/core-concepts/tenants#advanced (look for "Change Password")

The API is documented here: https://fusionauth.io/docs/v1/tech/apis/tenants (look for tenant.externalIdentifierConfiguration.changePasswordIdTimeToLiveInSeconds)

Hope this helps.

Thanks for using FusionAuth!

@ken

Hiya,

The information about whether an application has an IdP configured for it is stored on the identity provider object, not on the application.

So the easiest way to answer your question is to retrieve all the identity providers (or one, if you have a target), then filter through the JSON looking for your application id.

https://fusionauth.io/docs/v1/tech/apis/identity-providers/#retrieve-all-identity-providers shows how to list all Identity Providers.

If you look at the results, you'll see a field similar to:

"applicationConfiguration": { "1c212e59-0d0e-6b1a-ad48-f4f92793be32": { "createRegistration": true, "enabled": true } },

for each of the identity providers.

The applicationConfiguration has keys, each of which is an application Id.

Does that help?

@pclark

Thanks for sharing this. I filed an issue based on your helpful post.

@ken

Hiya,

Sorry, I'm a bit confused.

What version of FusionAuth are you running? Which type of identity provider are you setting up?

I just logged into our sandbox instance: sandbox.fusionauth.io and was able to add an identity provider and edit it and saw the "Linking Strategy" both times.

Thanks,
Dan

@yb98

Heya, this isn't something we document, so it is considered an implementation detail that could change at any time.

You could file an issue asking this to be codified and documented, but I'm not sure we'd do that. It's more likely we'd do something like this: https://github.com/FusionAuth/fusionauth-issues/issues/1515

Thanks for using FusionAuth!

You cannot display a lot of websites inside an iFrame. Reason being that they send an "X-Frame-Options: SAMEORIGIN" response header. This option prevents the browser from displaying iFrames that are not hosted on the same domain as the parent page.

I faced the same error when displaying YouTube links. For example: https://www.youtube.com/watch?v=8WkuChVeL0s

I replaced watch?v= with embed/ so the valid link will be: https://www.youtube.com/embed/8WkuChVeL0s

It works well.

Try to apply the same rule on your case.

SAMEORIGIN

The page can only be displayed in a frame on the same origin as the page itself. The spec leaves it up to browser vendors to decide whether this option applies to the top level, the parent, or the whole chain, although it is argued that the option is not very useful unless all ancestors are also in the same origin.

@voidmain Thank you!

@etienne-caldo Hey Etienne, this is a good question, there is some context that goes behind it and usually we would want to have a discovery coffee session to elaborate on the matter. Let me know if this is of interest to you.

No.

You can't explicitly revoke an access token in FusionAuth. We don't support RFC 7009: https://www.rfc-editor.org/rfc/rfc7009.html and based on the number of upvotes for this, I don't know if the community wants us to: https://github.com/FusionAuth/fusionauth-issues/issues/201 But if you do, feel free to upvote that issue.

If you want to have an access token become invalid, you have to manage it yourself. That is what is outlined in this article.

The process is basically:

set up webhooks to fire to all the resource servers when a refresh token is invalidated (when the user logs out) listen for that event, and when it occurs, record the user with the invalid token in the resource server (in redis, db, etc) next time an access token is presented, verify that it is not for a user who has logged out

If you want to handle the case where a user logs out, then logs back in quickly, then the time based logic in the Webhooks section here: https://fusionauth.io/learn/expert-advice/tokens/revoking-jwts needs to be implemented.

Thanks for the update!