Login workflow does not work from mvc app to identity.api

[raimundoteixeira]

i'm experiencing some network weird issues... when I try to make a login, through the docker network 10.0.75.1:5105, the initial process seems to works fine (it doesnt work if forced by "localhost" or the container's name). checking the log, it finds the client id but an exception occurs when it tries to check the returnUrl. An exception is thrown by "AuthorizeRequestValidator".

LOG --------
IdentityServer4.EntityFramework.Stores.ClientStore:Debug: mvc found in database: True
�[41m�[30mfail�[39m�[22m�[49m: IdentityServer4.Validation.AuthorizeRequestValidator[0]
Invalid redirect_uri: http://localhost:5100/signin-oidc
END LOG -----------

It seems like when running into local dev-machine, the MVC app with address localhost:5100 can access the Identity.api by 10.0.75.1:5105 but when it try to proceed checking within AuthorizeRequestValidator it cannot reach the returnURL http://localhost:5100/signin-oidc produced during this process... seems like the container network cannot access this address
I already freed all ports in firewall as well as disabled the firewall...

[mvelosop]

Hi @raimundoteixeira,

Please take a look at this comment: #686 (comment)

You can connect to the containerized SQL Server this way:

Where:

• Server name: localhost,5433
• Login: sa
• Password: Pass@word

BTW, you can also look at the logs in http://localhost:5340

Hope this helps.

[mvelosop]

Closing this issue now, but feel free to comment. Will reopen if needed.

[raimundoteixeira]

Hi @mvelosop thank you for your collaboration. But my problem has nothing to do with database access. It is working fine. As I said before, I cannot access the mvc client url from within the identity.api (when i try to proceed with the login).

In the comment you mentioned (#686) @eiximenis explains how mvc client tries to access the identity.api.
well... when i run export command in the mvc client the identityUrl is http://10.0.75.1:5105 (and this one works fine).
when i type export command in the identity.api the mvc client url is "http://:5100" (and all others clients like WebhooksWebClient = "http://:5114", BasketApiClient = "http://:5103", etc)

and when I execute the command "curl http://localhost:5100" inside Identity.Api it gives me a "CONNECTION REFUSED" response.
despite the comment in .env file (#Local: You need to open your local dev-machine firewall at range 5100-5110.) I did this twice. but it is not working... and it seems like trying to access localhost:5100 inside identity.api it is trying to access its own container (identity.api on port 5100)...

So I really appreciate if you guys could help me to make it works. maybe a docker configuration is missing or something like that...

[raimundoteixeira]

Hi @mvelosop could you please reopen this post? thanks

[mvelosop]

Hi @raimundoteixeira,

The linked comment wasn't really about DB connections, but about the data in the ClientRedirectUris table.

Those addresses are the identity server callback address whitelist for logging in, so that's what blocks the connection depending on the initial URL.

So, as stated in the comment, the solution can be:

1. Connect to Identity DB and update the values or
2. Drop the Identity DB, update appsettings.json and restart Identity.api container.

This would be the records to update:

Hope this helps.

[raimundoteixeira]

Thanks @mvelosop. I've checked that table (ClientRedirectUris) before. My problem is when the Identity.Api Container tries to access http://localhost:5100 it gets a "connection refused" message. My firewall is disabled...

[mvelosop]

Ok @raimundoteixeira, let's try this:

The client urls for identity.api are take from the docker-compose.override.yml lines:

  identity.api:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://0.0.0.0:80
      - SpaClient=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5104
      - XamarinCallback=http://${ESHOP_PROD_EXTERNAL_DNS_NAME_OR_IP}:5105/xamarincallback      #localhost do not work for UWP login, so we have to use "external" IP always
      - ConnectionString=${ESHOP_AZURE_IDENTITY_DB:-Server=sql.data;Database=Microsoft.eShopOnContainers.Service.IdentityDb;User Id=sa;Password=Pass@word} 
      - MvcClient=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5100              #Local: You need to open your local dev-machine firewall at range 5100-5110. 
      - LocationApiClient=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5109
      - MarketingApiClient=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5110
      - BasketApiClient=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5103
      - OrderingApiClient=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5102
      - MobileShoppingAggClient=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5120
      - WebShoppingAggClient=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5121
      - WebhooksApiClient=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5113
      - WebhooksWebClient=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5114
      - UseCustomizationData=True  
      - ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
      - OrchestratorType=${ORCHESTRATOR_TYPE}
    ports:
      - "5105:80"   

and the ESHOP_EXTERNAL_DNS_NAME_OR_IP variable is taken from the .env file, that should have these value:

ESHOP_EXTERNAL_DNS_NAME_OR_IP=localhost

It'd be good to check the logs, if you go to http://10.0.75.1:5340 you should be able to get something like this response from identity.api upon a successful login:

Hope this helps.

[raimundoteixeira]

Hi @mvelosop! thanks I'm gonna try this right now!
could you please tell me what is the output for EXPORT command in Identity.Api console? (I just want to see what is the final env vars running in this container) or "curl http://localhost:5100".
Just because in my dev-env it stills get a connection refused inside Identity.Api containter.

Thanks man.

[mvelosop]

This is the result of env in the identity.api container:

And this is the result for curl http://localhost:5100 (Power Shell's curl):

If you are working within a corporate VPN you might need to run this power shell command (from an admin prompt) every time you power up your machine, to allow access from DockerNAT network:

Get-NetConnectionProfile | Where-Object { $_.InterfaceAlias -match "(DockerNAT)" } | ForEach-Object { Set-NetConnectionProfile -InterfaceIndex $_.InterfaceIndex -NetworkCategory Private }

Hope this gets us closer to the solution 😅

[raimundoteixeira]

Yes it is closer! You clarified many things now.
I only misunderstood if... did you run "curl" inside your identity container (like: "docker exec -it eshoponcontainers_identity.api_1 curl http://localhost:5100") or directly in the host's powershell.
In my case, directly in the host's powershell it works fine (like yours, if it was on host).

But the identity.Api container doesn't access http://localhost:5100 as it should. As you shown in the earlier post (about the log service on port 5340). the Identity.Api checks the returnUrl (callbak from mvc client). but im my case, it gets a "connection refused" (when it tries to check if http://localhost:5100/signin-oidc exists) and doesn't shows the login page.

All the env vars are correct like yours. I can access the client mvc on browser normally. the communication between apis works fine (the communication into docker's network). the only thing that doesn't go is that process when the identity container tries to check something in the host's network.

So... I realized i really have a network issue. something missing in docker setup or whatever... I will look for more details in that network configuration related with my win10pro, firewall, etc... I only installed docker desktop for windows (latest).

thanks man! could you please close this thread. Just tell me if you typed "curl" inside the container or in your host's powershell. I really appreciate your help

[mvelosop]

Hi @raimundoteixeira,

I ran curl from my computer's command prompt, not from the container's.

BTW, that's the way it should be, because that's a "redirect" address. That means it's not really a callback from identity.api to the webmvc microservice.

Let's go through the login process as seen with Fiddler (and use this to document the process later in the wiki 😉):

1. User tries to login into webmvc, but they are not autorized, so it's redirected to check authorization with identity.api:

2. But they're not authorized either (not even uthenticated), so they are redirected, once again, to the login page:

3. So they are shown the login page:

4. When the user logs in, they are redirected to the /connect/authorize/callback (in identity.api):

5. The user is shown an intermediate login page (that you never get to see, unless you don't have JS enabled) that posts the necessary data as hidden inputs to http://localhost:5100/signin-oidc (but this is done from the browser, not from identity.api):

You'd see this if JS were disabled:

6. So after posting the login data, the user finally gets redirected directed, one again, to http://localhost/Account/SignIn (this is the MVC app):

7. Where they are redirected, finally, to the MVC home page:

So it's a pretty complex flow, but, as you can see, the sign in is done from the browser, in steps 5-6.

Just to be 100% sure, I added a SerilogLoggingMiddleware to the request pipeline, and the events correlate perfectly with the above:

Hope this helps.

[raimundoteixeira]

Thanks @mvelosop ! I'm gonna check this out

[FrankDupree]

@mvelosop Thanks for the detailed fiddler workflow, its making more sense now. But i seem to have hit a snag, on visual studio with debugging turned on, I set a break point on the Account/Signin controller, for some strange reasons its not being hit. a look at the ClientRedirectUris table shows the entry is correct. any help please?