PHP Post&使用与HTML表单相同的cURL重定向 [英] PHP Post & Redirect with cURL Same As HTML Form

查看:93
本文介绍了PHP Post&使用与HTML表单相同的cURL重定向的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在HTML中,我们可以创建一个表单并放置输入数据,然后将其作为POST发送到某个目的地;这意味着我们在同一时间发送和重定向,而目的地将两者视为同一事物.我想使用cURL做同样的事情;意味着当我使用cURL来发布数据时,那么我应该能够使用header()之类的东西进行重定向,并且目的地的行为就像是使用HTML表单定期完成该过程一样.

In HTML we can create a form and put input data then send it as POST to some destination; It means we send and redirect in the same time and the destination detect both as a same thing. I want to do same thing using cURL; Means when I use cURL to post data, then I should be able to redirect using something like header() and the destination behaves like the process has been done regularly with an HTML form.

有可能吗?!

推荐答案

我相信您想要做的事情是这样的:

What you want to do, I believe, is something like this:

Client --> Server A

           Server A --> POST --> Server B

Client <------------------------ Server B

例如,客户端可以在不知道服务器A已知密码的情况下登录服务器B.

so that, for example, the client could login to Server B without knowing the password, which is known to Server A.

如果是这样的话,您可以做一些类似的事情,但不能做的完全您想要的事情(尽管可能是类似OpenID的事情) ,并且可以使用OpenID解决.)

If this is so, you can do something similar, but not exactly what you want (which could be something like OpenID, though, and solvable with OpenID).

您可以让服务器A进行POST并接收答案,然后将答案发送给客户端.不幸的是,您可能无法设置cookie(它们将对A子域有效,并且它们将不再发送到服务器B),并且会话可能由于类似原因而无法正常工作.

You can have Server A do the POST and receive the answer, and send the answer to Client. Unfortunately, you probably can't set cookies (they would be valid for A subdomain, and they wouldn't be sent to Server B anymore) and sessions are likely not to work for similar reasons.

可能能够使服务器A充当完整的代理:请参见以下答案

You might be able to have Server A working as a complete proxy: see this answer How can I scrape website content in PHP from a website that requires a cookie login? .

大多数银行都有API可以做到这一点(Paypal,即使它不是银行, WorldPay ).

Most banks have API to do exactly that (Paypal, even it's not a bank, does, and so does WorldPay).

一种可能的工作流程是将所有数据发送到银行,银行以唯一的ID进行响应.然后,当您使用特殊的URL 重定向客户时,您要么自己显示所有信息,要么(银行很喜欢)银行向客户显示信息. ID.

One possible workflow is to send all the data to the bank, which responds with an unique ID. You then either show all the information yourself or (much preferred by the banks) the bank shows the information to the customers, when you redirect them using a special URL and the unique ID.

客户可以更改其表格中的数据-但他获得的全部内容是中止交易,因为两个数据副本不再一致,他无法触摸发送的副本(当然还有其他方法和工作流程).

The customer can change the data in his form -- but all that he obtains is to abort the transaction, for the two data copies no longer agree, and he can't touch the copy you sent (other methods and workflows of course exist).

如果您的系统按照此工作流程(或类似方法)运行,并且使用银行自己的API和建议的做法,请忽略并接受我的道歉:您做对了.但是,以防万一您不舒服,请仔细考虑.

If your system works according to this workflow (or similar) and using the bank's own API and suggested practices, please disregard and accept my apologies: you're doing it right. But just in case you are not, well, please think it over.

尝试使用cURL设计自定义工作流程是可能的(对于某些银行来说,绝对是可能的),但它可疑地接近

Trying to craft a custom workflow with cURL is maybe possible (for some banks it is definitely possible), but it is suspiciously close to rolling your own cryptography, is likely to be less supported by the bank, and might trigger some anomaly detector on the bank's part (just to cite one, lots of payments would appear to come from the same IP address or range).

这篇关于PHP Post&amp;使用与HTML表单相同的cURL重定向的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆