3

Our SharePoint 2016 on-premise farm have setup Internet access. Our reverse proxy have setup URL rewrite from 'https://www.mysharepoint.com' (Internet URL) to https://server_wfe1/ (our web front end server).

Most functions are working fine beside the search page. When browse with IE nothing wrong. But browse with Chrome or Firefox return:

Unexpected response from server. The status code of response is '403'. The status text of response is 'Forbidden'.

After checking ULS log, the problem is:

Request is a Cross-Origin request. Origin is : 'https://www.mysharepoint.com'. Host is : https://server_wfe1/_vti_bin/client.svc/ProcessQuery

How can we configure SharePoint to work around it?

Improve this question

2 Answers 2

Reset to default
1

You have to configure Alternate Access Mapping to support https://www.mysharepoint.com to map to https://server_wfe_1. If you don't do this SharePoint will not correctly map the incoming URL to a query and then write the outbound URL correctly. SharePoint search matches the inbound request to the AAM Zone and then determines how to return the result URLs via AAM. Failing to have the AAM results in mapping to the default zone.

Improve this answer
7
  • Hi Matthew, we have setup AAM extranet zone with incomingurl=server_wfe_1, publicurl=sharepoint.com already.
    – Mark L
    Commented Jul 14, 2019 at 1:04
  • But we have multiple entries in extranet zone. Is it a issue?
    – Mark L
    Commented Jul 14, 2019 at 1:05
  • As long as AAM is correct and you are crawling only the default zone it should all work perfectly. (It has been this way for 10 years.) If one or the other is wrong you will experience all kinds of issues like this.
    – Matthew McDermott
    Commented Jul 15, 2019 at 12:04
  • My search is working perfectly via Intranet (no url rewrite) . The only problem is access from Internet got cross-origin error. Later I found this error not only shows in search page
    – Mark L
    Commented Jul 15, 2019 at 12:08
  • That's what I am saying. The problem you are seeing is caused by having the AAM's or crawl config wrong. Telling me that it works in one zone and not in another is the exact issue you will see. Recheck your AAMs and be sure your content sources are using the default zone.
    – Matthew McDermott
    Commented Jul 16, 2019 at 15:33
0

I am not sure it is the right fix because I cannot find any official document or blogger talked about this setup. (Please advise me if any) Also please check out Matthew's answer too. It is not my case but it could be yours.

Here is my fix/workaround:

  1. Since our reverse proxy have setup URL rewrite from 'https://www.mysharepoint.com' (Internet URL) to https://server_wfe1/, we have to avoid the rewrite which lead to CORS error.
  2. Add a new record in the HOST file of reverse proxy server, to point www.sharepoint.com to WFE's ip address.
  3. Change the existing rewrite rule, to make the rule rewrite from 'https://www.mysharepoint.com' to 'https://www.mysharepoint.com' (yes, no change).

The above setup make my search page as well as other CORS related function works. No more CORS error now.

I have tried disable the rewrite rule (since there is no point to rewrite now) it makes every page unable to be browsed. IT looks like the reverse proxy server do not forward request any more. Therefore I keep the rewrite rule until I found the right way.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.