Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems with Microsoft Auth #199

Closed
aryankhandal0 opened this issue Sep 23, 2020 · 4 comments
Closed

Problems with Microsoft Auth #199

aryankhandal0 opened this issue Sep 23, 2020 · 4 comments

Comments

@aryankhandal0
Copy link
Contributor

aryankhandal0 commented Sep 23, 2020

This is a very specific bug but may solve some people's problems.
There are multiple possibilities to see through this problem related to redirect_uri.

Running para and scoold as two azure container instances in same virtual network while using application gateway to route through them.

Capturen

The scoold-application.conf file will contain this config.

# the public-facing URL where Scoold is hosted
para.host_url = "http://11.0.2.5:8000"
# the URL of Para - can also be "https://paraio.com"
para.endpoint = "http://11.0.2.4:8080"

We can only whitelist http://localhost:8080 or https:// in microsoft redirect_uri, Link to docs. So we cannot whitelist http://11.0.2.4:8080.

Now we are left with another option that we change para.endpoint to the application gateway front facing dns, which defeats the purpose of virtual network but let's try.

para.endpoint = "https://frontenddns:443"
So, Scoold will now try to connect with para over the internet and make the whole setup slow and this will not work with self signed certificates.

The solution may be is to give options both for para.endpoint and para.redirect_uri so that para.endpoint can be saved as 11.0.2.4 and scoold will be able to connect with it, while the redirect_uri be set to the frontend https dns.

I have encountered multiple scenarios where this would be helpful if you need more details, I could write those scenarios as well, I have deployed para+scoold on nginx, nginx + ssl, azure container instances + nginx, azure container instance + application gateway.

@albogdano
Copy link
Member

albogdano commented Sep 23, 2020

I understand what you mean but if the public frontend uses a self-signed certificate wouldn't the users see a broken HTTPS icon in their browsers as well? The only place where redirect_uri is set to be the value of para.endpoint is in the signin.js script which initiates the auth request to Microsoft. It would be helpful if you could go to the /signin page and change the value of ENDPOINT variable by opening your browser dev console and typing ENDPOINT = "https://frontenddns:443":

image

After you do that, hit "Enter" and click the "Continue with Microsoft" button and see what happens.

@aryankhandal0
Copy link
Contributor Author

Even if we leave the certificate part, and define

# the public-facing URL where Scoold is hosted
para.host_url = "https://frontenddns:443"
# the URL of Para - can also be "https://paraio.com"
para.endpoint = "https://frontenddns:444"

This defeats the purpose of me having the scoold and para in the same vnet that is not make the site faster.

The solution you have provided works, can we have that as parameter in scoold-application.conf as it would be useful, if possible.

I have encountered this problem many times on my local deployment as well, and a para.redirect_uri will solve it.

This is all caused by microsoft not allowing people to whitelist http ip's or dns.

Thank you for the help.

@albogdano
Copy link
Member

I added the option para.security.redirect_uri which by default equals the value of para.endpoint but you can change it to be your frontend URL.

@aryankhandal0
Copy link
Contributor Author

Thank you for this. Very Helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants