Cannot connect to server that is published externally via azure application proxy

I’'ve got specific issue without any description when I use Jetbrains Rider plugin:
With login/pass:

With token:

I use server URL that goes through azure active directory and when I’m not logged in → before it went to https://sonarqube.<rest-of-url> it will redirect me to: <>.

Do you support such URLs? It was made for security purposes to prevent any code leaks and I can’t change such setting on azure.

In Rider there is already supported such behavior within Nuget section. When we add new feed from azure devops before it’s added it redirect us to a web browser to authenticate.

More information about it:

Bump for visibility!

Hello, thank you for your question!

To make sure that I fully understand your use case:

  • Your SonarQube server is hosted behind an authenticating reverse proxy that is linked to your Azure AD
  • Authentication to this reverse proxy is transparent in the browser (Windows SSO)

If this is the case, I will probably move your thread to the New features category and create a ticket - I am pretty sure that such a use case is not supported at all currently.

So it will take forever ;_;.
Graph to visualize my situation:

Sequence diagram for better understanding:

    title: Get homepage of SonarQube management
    participant local machine (IDE)
    participant Azure (app proxy)
    participant On premise Server
    participant Azure
    note over Azure (app proxy): External URL
    note over On premise Server: Internal URL
    local machine (IDE)->>Azure (app proxy):HTTP GET `/`
    Azure (app proxy)->>Azure (app proxy): Check if request is logged into Azure.
    Azure (app proxy)->>local machine (IDE): 401 UNAUTHORIZED<br/>Redirect to login page.
    local machine (IDE)->>Azure: Login
    Azure->>local machine (IDE): 200 OK<br/>Redirect to app proxy page
    local machine (IDE)-->>Azure (app proxy):HTTP GET '/'
    Azure (app proxy)->>On premise Server: HTTP GET '/'
    On premise Server->>Azure (app proxy): 401 UNAUTHORIZED
    Azure (app proxy)->>local machine (IDE): 401 UNAUTHORIZED
    local machine (IDE)->>Azure (app proxy): Login<br/>Login to sonarqube server
    Azure (app proxy)->>On premise Server: Login
    On premise Server->>Azure (app proxy): 200 OK<br/>Redirect to projects page
    Azure (app proxy)->>local machine (IDE): 200 OK<br/>Redirect to projects page
    local machine (IDE)-->>Azure (app proxy):HTTP GET '/'
    Azure (app proxy)-->>On premise Server:HTTP GET '/'
    On premise Server->>Azure (app proxy): 200 OK
    Azure (app proxy)->>local machine (IDE): 200 OK

I’m not sure what you mean by “it will take forever”.

Yes, we are a product company and we have a roadmap. We don’t “stop the world” as soon as an issue is reported, or a missing feature asked for. We don’t have an infinite bandwidth either.

When someone reports an issue, we prioritize the fix depending on the severity and number of impacted people. Moving the thread to the “New features” section is one way to do this: other users will be able to vote for it and increase its priority on our backlog.

I’m sorry that you are the first person to report this use case, and I understand that it might be frustrating that we don’t fix it immediately. This being said, we do have backlog reviews in place, and a ticket is precisely the guarantee that we keep it in mind and that it does not “take forever”.

I didn’t want to offend you, I’m sorry.
From what I saw your new features section depends on votes and this system encoragues to firstly fix issues that are popular. It means that for rare cases or something like mine - that happened because of security policies - won’t get so much priority. Even though I want to integrate that in our company I have to wait for that solution.

Thank you for response and move to better section.

Like I said, votes on the community forum are just one parameter of the priority function. Another one is input we get from paying customers, through our support team. And the inherent severity of the issue - for instance, that there is absolutely no workaround, like the use case you reported - is another one.

For instance, the 2 top-voted features for SonarLint are C# and C++ in VSCode, and they have been there for a while; we do feel the pressure to tackle them, but none of them have become an absolute priority for us yet :slight_smile:

For the record, I linked to this thread in SLI-640. Thanks for the links to the documentation and expected sequence diagram, I believe both will help when we tackle this issue.

FWIW we would also like to see some support for Azure App Proxy but I don’t think it’s well understood by anyone who does live in that world.