Problems logging in user through C# API call
-
@xan ,
If you are seeing
localhost refused to connect
that may mean the server hasn't started or that you have a firewall blocking access to that port.Did you start the server?
https://github.com/FusionAuth/fusionauth-example-asp-netcore has the full codebase if you want to try to get it running before working through the tutorial.
-
This post is deleted! -
@xan said in Problems logging in user through C# API call:
I was thinking it was the .ipAddress but since the library has no commenting I have been shooting in the dark most of the time with all this.
How are you creating the client (
_faClient
) here? It looks like you might not be passing the host (which is typically athttp://localhost:9011
if you are developing locally). -
@dan said in Problems logging in user through C# API call:
_faClient
So _faClient is DIed. The service is setup here.
services.AddTransient<IFusionAuthAsyncClient, FusionAuthClient>(_ => { return FusionAuthClientBuilder.Build(context.Configuration); });
How do I check to see if the server has started? I have the firewall open on that port(in and out), and can login through the 9011 port.
This is setup on a ec2 server, so I am using a static ip to make calls to it, and I have those specified in my User secrets, which looks like.{ "UsersManagement":{ "ClientSecret" : "XXXX", "ApiKey" : "XXXX", "Server" : "http://xxx.xxx.xxx.xxx:9011", "Authority" : "http://SAME.AS.ABOVE:9011", "TenantId" : "XXXX", "ApplicationId" : "XXXX", "ClientID" : "SAME AS ABOVE" } }
Which looking at the example project you linked they have
"SampleApp" : { "Authority" : "http://localhost:9011", "CookieName" : "sampleappcookie", "ClientId" : "4420013f-bc5e-4d5a-9f94-f4b64ad5107c" }
Does the json object have to be the name of the project, assembly, or namespace?
EDIT: Ah nevermind they are specifying it in the AddOpenIdConnect, where instead I am using the Client Object. -
This is where I build the FusionAuth Client.
public static FusionAuthClient FusionAuth; public static FusionAuthClient Build(IConfiguration configuration) { if (FusionAuth == null) FusionAuth = new FusionAuthClient( apiKey:configuration.GetConnectionString(FusionAuthMgmtServerInfo.ApiKey), host:configuration.GetConnectionString(FusionAuthMgmtServerInfo.FusionauthUrl), tenantId:configuration.GetConnectionString(FusionAuthMgmtServerInfo.TenantId)); return FusionAuth; }
which just are the ""UsersManagement:ApiKey", "UserManagement:Server", "UserManagement:ClientID"
EDIT:
Also in the webportal admin page for the application my "Authorized redirect URLs" is "http://xxx.xxx.xxx.xxx:5000/signin-oidc"(with the xxx being the servers public static ipv4), and "LogoutURL" as "http://xxx.xxx.xxx.xxx:5000"If I look at the application details it shows.
OAuth IdP login URL: http://localhost:9011/oauth2/authorize?client_id=[CLIENTID]&response_type=code&redirect_uri=http%3A%2F%2F[SERVERIpv4]%3A5000%2Fsignin-oidc Logout URL: http://localhost:9011/oauth2/logout?client_id=[CLIENTID] Introspect endpoint: http://localhost:9011/oauth2/introspect Token endpoint: http://localhost:9011/oauth2/token Userinfo endpoint: http://localhost:9011/oauth2/userinfo Device endpoint: http://localhost:9011/oauth2/device_authorize OpenID Connect Discovery:http://localhost:9011/.well-known/openid-configuration/[TENANT_ID] JSON Web Key (JWK) Set: http://localhost:9011/.well-known/jwks.json
with [] being what they should be(excluded by me).
-
Though it looks like I have two applications, a base FusionAuth and then my applications, both using the same localhost:9011. How does it seperate them out? And if I need to change that where do I do that?
-
Any suggestions on how to proceed, or is this a bug I should report?
-
A new update. I can do a get user by email, but if I try to do user login both sync and async it throws a 404 status code. So clearly it is finding the server, maybe it just can't find the login portal?
-
I got it working in a separate console app, so must be something in my app.
-
Yep, I wasn't assigning the values correctly for the service. All fixed!
-
@xan So glad you got it resolved!
Was there documentation that should be clearer or any changes needed on our end to avoid other folks having the issues you encountered?
-
@dan said in Problems logging in user through C# API call:
e
The ultimate help ended up being this
https://github.com/FusionAuth/fusionauth-netcore-client/blob/master/fusionauth-netcore-client-test/fusionauth-netcore-client-test/test/io/fusionauth/FusionAuthClientTest.cs
which went over each functionality which was nice. Otherwise comments of functions on the API would be nice as at points it is a bit unclear. Honestly this was the only problem I have faced so far(and it was just my fault in the end), and it has been an amazing tool. -
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.
-
@xan said in Problems logging in user through C# API call:
when I do "http://localhost:5000", currently it just gets a "localhost refused to connect."?
Generally this happens when the service running on your localhost has some problem resolving the request. If you have access to logs, please see logs for more details on the error. Also, make sure the application interface, server, and services are running. There are many situations that might trigger “this site can't be reached” error in browsers. Sometimes the server is still running but the interface application is closed or the database is down. If your application interface and server is up but a dependent service is down then restart your computer/server and restart services. Make sure the app is bound to localhost. It may just be bound to an individual interface. netstat -na will give you the clues you need. Run a port scan on your computer and make sure the port is opened.
The problem may happens for failing on DNS lookup . DNS is that network address that translates the website name to its internet address. Most often it causes for not getting the internet connection or misconfigured internet or network settings. Another reason could be the firewall preventing Google Chrome to load the webpage. However, other reasons, such as insufficient permissions or the Apache web server not running properly might also cause the error.