@manoj-patil Have you checked out the documentation on this? Is there something missing. I imagine that if you want all network traffic, you would have to configure that separately than the logs you get from FusionAuth activity since that would be at the networking level.
administrators
-
RE: All log
-
RE: How to get event.info.deviceDescription in events webhook (ex user.login.success)?
@rabah-laouadi What information is in the device.description that is not in the info section?
"info": { "deviceName": "macOS Chrome", "deviceType": "BROWSER", "ipAddress": "192.168.65.1", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36" },
Or are you specifically trying to get a custom value in your url? If you let us know a little more about what exactly you want to accomplish, we may be able to find a way to get it done.
Also have you seen this post?
-
RE: Redirect loop between login and consent page during OAuth2 authorization (Proof of Concept)
@jefferson-piscos, the debug enabled is under the OAuth tab. Go ahead and enable that and check the logs.
Also it is a little weird that you are redirected to a consent screen. Do you have any consents configured? You can go to Settings -> Consents in the Admin UI.
Then you can check the user and see if you have any set for the user you are testing.
Hopefully that will clear it up and you will be good to go. If not, let's see what those logs say.
-
RE: Redirect loop between login and consent page during OAuth2 authorization (Proof of Concept)
@jefferson-piscos There are a few things that may be going on. Where are you you expecting to redirect to after successful login? Can you tell if that page is being hit or is it redirecting back to the login page because that is the page you set it to? Anything you can safely share about the application configuration in FusionAuth or code for your redirect page could be helpful.
It terms of tips for debugging, you can turn on "Debug Enabled" for the identity provider and then check the Event Log after you try to log in. Let us know if that yields any useful information.
-
RE: Issues with multi-tenant refresh token revocation and custom JWT signing
@michaelginn529 What do you have your "Logout behavior" set to for the application? Any other specific configuration you can share would help as well.
-
RE: Proxy IP Issue
@haziqt Sounds like FusionAuth is up and working except reporting the wrong IP address of the user on login. You may want to consider opening a issue.
-
RE: Issue with Getting Started guide, invalid client
@raymondcamden Ha, gald you got it working. Generally, the quickstarts come with a docker file that you can just run docker compose against and it will get you the instance. That instance would be configured to work with the sample code for that quickstart. The application and uses would be created and things like that. If you have it working the way you want, awesome. If you run into other issues, please just let us know.
-
RE: Implementing Phone Number Verification in FusionAuth Without Enabling 2FA
Just an FYI, as of 1.59.0, phone number verification is now fully supported in FusionAuth.
Read more here: https://fusionauth.io/docs/lifecycle/manage-users/verification/gate-accounts-until-user-phone-verified
-
RE: How to deal with sign-up spam?
@atakan @theogravity-sb Seems like two different issues here.
@theogravity-sb is talking about attackers using the Google identity provider to create accounts with malicious names. @atakan is talking about attackers using self-service registration to create accounts with malicious names. They seem related but not identical. When you are allowing people to create their own identity and/or delegate to another source of identity, you decrease friction but give up some control.
The bad news is that FusionAuth has nothing out of the box to stop this behavior.
The good news is that you can build an integration to stop it. There are email verification services that give you a risk factor for email addresses and you can check that before you allow for registration or login.
Here's a blog post I wrote about leveraging a third-party service to check the validity of emails provided during registration. This post uses a self-service registration validation lambda, but for the Google identity provider use case, you could use the login validation lambda and perform the same type of check.
While I used Fideo because it had a good API and I had a connection there, I have not done an extensive survey of the landscape of email verification services, so cannot recommend any particular service.