Home  >  Q&A  >  body text

java - How to solve the problem of cross-domain redirection carrying parameters? Do not use the method of splicing parameters at the end of the redirect url

How to solve the problem of cross-domain redirection carrying parameters? Do not use the method of splicing parameters at the end of the redirect url

Requirements, project A is on server A, needs to be redirected to project B on server B, and parameters need to be carried. The parameters are not visible to the user, so the parameters cannot be spliced ​​behind the redirect url. Do you have other solutions? ?

Project uses spring

RedirectAttributes.addFlashAttribute is not possible, it can only redirect between controls within the same project.

This problem has not been solved, please give me a reply.

Supplementary questions:
(1) Downstairs answer
You can put the data in the header of the request, but the other party's server needs to set the allow request header custom field

How to understand this? How to achieve?

The browser requests server A (not an ajax request), and server A returns a 302 response and a redirect url to redirect the client. At this time, server A can place the parameters that need to be passed into the response header, and then the browser The target url is redirected, but the previous redirect response header information will not be carried at this time

How can we let him carry it there?

(2) Question 2: The server returns a 302 redirect response. Can this response contain a response body message? ? ?

Because I am testing using response to write data, but the browser cannot see the redirection response data. How is this controlled in implementation? Do all redirect responses not contain a response body?

伊谢尔伦伊谢尔伦2702 days ago1856

reply all(8)I'll reply

  • PHP中文网

    PHP中文网2017-05-27 17:43:37

    You can put the data in the header of the request, but the other server needs to set the permission to customize the request header field

    reply
    0
  • 巴扎黑

    巴扎黑2017-05-27 17:43:37

    1. Server A sends parameters to B and waits for B to respond

    2. B gets the parameters and saves them, and responds with a token to A. A carries this token and redirects to B

    3. B receives the redirection from A and obtains the parameters saved in step 1 based on the token

    reply
    0
  • PHP中文网

    PHP中文网2017-05-27 17:43:37

    Create a <form method="POST">,把参数填以<input type="hidden" ...>的形式填到<form>里,再用JavaScript触发submit() and these parameters will be brought to the target site invisibly in the address bar.

    reply
    0
  • 仅有的幸福

    仅有的幸福2017-05-27 17:43:37

    Thank you for the invitation. If you control both services yourself, it is enough to encrypt the parameter content. You can refer to how http session is encrypted and decrypted and there are relevant security standards.

    reply
    0
  • 曾经蜡笔没有小新

    曾经蜡笔没有小新2017-05-27 17:43:37

    Why don’t you try to solve this problem from the front-end perspective? Just send an ajax request through the front end, and then use jsonp to solve the problem of cross-domain parameter transmission

    reply
    0
  • 漂亮男人

    漂亮男人2017-05-27 17:43:37

    Or create a middle-tier service, so that when users request the middle-tier service, they cannot see the specific parameters, and this also controls cross-domain issues

    reply
    0
  • 仅有的幸福

    仅有的幸福2017-05-27 17:43:37

    Write the data and the address of server B to the browser's ajax. After ajax gets the address, it posts the data to server B.

    reply
    0
  • phpcn_u1582

    phpcn_u15822017-05-27 17:43:37

    1. If these two servers are controllable by you, you can use cookies to bring them across domains. Note that only through cookie cross-domain 302 redirection can you access server B with cookie request headers and other custom request headers. The browser will not take it.
    2. The http protocol does not stipulate that the response body cannot be included in the 302 response. Maybe the browser automatically ignores it?
    3. You can use 307, so that your post request will be posted to the new uri. See rfc2616-307 for details

    reply
    0
  • Cancelreply