Update: Microsoft will be moving away from UserVoice sites on a product-by-product basis throughout the 2021 calendar year. We will leverage 1st party solutions for customer feedback. Learn more here.

Frechette, Pierre

My feedback

  1. 194 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    22 comments  ·  Azure Active Directory » Application Proxy  ·  Flag idea as inappropriate…  ·  Admin →

    We are looking at enabling a feature that focuses on supporting CORS preflight requests between two applications. This works by allowing you to configure the response and have App Proxy handle it on behalf of the app.

    A pre-requisite for this feature to work is that the user must be able to authenticate into the second application in order to avoid a CORS issue from the login flow into the second app.
    To avoid this the user will have to make sure they have already accessed the 2nd application before the CORS request, and has valid credentials. This should work for wildcard apps and can also be achieved by adding a fake link / image to the 2nd application in the first application.

    We would love to get your feedback on this requirement and if this is something that will fit your use case.

    An error occurred while saving the comment
    Frechette, Pierre commented  · 

    For now, in the case of our SPfx webpart, we're redirecting the users to a redirect page on the proxy. We inform them we first need to "authenticate their request". This redirect page will simply redirect the user back to the page with the SPfx webpart. This way, the proxy authentication process takes place and subsequent XmlHttpRequests have the necessay authentication cookies for the proxy. Not ideal, but it works.

    An error occurred while saving the comment
    Frechette, Pierre commented  · 

    Same as everyone lately on this thread. Total blocker to expose on-prem services via proxies that require CORS. The redirects to and from login.microsoftonline.com or device.login.microsoftonline.com seem to be breaking the flow. We have an SPfx webpart on sharepoint.com trying to do XmlHttpRequests to a proxy, but the whole thing fails because of this.

    Interested in understanding the statement "This should work for wildcard apps and can also be achieved by adding a fake link / image to the 2nd application in the first application". Our testing as shown that navigating to the proxy in a different browser tab to obtain the required 'AzureAppProxy*' cookies prevents the redirects to login.microsoftonline.com; subsequently refreshing our page with the SPfx webpart then works. I understand the issue is complex since it requires checks to the AAD app as well as potential Conditional Access checks. Multiple redirects seem to be involved with user authentication and can't seem to play well with XmlHttpRequests. Help is very much appreciated. Re-writing the app to leverage Azure API Management or some other kind of data access is not in the cards in the short term.

    Frechette, Pierre supported this idea  · 

Feedback and Knowledge Base