Skip to content
This repository has been archived by the owner on Nov 17, 2023. It is now read-only.

SPA web app is not managing images and login properly when running from remote browser #112

Closed
CESARDELATORRE opened this issue Mar 10, 2017 · 3 comments

Comments

@CESARDELATORRE
Copy link
Collaborator

CESARDELATORRE commented Mar 10, 2017

When deploying the "prod" environment (using docker-compose.prod.yml with external IPs that you need to change depending on your host machine), the MVC app works OK from a remote browser.

However, the SPA app is not showing the catalog images neither being able to authenticate agains the STS container (IdentityServer4).
An URL like this show no images:
spa-bug-images-remote

However, if running the same deployment but using the URL http://localhost:5104/catalog then the images show up properly, but the authetication page show an error:
Sorry, there was an error : unauthorized_client
Request Id: 0HL37FHCF72NO

@eiximenis
Copy link
Contributor

Ok. Both issues (images & login) solved in commit 12ecc78

Important: Currently SPA nor our IdentityServer configuration supports running SPA from two different origins.
So, when running deployed "prod" environment it CAN'T ONLY BE ACCESSED THROUGH EXTERNAL IP. Using localhost for accessing prod environment will generate issues and it is not supported.

Reason of this is because our current configuration for IdentityServer only allows one supported redirect url for a specific client (the redirect url is the uri where identity server will redirect the user after a successful login. It is set by the client and checked by IdentityServer. Note that IdentityServer supports multiple redirect urls per client, it is just our current configuration that do not).
In the "prod" environment the redirect url of SPA client is set to external IP. When SPA performs login the URL that passes to IdentityServer is the browser origin. So the browser origin must be the same as the external IP, meaning in that only login from external IPs are supported.
@CESARDELATORRE if you want, you can open a new issue to support "multiple redirect urls" on identity server and I'll take a look with lower priority ;-)

Another change I did is to use a environment variable in the docker-compose.prod.yml file to set the external IP. So, there is no need to edit this file to put your correct IP in it.
Now, you must set the ESHOP_EXTERNAL_IP environment variable to your external IP. Then you can run docker-compose.
There is no check to ensure the variable is set, but if it is not it won't work. @CESARDELATORRE please, ensure that this is well documented (i put a comment in the file).

@CESARDELATORRE
Copy link
Collaborator Author

CESARDELATORRE commented Mar 11, 2017

I'm not sure I like to use an environment variable (for the the external IP) at the server level used in the docker-compose.prod.yml file to set ALL of the microservices...
I might be the right solution as in a Docker Host and even in a cluster, that external IP or DNS name is shared across all the cluster...
But I'm not sure if that config should be shared across multiple/different microservices that should have independent configuration.. Could be ok as the external DNS name or external IP might me always the same for all the containers within the same app and cluster if using an orchestrator...

Basically, do you think there is any possibility that any of the microservices could use a different external IP or DNS name within the same deployment in a hypothetical orchestrator/cluster like Docker Swarm? probably not..., then using this ENV-VAR per deployment environment would be right.

Probably, this is right. For having a different external IP or DNS name you'd need a different deployment environment in which case you could also specify a different external IP or DNS name for that different deployment, as well.
Just wanted to confirm this.
Thoughts?

(Also, we shouldn't explicitly say just "IP", as it could also be a DNS "server name" if deployed in production, but that is a minor detail)

@CESARDELATORRE
Copy link
Collaborator Author

CESARDELATORRE commented Mar 11, 2017

Confirmed from y side. I think the env-var approach is right for the external IP or DNS NAME across all the microservices under the same docker-compose deployment as they will share the external Docker Host IP or DNS Name or even if it were a cluster or Docker Swarm, the external DNS name would also be the same.

I even went further so in order not to make complex setup instructions with multiple ways to set an environment variable depending on your deplpyment environment (Windows, Mac, Linux, Cluster/Swarm, etc.) I'm using the ".env" file to set the by-default env-vars.
So, the ESHOP_EXTERNAL_DNS_NAME_OR_IP environment variable is taken, by default, from the ".env" file placed at the root folder, which defines it like ESHOP_EXTERNAL_DNS_NAME_OR_IP=192.168.88.248
But, values present in the environment vars at runtime will always override those defined inside the .env file.
This is the commit with this improvement:
71987d0

As a reminder, this deployment configuration using the docker-compose.prod.yml file has to be used when testing the Web apps and the Xamarin apps from remote machines/devices using the same WiFi, for instance. Like remote browsers and remote devices.

Closing this ISSUE for now, as I tested it and it is working successfully in my tests.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants