Closed jtlapp closed 8 years ago
A less ideal solution would be for the proxy to use the SpreadShirt API to check basket item IDs looking for one that is in a valid shop. For efficiency, it need only check one item. If this is even possible.
Duh. Never mind! The whole reason for the proxy is that the script must hit its server of origin, so other stores could never use other people's proxies. I'll close this issue. Sorry! (Still wrapping my head around this.)
As things stand, anyone can use anyone else's proxy server for any shop. This may not be much of a problem in practice, but if ever abuse does occur, we're going to need a way to put it to a stop.
The best solution I can imagine is the client providing the proxy with a shop ID, the proxy verifying that the shop ID is allowed, and then the SpreadShirt API verifying that the basket ID or basket item ID is associated with a provided shop ID.
Each of these pieces would be necessary. It's not sufficient for the proxy to verify the shop ID, because that's readily spoofed. It's also not sufficient for SpreadShirt to verify that the basket or basket item is associated with the provided shop ID, because that does not constrain use of the proxy.
At present, the DELETE call is not providing a shop ID for the SpreadShirt API to verify. Is there a way to do that -- to provide a shop ID with the DELETE call and have the API verify it?
To handle the case where a person is willing to host the shopping cart of multiple stores, the proxy might check for the shop ID in a list of acceptable shop IDs.
Also, I'm now convinced that shopping cart updates must be done via a proxy server. That's one more reason for SpreadShirt itself to provide a universal shopping cart, because now there is a requirement that users run a dynamic server instead of just a static web site. PHP may be common, but it is also common for PHP to be slow on shared virtual hosts. With a third-party shopping cart, proper functioning of the store is dependent on the proper functioning of two dynamic servers.