If your going to give out a PUT tempurl then your trusting someone to put stuff. But I guess there are different levels of _trust_.
I see that DLO's are an issue in this case, (someone could attempt to probe the account) and so if we go with blocking a PUT request from the tempurl middleware when X-Object-Manifiest headers exists will stop that. Noting we want a tempurl GET to support DLO as that is a valid use case.
If we are going to filter on X-Object-Manifest in tempurl PUT, do we need to think about x-versions-location as well (which I guess isn't a problem until someone has PUT and DELETE tempurls)... However, will this start making TempURL middleware more coupled with others? I guess if we can find a good way to limit the scope tempurl's have access to will solve this.
If your going to give out a PUT tempurl then your trusting someone to put stuff. But I guess there are different levels of _trust_.
I see that DLO's are an issue in this case, (someone could attempt to probe the account) and so if we go with blocking a PUT request from the tempurl middleware when X-Object-Manifiest headers exists will stop that. Noting we want a tempurl GET to support DLO as that is a valid use case.
If we are going to filter on X-Object-Manifest in tempurl PUT, do we need to think about x-versions-location as well (which I guess isn't a problem until someone has PUT and DELETE tempurls)... However, will this start making TempURL middleware more coupled with others? I guess if we can find a good way to limit the scope tempurl's have access to will solve this.