Deploying NiceGUI app in Azure WebApp with Authentication

[Rjdrenth]

Question

Hi everybody,

I've created a nice nicegui app if I say so myself for my company, which I packaged in a docker container and deployed it in an Azure Web App. The app works without problems in this scenario

Only the final formality of adding authentication is left and I just can't get it to work. I am pulling my hairs out, so any help would be greatly appreciated.

The requirement is as follows:

• Add authentication based on Microsoft Entra (formerly MS Active Directory)

Initial idea
Since you can simply add an identity provider to an Azure Web Service that sits in front of your application without having to actually implement any authentication logic in your application yourself, this was my first approach.
When I do this, I am able to authenticate and load the webpage of my application. However, the application is unresponsive because apparently the websocket connection is blocked and not passed through, as the console log of my web browser shows the following error messages:

Firefox can’t establish a connection to the server at wss://<app_name>.azurewebsites.net/_nicegui_ws/socket.io/?client_id=<id>&EIO=4&transport=websocket.
The connection to wss://<app_name>.net/_nicegui_ws/socket.io/?client_id=<id>&EIO=4&transport=websocket was interrupted while the page was loading.

I have no idea how I can get Azure to allow this websocket connection. If anyone does know, please share how.

I did see this thread, however, I have nowhere to configure such headers or am I using a reverse proxy myself. It could be that Azure is using something like this under the hood, but I have no way to modify this. So whether it's relevant or not, I don't know, but I don't think I can do anything about it.

Backup approach
Currently I am working on trying to implement the authentication flow in my own application using examples I found on the internet, e.g. https://github.com/Azure-Samples/ms-identity-docs-code-python and a bunch of others.
However, assuming that this will work, I have no idea whether this will be sufficient in getting traffic over the websocket that nicegui uses in the background.

If anyone has got any insights for me for either approach, that would be greatly appreciated!

[falkoschindler]

Hi @Rjdrenth,

You're probably correct that the websocket connection is blocked.
Unfortunately, we don't have much experience with Azure, but maybe someone from the community can help?
This seems to be mostly a question about how to combine Azure Identity Provider with SocketIO. So maybe StackOverflow with its broader audience is also a good place to ask.

[Rjdrenth]

Thanks for the pointers. Unfortunately they did not yield any results.

I am currently very close to completing the implementation of my backup approach and in fact got a working solution. However, there is one aspect I am not happy about:
To perform the authentication sequence I need to perform a redirect to microsoft so an user can log in. After logging in, microsoft sends the user back to the NiceGUI app. When the user returns, NiceGUI registers it as a new client connection and even as a new browser ID. However, I do need to link the initial connection and the subsequent return to my application.

Currently I link these based on a token something microsoft sends me both initially and on the redirect, but I'd rather do that using the browser ID or client ID.
I can imagine that obtaining a new client ID is to be expected, but I would expect the browser ID to remain the same. Is this reasonable to expect? Or could this be due to the being redirected after visiting Microsoft for logging in?

[rodja]

What do you mean with "browser ID"? We have client.id and client.tab_id. The tab_id is simply a uuid stored in the browsers sessionStorage. If it changes we can not do anything about it. We also have a app.storage.browser['id'] which is stored in a browser session cookie. This should remain the same between browser restarts and hence should also allow you to identify the user coming back from a Microsoft authentication page.

[Rjdrenth]

I indeed meant app.storage.browser['id']. I figured out the cause of my observation of a changing browser id:

• When you start a nicegui app with show=True, it opens up http://127.0.0.1:8080
• It reports NiceGUI ready to go on http://localhost:8080, ......, so localhost is first, which is what I tend to click if I were to click one of those links.
• Finally, I had to do my redirects to http://localhost:8080/ rather than 127.0.0.1
• Personally, I was not aware that changing 127.0.0.1 to localhost or another local-pointing IP address would result in different values for app.storage.browser['id'] - I just assumed that connecting to my local app from the same browser would result in the same value for app.storage.browser['id'].
• This also caused getting another value for app.storage.browser['id'] after coming back from the Microsoft authentication page.

In any case, thank you for your answer. It prompted me to do further investigation and figure this stuff out.

Is this personal discovery common knowledge and was I just simply oblivious due to a lack of web programming / networking knowledge? Or could I have read it in the documentation somewhere? If not, I'd be happy to add some notes to the documentation.

[Rjdrenth]

I wrapped up my authentication journey with Entra and made a minimal example. and produced a Show and Tell discussion