The direct copy of the link will not be 302, if the application directly on the website jumps automatically, it will be 302.

the front end uses the vuejs, back end to deploy on the tomcat server using java spring, and the background directory of the request for access to the dist, front end through 8080 is webapp.
now there is a problem: visit a top-up page at the front end. The top-up request is sent through the front-end, and the back-end returns the address of the top-up link. After that, the front-end window.open has a page to top up. When deployed to the online top-up link, 404 appears, but not locally. If you copy the recharge link address directly to the browser and can access it, it will not be 404. Grab the bag and find that the link is 302. The problem with
is that
1.tomcat imposes a restriction, but the interface that is called locally is an online environment.
2. The recharge operator interface is limited, but there will be no problem locally.
the 3.java application is limited, but the front and back ends are separated. I"m just calling the interface, so I shouldn"t jump on my own initiative.
ask for help from the great gods.

Mar.03,2021

is generally 2. As a third-party payment, you need to avoid cross-domain scripting attacks. If you use a third-party service that distinguishes the test environment from the production environment (usually very old systems), localhost is sometimes used as debugging, and front-end redirection is not allowed for this type of service.

now ordinary payment systems no longer distinguish between test and production environments, and development and debugging must be fully authorized in the production environment, for example, localhost also needs to be authorized in your own background.

Menu