Hard to know exactly what's going on.

I would try creating another tenant and seeing if the same SMTP settings fail. Then I'd try standing up a version with the very latest FusionAuth version and seeing if you see the same behavior.

Also, do you have the same tenant smtp settings? That is under the "advanced" tab, then "smtp settings".

But if I put these in the application, won't this be a security problem?

If you put them in a javascript app, yes. But if they are in the php application only, then it'll be like a database password. Not really a security issue.

You could also inject them as an environment variable or pull from a secrets manager; however you manage your database credentials, I'd suggest doing the same with the client id/secret.

@maciej-wisniowski That was done when we found that there was a bug in

#FROM fusionauth/fusionauth-app:1.19.4

and we replaced it with:

FROM fusionauth/fusionauth-app:1.19.7

@joseantonio said in Identity Provider with no email?:

I need to make an API call inside the SAML reconcile. Is this possible?

Nope, this is currently not possible, unfortunately.

Upgrading lambda functionality to support network requests is an open issue. Please vote it up if it is important to you.

If this is very important to you, you can engage our professional services.

More on the FusionAuth roadmap.

Awesome!

thanks , I will do just that

Best Regards,

Thanks @sjswami , this duplicate ids issue is now resolved in 1.19.7. Appreciate you letting us know about it: https://github.com/FusionAuth/fusionauth-issues/issues/890

solved. I needed to type DELETE.

Thanks awesome @richb201 !

I'm glad you were able to sort it out!

@dan Thank you for your support. Fixing the signature just saved me another couple of hours (also coming from https://fusionauth.io/blog/2020/07/14/django-and-oauth/) ^^

Hi,

Thank you for this i have managed to get past the issue with the database i changed to to postgres SQL and it worked fine, I'm just to figure out if i can ass Exchange 2016 to this application so users are made to get a Auth code before they can logon to exchange.

Thanks,

Related GitHub issue with details.
https://github.com/FusionAuth/fusionauth-issues/issues/178

In case anyone else would like to do the same, I have found a solution which I have detailed here:

https://github.com/FusionAuth/fusionauth-issues/issues/822#issuecomment-680172776

Thanks, that's great to hear!

We have a long term project to overhaul the client libraries but it's on hold for right now. Appreciate the feedback.

I wrote a guide for running fusionauth in a clustered/multi node setup: https://fusionauth.io/docs/v1/tech/installation-guide/cluster/

The bug about the ip addresses being the same (which was only a display bug, not a functionality bug) was also addressed in 1.23.0: https://fusionauth.io/docs/v1/tech/release-notes/#version-1-23-0

@dan

Hello,

I am happy that I got the answer for my doubt by going through the conversation.

thank you so much.

Samo

I'm so glad you solved it!

@sswami said in After Chrome 80+ Cookie Set SameSite=None requires 'Secure' in Android WebView doesn't seem to complete Authorize:

I don't know, if what I am doing is best practice or was there something else I should have done, at least this is working for me as now.

In the blog post I mention, the app uses the react-native-app-auth library, that may be worth investigating as it provides the hooks into the native browser.

This may be worth investigating so you don't have to support your own solution, though of course I'm glad you have it working.

There is another issue, calling /api/logout?global=true&refreshToken={refresh_token} only signs out of the app, but doesn't signout from the FusionAuth completely, making it redirecting back to the App instead of the Login Screen?

You should remove your access tokens in your client when the logout button is pressed. The FusionAuth logout API only removes cookies. This post may be helpful: https://fusionauth.io/community/forum/topic/270/logout-questions

@joseantonio,

I am checking on this for you; will let you know if I hear anything on a partial upgrade, but it is not one of our current offerings from our Sales/Marketing team.

I suspect that if you were to spin up a few (small) example applications and try writing your own cookies through a proxy, that may give a better understanding of the problem space and available approaches.

I will let you if I hear more

Thanks,
Josh

This issue was resolved and released as part of 1.24.0.

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

@didier-rano

It looks like there are two issues.

The first is that the SAML login lambda runs after the JWT populate lambda (or at the least the order is indeterminate) so your groups aren't being propagated, at least for Azure AD. More concerning to me is the fact that you are only seeing one SAML reconciliation for your user. I would expect that lambda to run every time the user logs in.

These feel like issues to raise on our issues repo, preferably with reproduction steps. I have been trying to find time to replicate it and file the issue, but if you can, that'd be very helpful.

The second is whether we support Enterprise Applications. I don't know if any of the community is using that particular feature. That does make sense why you are not interested in OIDC, however. Do you have a link for the Azure docs on this so I could learn more (I googled for them, but wasn't able to find anything relevant).