As far as I understand, GET has to be idempotent - it cannot change anything in the system and repeating it should always return the same unless something else changed the state of the application.
Problem is, on my website, there should be a lot of little changes based on whether some content has been already seen before by the user. I mean, like notifications, new message alerts, content sorting based on whether user saw it or not, how many users saw the content counters... For example when user clicks on notification, the notification should disappear from his notification panel and never be seen there again, so it changes something - state of the notification, but I can press F5 as many times as I want and it always returns the same page with same info, same buttons etc.
Can I ignore this kind of side-effect as too small and I can use GET or do I have to make most links and buttons on the website use POST like I do with links and buttons which lead to more "serious" changes? I do that by making forms around each of them with those links as form actions and original buttons as submit buttons of the form which seems a little messy to me and I don't want it almost everywhere (or is there a better way?).
This can be tackled from several points of view, I'll illuminate it from this angle:
The end result here is always the same, hence the request is idempotent.
The user visits the URL, the end result is that the notifications are cleared. They can visit the page again and again, the end result is that the notifications are cleared. They're not going to get an error message because the notifications have been previously cleared (that would not be idempotent). Yes, they will see different content each time they visit the page, but nothing says that the page content must be identical each time the resource is requested (that would put half the web in a bind).
Contrast that with a POST request to /questions (which creates a new question, for example): each time you repeat that POST request, a completely new resource is being created. You POST once, and /questions/12345 is being created. You repeat the same request, /questions/12346 is being created. That is not idempotent.
No, you do not need to make all those requests into POST requests.
Related
When users request a password reset, they get an email with a link to generate a password reset code. This link is valid for 24 hours and can be re-used within the 24 hours to generate a new code if the first is lost or forgotten. When users double click the link, two codes are getting generated, leading to user confusion about which to use (the second code invalidates the first code with the way it has been developed).
Since the link in the email is just an html a tag, I'm not sure how I can keep users from double clicking the link.
This sounds like you're facing the XY problem. Your actual issue is that users get confused by visits in a quick succession causing a code that was just generated to be invalid, rather than the fact that the link can be clicked twice.
From a security point of view, these kind of links should really be single-use, and the user should request a new e-mail if they want to perform the action again. Assuming this is something you're forced to do, I believe the best compromise would be to limit code generation to a time frame, so visits within, let's say, 5-10 seconds would result in the same code being shown to the user, based on the server's time.
Implementing any CSS based solution for this that'd work across every e-mail client out there is challenging enough (if at all possible), and I doubt any self-respecting e-mail client is going to let you run any sort of JavaScript to intercept the event.
The following works in a modern browser on an actual web page, but this is not just a bad idea, it's also probably not going to work if you try to use it in an e-mail. I'm providing it here just for the sake of completeness, showing that it's somewhat possible, but please do not rely on this to fix the underlying issue.
<style>a:focus { pointer-events: none }</style>
<p>This is some text, here's a link you can't double click by the way.</p>
Okay so here is my problem. I have developed a framework which does the following:
If, for example, you have four webpages... but you only want to allow users to reach the "4th" webpage after progressing through pages 1-3 sequentially - I have built this functionality (basically I set an encrypted cookie keeping track of what the user has completed thus allowing to know what they should be able to access). There are two parts of it:
1) If a page does NOT have a quiz, the user must only visit the webpages sequentially to be allowed to view the 4th page in the "progression".
2) However, if a page has a quiz on it, the user must successfully pass the quiz to go on to the next sequential page.
Now... Here is the real biggie... The last page will often be a web form which, obviously, I only want an individual to fill out and submit if they have reached the form by sequentially getting to that last page in the progression... BUT I found a flaw in the system. If someone were to go completely through the progression and fill the form out... they could delete their browser's "form data" and go "back" to the form and allow a friend to fill the form out. That would be detrimental to the system, and the users who will be navigating this progression are GOING to look for ways to get around going through it.
Some of the suggestions I will probably get will not be possible given the larger framework I am in, but rather than list all of the impossibilities I would like to see what you guys thought would be a way of getting around this issue?
P.S. This functionality is built in HTML and ColdFusion.
Thank you for any feedback, it is a great help!
EDIT:
Keep in mind the user must be able to back track any previous page they already completed.
I am currently working on a GWT application that requires report
printing. The use can select report parameters from a screen, and
upon clicking print we would like to display the file as it is being
generated. Currently we have server side code that is generating HTML
and writing it to a file. When the user clicks print, an RPC is being
made to pass the report parameters to the server and begin the
report. A second RPC is made after the report has started to obtain
the report's URL. From here, we are creating a Frame and setting the
URL to be the URL retrieved by the second RPC.
The issue I am running into, is that when setUrl gets
called, it only displays as much HTML that was contained in the file
at the time of the call. What would be the best way to refresh just
the frame containing the HTML report? It appears making subsequent
calls to setUrl passing in the same Url each time would do the trick,
but it actually doesn't seem to contain the additional content that
would've been written since the last call. It is also resetting the
vertical scroll bar's position each time back to the top of the bar
which is something else I would like to prevent.
Is there a better way to go about doing this?
I think it would be better to request HTML in chunks from GWT and render them as they arrive. Doing this with ajax instead of wholesale refreshes will enable better behavior with the scrollbar, eliminate flashing, get around caching problems, and will also let you add some feedback like a progress bar, estimated time remaining, etc.
There's a lot more infrastructure required for this, but your suggested solution doesn't seem quite appropriate for the task.
I am sure everybody knows that behaviour. You fill in a form on the web, and you submit it. After the submission you recognize that you filled in some wrong data. So, you click on the browsers back button. Then, sometimes the form still have the data you entered (what you are hoping in this situation) and sometimes not.
I couldn't find any connection when it is cleared and when not.
Some answers i found on the internet / stackoverflow:
on https connections, forms are always cleared
when using dynamic websites with sessions, forms are always cleared
But both of them are definatly wrong. I have seen sites (like one of my own) that does keep the form-data after the browser back and are using https and are using sessions.
So please: can anybody explain me how browsers are handling this stuff?
By the way: my task is it to make sure that the form data is not cleared.
I can't provide the definitive answer for all scenarios.
As a web developer, here's the rule I generally follow for sites I develop, to accomplish the goal of not letting the user lose data:
Disable all caching (via HTTP headers) on the page you want retained.
Capture all data into session (or some other temporary storage) when the form is submitted.
If the user navigates backwards, the browser requests a new version of the page (because you set it to never cache).
The page has logic to look to the session/database/wherever and repopulates all the fields based on the last input state. If there were dynamic inputs on the page, you should have enough data to recreate them.
Once the process is finished, use a POST/Redirect/GET pattern to clear the session data and make it difficult for the user to go back to the original page.
Some answers i found on the internet / stackoverflow:
1. on https connections, forms are always cleared
2. when using dynamic websites with sessions, forms are always cleared
I believe #1 varies by browser/security settings/scenario.
Assumption #2 is certainly not true in all cases (the pattern I just described leverages session and dynamic forms).
Its a browser issue. Browsers behave differently when the back button is clicked.
This question was asked before here Losing form data when clicking the back button on browser
I have a handful of pages that let me alter the status of things (like changing the status of a listing or deleting an user) and I was wondering: should I use a link or create form buttons for those actions? (without javascript)
What are the pros and cons of each implementation? It seems to me that link is easier to code but form buttons seem more secure.
What do you think?
Non idempotent operations, like creations, updates and deletes are supposed to be done with a POST. So, without JavaScript, a form should be used with a submit button. This at least warns the user, if he refreshes the page after the delete, that the action will be resubmitted.
A useful pattern, to let the user refresh the page after the post and not risk a re-submit, is the redirect after post pattern , also known as post-redirect-get. This makes sure a refresh is possible, and make the browser "forget" about the post in his history, allowing the user to go back without resubmitting the delete.
well with css you can make buttons look like links and links look like buttons, so it's mostly a matter of appearance.
Personally, I try to use links to indicate movement (to another page, to another part of the page, popup page, etc) and buttons for actions (updates, deletes, 'buy', etc)