InfoPath Dev

SSIA :)

I have a site with 2 very similar XML libraries, one of which has at least 1 Query data connection; the other library is the one used for the SharePoint Library Submit DC, but when I try to create a Query DC for it, it cannot get its list of columns ("Encountered an error when retrieving columns: Failed to fetch"). It seems be running afoul of CORS:

Access to fetch at 'https://login.microsoftonline.com/3456fe92-cbd1-406d-b5a3-5364bec0a833/oauth2/v2.0/authorize?...' (redirected from 'https://formsv.nycourts.gov/WebProxy/GetColumnsByListId?...')
     from origin 'https://formsv.nycourts.gov' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
middleware.js:18  GET https://login.microsoftonline.com/3456fe92-cbd1-406d-b5a3-5364bec0a833/oauth2/v2.0/authorize?...  net::ERR_FAILED 200 (OK)

What can I do to query this library?

Hi Scott,

Sorry for the delay. Short version: the CORS error is a symptom, not the problem. The real signal is that our WebProxy handed your browser a redirect to the Entra sign in page, and a fetch() call cannot follow that across origins, so Chrome reports it as a CORS failure with that odd "ERR_FAILED 200 (OK)". Nothing is misconfigured about CORS, and there is nothing to fix at login.microsoftonline.com.

One thing worth stating clearly: SharePoint Online does not redirect REST calls to the authorize endpoint. If the account simply lacked rights on that library, the call would come back as a clean 401 or 403. A redirect to /authorize means FormsViewer could not silently obtain a token for that call and tried to start an interactive sign in. So this is token acquisition, most likely one of:

• The two libraries are not actually in the same site collection, and the token we hold is scoped to the other one.
• The token or session expired between your two attempts.
• A Conditional Access policy or a pending consent applies to that site and forces interactive re-auth.

Three things would let us pin this down quickly:

1. The full, unredacted authorize URL from the console. The query string usually names the cause directly. Look for error, error_description, prompt, client_id, and scope or resource. Scrub anything you consider sensitive, but the parameter names matter.
2. The two GetColumnsByListId request URLs side by side, the working library and the failing one, so we can compare the web URL and list ID parameters.
3. The FormsViewer server log entries from that moment, so we can see what SharePoint actually returned before we issued the redirect.

A quick test that splits the problem in half. Signed in as the same user, browse to:

{site}/_api/web/lists(guid'{list id}')/fields?$select=InternalName,Title

If that returns data, the library permissions are fine and this is our token handling. If it returns 403, it is a permissions issue after all and we look at that library's unique permissions.

Also worth one minute: sign out and back in, then configure the failing library first, before touching the other one. If it works, it was a stale token.

On a workaround, you can copy the working Query data connection and repoint it at the other library's list ID and URL, which bypasses the Designer's column picker. Two cautions. The internal column names have to match exactly or the form binds to nodes that do not exist and fails at runtime, and if the runtime query goes through the same WebProxy path it may hit the same auth problem on form load. Test it end to end rather than in preview.

What FormsViewer version are you running? We have made a number of changes recently and I want to be sure we test against your build.