Does the company say why this is so? Maybe the second request delivers the data with some embedded signature/MAC to let the user acknowledge the data for further processing?

@Marcel they could still serve this in the response to the first request already. Or at least use an identifier, so that the app can have certainty, that they are requesting the correct data (idempotency).

How is the get request not idempotent? (This is probably obvious, but I have not had coffee yet.) I agree that the whole design is weird...

I also see the GET as idempotent. Based on your description it gives the same result if retried, i.e. it does not change some state at the server. Given that your question is based on the assumption that the GET request is not idempotent, I think you need to explain in more detail (by editing your question) why do you think this is the case.

@SteffenUllrich What you described is a 'safe' http method (safe = not changing server state). Idempotent means that it always gives the same result. If the first POST request gets resubmitted with different data inbetween, the GET request would give different results. That means it is not idempotent.

@Anders It's not idempotent, because it gives a different result, if the user sent the first POST request with different data inbetween.

I just looked up "idempotent", and it seems the only thing that matters is the effect on the server. So your request is actually idempotent. What your request does is to just return a different result, which is completely normal everywhere on the web (the content of pages can change constantly over time). I see no security problems at all with this.

@reed I disagree. "From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result." Which is not the case here. It's true that the response is not changing just as a result of the request itself. But an idempotent version of this would return an ID in the first request, and the GET request would then subsequently request the data with GET /filledoutform.php?id=[value]. Otherwise it's not idempotent.

@MartinFürholz, but your GET request actually has always the same effect, on its own, which is what makes it idempotent. Of course if between two idempotent GET requests you make a POST request, then the second GET request is going to return different data. But it's not GET's fault, which is idempotent. It's POST's fault, which is not idempotent.

@reed From my understanding the resource that the GET is requesting should be distinct and unambiguous. That's why we request data using parameters. E.g. GET /pre-filled-form.php?id=1234. This design is weird and I still think this is going against the definition of idempotent HTTP requests. You are (all!) mixing up 'safe' and 'idempotent'. Safe = do not change resources. Idempotent = returns always the same resource.

@MartinFürholz, I'm sorry, I just think that we have different definitions of "idempotent", so we can't find an agreement. All I can say is that I think my definition is correct, also according to several resources I found online (you can find some by googling "idempotent GET" for example). I know the difference between "safe" and "idempotent": safe requests must not change the status on the server at all, while idempotent requests can change the status, but subsequent identical requests must have no effect (N idempotent requests M in a row = 1 idempotent request M)

There are many ways to make a request distinct and unambiguous. A URL parameter is only one of them. And along with everyone else, I have to point out that you misunderstand the meaning of "idempotent" which renders the question baseless.

Yes, I'm fully aware of the RFC 2616 definition, and that's not the problem. The problem is that you're trying to apply it to something that does not meet that definition, so your question doesn't make any sense.

"what you are saying is that GET url.com/image001.jpg is NOT supposed to return image001.jpg everytime you call it, but it's perfectly fine if it sometimes returns image999.jpg's representation, or image444.jpg's representation." I can't see the image, but what I'm saying is there's nothing in your post to indicate that it doesn't.

And specifically, this "It's not idempotent, because it gives a different result, if the user sent the first POST request with different data inbetween." is where you go wrong. The POST is separate request, and has nothing to do with the GET, and if they're using something in the session to determine what comes back in the GET (which it appears they are) that's perfectly fine.

Any further comments, please post them in the chat. This question is on hold as it doesn't currently seem to be on topic (the basic premise seems to lack detail, and it appears to fall into our "demonstrate understanding of the concepts" close reason)

@RoryAlsop How does that fall into that close reason? This is clearly an example, not an actual system, and the question is about whether or not it is bad practice to make a GET request without specifying the exact resource to be requested, when it can clearly change. How more clearly can I explain that?

I agree with @RoryAlsop. The edits don't change that the question is premised on a misunderstanding how HTTP and this application work. Without that misunderstanding, there is no question.

I responded in chat

Martin - we have a "be nice" rule here. Failing to adhere to it results in suspensions.

← 95 messages moved from Discussion between mentallurg and Martin Fürholz

@RoryAlsop Yes I understand that. But "be nice" also includes answering, and not ignoring, my questions. I find it rude that my question gets closed with a questionable reason. As I said before, I'd completely rephrased my question already, after the first 2 or 3 'close' votes of the question. I bet this hasn't been considered before closing it.

"How does that fall into that close reason? This is clearly an example, not an actual system, and the question is about whether or not it is bad practice to make a GET request without specifying the exact resource to be requested, when it can clearly change. How more clearly can I explain that?"

@MartinFürholz You did get answers. In a round-about way, the answers all said the same thing which more succinctly is that generally "No, it isn't a bad practice and no, there generally aren't security implications."

No that's simply not true. @Xander You yourself said "then that is the potential threat" yesterday.

And literally nobody wrote "no, it isn't a bad practice".

(also not in that sense, with a different wording)

@MartinFürholz So, you don't want a answer, you want confirmation of the position that you've already formed.

quote: " we have a "be nice" rule here. Failing to adhere to it results in suspensions."

Everything you just wrote doesn't even remotely touch what I wrote to RoryAlsop.

@MartinFürholz "But "be nice" also includes answering, and not ignoring, my questions."

Kinder

I brought a couple of examples (of security-related issues with this design). And accusing me of "missing understanding of the concepts involved" is ridiculous. This was a great negative example of what this particular community is capable of @Xander

The whole 'closing' reason in this particular case is a joke, in my opinion.

And my question whether you need a diagram or graph or visualization to understand my original question was legit.

@MartinFürholz I'm sorry, I don't know how to say it any more plainly. There are no general security concerns for the system you described. That doesn't mean that there are no security concerns present, just that nothing you described is in and of itself alarming.

@MartinFürholz Look, the only reasons I visit this site are to learn, and to help other people. I have no vested interest in being right, or proving you wrong. I'm only trying to help you understand what I see about the system you've described. If you don't find my input helpful, then just let me know and I'll bow out.

@MartinFürholz We have a few "canned" close reasons, and as I pointed out in my comment when I closed it, it falls into a couple of them. Yes, I read your edits, and the core of the question is a misunderstanding of the technology. Your assumption is just wrong. As many have pointed out to you. There is no security issue here.

Closing a post is not rude, and you got answers - from folks way smarter than me. If you do think it is rude, then maybe you should review how Stack Exchange works. Upvotes, downvotes, close votes - none are rude, they are the way the entire network of sites works

@RoryAlsop Can you explain what part of the technology I misunderstood? This is a pretty bold statement. Which assumption is wrong?

Do you want me to explain it to you again?

Making bold accusations and statements without any explanation or reasoning to me falls under the "be nice" rule.

Do you agree?

My issue with this design - which those who understood it agreed with - is that it doesn't make sure that it requests the exact representation (in this case payment slip) that the user expects to see. I even listed a few examples how this could be exploited. Did you see that? Do you understand that, so far?

Are you following?

@MartinFürholz Yes, I'm very much following. The problem is that the system you've described is generically, an application that interacts with an API. It creates/updates data with POST and PUT requests, and retrieves data with GET requests. This is how all APIs work. You've then speculated that there might be a security concern, but provided no additional data to lead us to believe that there is any more reason for that to exist here than in any other RESTful API.

The lack of a querystring parameter on the GET request is neither a vulnerability in and of itself, nor would it be a mitigation if there is a vulnerability in the system.

@MartinFürholz what Xander said. Especially that last sentence ^

I do apologise for the brevity of my comments - I'm responding as I pop between things in the day job, but the key issue is that you haven't demonstrated any security issue. There is nothing here that seems to be on topic for this site. Sure, there may be better ways to do things, but that's not a security concern

@MartinFürholz also be aware that what you are doing with the "want me to explain again", "are you following", "did you see that, do you understand that so far" could be taken as overly persistent, and that you may need to take a step back and review your work to see if there is a reason a few people are telling you it looks wrong

@RoryAlsop Do you agree with my statement in the comments "The thing is that the client absolutely expects that specific representation in the response. Therefore it would be much safer to return it directly with the response to the first POST request." ?

"if there is a reason a few people are telling you it looks wrong" From my point of view the reason is that most people in IT lack basic understanding of HTTP.

The fact that the majority of the commenting/answering users kept confusing the terms 'safe' and 'idempotent' repeatedly, assured me of that.

@MartinFürholz okay. I do see you misunderstanding idempotent/safe, so thereby lies the issue.

@MartinFürholz until you have a long hard look at that, and seriously consider that it might be you with the basic misunderstanding, then you may have challenges

So I'll step away and leave you to consider that. And consider that of the volunteers who try to help you, many will stop helping if you won't take on board their help

why are you so hostile?

You don't answer my questions, from the very start. And just make inappropriate accusations without any justification.

I understand that you don't care about this question, and feel annoyed by the whole process, but why don't you just leave it to other moderators then, to handle it?

Kinder, Kinder,... I'm sorry, but to me this way of ignoring my specific questions, and instead just throwing random accusations of lack of knowledge in my direction every time I ask you something, appears very childish.

@RoryAlsop: Regarding suspension of Martin: Please don't do that.

@RoryAlsop: Please consider following: Martin really tried to be nice. He has removed the part of his question about "idempotent" and posted it as a separate question at Software Engeneering SE: softwareengineering.stackexchange.com/q/411600/132918. I find this right. This shows also a good level of self-criticism. If you want, this is also nice to the community.

@RoryAlsop: Despite I disagree with with Martin regarding interpretation of "idempotent", I don't find his comments rude or unacceptable. We have just different interpretation. His question forced me (and probably many others) to reread the specification, and to think deeper what it really means, what do specifications say about it, what interpretations are possible. From this point of view the question was useful to me personally and I suppose to many users (esp. who commented), too.

@mentallurg there were a number of behavioural issues. But hopefully they will go no further. The rudeness was not in the content of the question, but the comments, and approach to others who have been trying to help. But thank you for speaking up in support.