Solving CORS Issues When Integrating React Frontend with Java Backend
Integrating a React front‑end with a Java back‑end required fixing HTTPS‑to‑HTTP CORS errors by serving the React index.html from the backend, switching @RestController to @Controller for sub‑path routing, adding Thymeleaf, using a Chrome redirect plugin and crossorigin tags, and disabling lazy‑loaded asset URLs during local development, highlighting that true front‑end/back‑end separation remains elusive.
Background: First React project, local dev with npm start, calling backend via host 127.0.0.1 local-fishci2.alibaba.net solved local CORS.
After deploying frontend via def (HTTPS) and backend daily (HTTP), protocol mismatch caused CORS.
Pitfall 1: “This request has been blocked: the content must be served over HTTPS.” Fixed by copying React index.html to backend template and adding a controller to forward to it.
Pitfall 2: Redirect returned a string instead of page. Solved by adding Thymeleaf template dependency.
Pitfall 3: Wanting to use sub‑path /fyapp/ led to same string issue because of @RestController ; changing it to @Controller resolved the problem.
BUC integration introduced HTTPS→HTTP downgrade CORS. Temporary fixes: (1) server‑side domain check to serve local or CDN resources; (2) Chrome plugin Switcheroo Redirector for host mapping; also require crossorigin attribute on resource tags in index.html.
Remaining issue: React lazy‑load generates dynamic assets (e.g., 8.css , 8.js ) pointing to the server domain, inaccessible locally. Work‑around: keep a backup routing file, disable lazy load for local dev, revert for deployment.
Conclusion: True front‑end/backend separation is lacking; CORS problems appear in many forms.
Xianyu Technology
Official account of the Xianyu technology team
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.