I'm developing ASP.NET applications and stuck with a "problem" relating to resubmit behaviour.
I'm controling the re-submit using a counter in form submit event which disables the submit if it's already been posted.
My application is a 3 step workflow and when the 3rd step is shown the transaction was submited from step2 to step 3.
What's my problem? Well... i want to avoid the user to resubmit the data by pressing the F5 or all other possibility. I don't want to disable the key because may be workarounds.
I'm wondering if i can remove the post data in a HTTP module that runs after the render was completed and right before the response is sent to the user.
You can use Post/Redirect/Get "pattern", where when user post data, you redirect it (after processing submitted data) to another page that will response to get. Just like stackoverflow and another sites are doing.
Here's is the Wikipedia page that explains the Post/Redirect/Get Pattern.
Maybe I misunderstood your question/issue but it sounds like you may be making things harder than they have to be. If you are already keeping track of whether or not the form has been submitted before, why cant you just check that flag on the code behind before performing whatever logic you execute on the submit? If it has already been submitted before, just ignore the resubmit event and maybe set an error message.
Related
My question is very specific and not for all, I want people to help me with my train of thought.
What I want to build : for example I have service where all people (not logined) can create they post with some data like news and publish it for money.
How I think it should be built (in 2 steps):
Man click on the link to page with form that create posts and router go to this page
He fills data and click submit
Server checked form and if all OK, session.set this data that he fills and route to the next step (pay money
to publish they post)
(I want to build this with stripe so) He clicked on stripe checkout button and pay some $$, if he paid then show message, all ok, we session.get data that he fills from previous step, and on server we insert his post and go it, if not show message that something wrong
Technical Plan session.set session.get, it is right ?
And if someone slip through form with fills and go to payment page, how to check it ? If session.get === undefind or something like this, reroute to previous step ?
As you can see I have a lot of questions, and I cant find answers in google or some documentation tutorials and etc. maybe some have answers to it
Your question is very wide. Consider narrowing it.
Your 2 first points make sense. It's ok. The third and forth are wrong.
Technical Plan session.set session.get, it is right ?
No it is not. You plan to use the information you hold in a Session variable to publish data validated on client side. It does not ensure the validity of your data. This is a bad idea because anyone can open the console and edit the data to make it different/invalid regarding your rules of validation. All it takes is a Session.set ("yourData", "YouHaveBeenHacked");
What you need is to call a Meteor method on server side to add an entry to a dedicated collection. You add another field (e.g; status) to keep track of the post payment and publication and return the data entry _id that you store in a Session variable.
This way, your method can return an error if the data does not fit into your requirements.
Side note: you also need to add a CRON job serverside to get rid of all the old post tentatives that have not been paid for (user left his browser, he closed tab, etc.).
In my asp.net web application, the session is set to its default timeout value. As far as I understand, the timeout starts to count the minutes as soon as the application is idle and no action is done on it. However, when i open up a form and start filling it, if I take longer than 20 minutes to fill up the form then when i press "Save" the application logs out. I'm not inactive, but actually i'm filling up data in the form, so I don't want the session to timeout.
Is there a way to let the session only start counting the time when there is no action at all and let it "sense" the typing of the user ?
What you are looking for is called a "heartbeat". There are a number of ways of achieving this - the easiest will depend on what other assets you already have in your page - jQuery, AJAX controls, whatever.
The basic premise is that it sends, in the background, a request to the server effectively saying "I am still here" to the server to stop the timeout from happening. Ideally your solution should be checking for onkeypress in the javascript to ensure a user is there and filling in the form.
A search for "heartbeat form filling javascript asp.net" leads to a few sample ideas.
I'm developing an online quiz site where the users can take tests (multiple choice). I have a requirement to put a timer on the test say if the maker of the test sets the time to 30min a timer would be placed on top of the page counting down the time, now i want to monitor the timer on the server side when it reaches to 00:00 the test would stop and the marks obtained is shown.
Solutions i have considered:
1) To use a JS plugin and upon its expiry do a location.href to some ActionResult that will end the test.
2) To create a session and clear it after the given time and before rendering each question check that session if it has expired or not.
My concern about using a javascript based solution is its robustness, i want to implement a server side solution. Please help me find the right path...
Regards.
When using the timer in the browser there is no way to verify that it is running as expected. User can disable javascript and get around your restrictions; heck they can even change your javascript. So relying solely on javascript is not an option.
The best solution is to validate postbacks on server side. You can use javascript on Client side to inform the user so that they are aware of how much time is left and server side to verify they have not gone over the time limit. If synchronization is required, then you can have the javscript ping back every so often to resynch the time.
Expanded Answer
The time of the start of the test should be on the server side. Whenever the user clicks begin test or other start buttton to begin their test. The server should note the current time - perhaps in a session or even in database.
The user should then be informed of the time remaining via javascript and expected end time. These are then updated whenever the user submits a question or perform another postback to the server.
The end time will be the fuzzy part. If the javascript does it's job correctly; you can inform the user their test has ended through this (or window.href etc). If the javascript is not worked; then the user will receive their notification whenever they next attempt to submit something to the server.
Either way, the user should clearly be informed that this is the expected end time, and how much time they have remaining on each page load.
I have a webpage which has a form that is submitted via POST. This POST-route processes some data and redirects the User to a GET route. The problem: The GET route is called multiple times, usually 3 times. So three GET's are fired and the user see's the first GET request. The other two GET requests I can just see on my logs.
Occasionally it even happens that the GET is called more than three times...
(Of course the POST route is just called once...)
By the way I'm using JRuby/JRack/Sinatra on Jetty (-> Google App Engine.) The problem happens locally and remotely.
Philip
I have had that same issue in my code before (although different platform). It turned out to be elements in the page referencing the same url as the page. I had 1 broken image and 2 ignored css files that had been set to the parent page.
If it's the same kind of issue you can use Firebug's net tab to verify and debug.
Not sure without seeing the code, but in most cases a script will continue to execute after a call to a redirect function. Try returning from your method immediately after calling redirect_to.
There is a logical bug in your code. Fix it.
If I have a small microsite and on the first page I want to ensure that the user cannot jump to a non secure page between (e.g. 2 or 3), what would be the best way to implement this? The next page can only be seen if the user sets a certain item in a drop down box.
My first thought is cookies. If the user goes to the second page and the cookie's value is null, then there is a redirect to a failure page. If the user chooses the right value, the cookie's value is set to being a success. Would this approach work if I send a link on the 2nd page to a friend on another PC?
Is there a better way?
Cheap, downa and dirty? The cookie or session value work. Neither are reliable long term.
If you are making it so a user can only see certain info after selecting a drop down, you can hide it in a panel and only show that panel when the drop down is selected. This is the most useful if you do not mind the user having to select from drop down each time. You can use this with a cookie, as well, if you want the user to be able to see the data without selecting the drop down.
Hidden in the same page (drop down in one panel, info in another), you can keep it hidden perpetually.
If this has to be a second page, you can also put the page in another directory, and then put a web.config file in there that requires log in. You can then make it like a "log in" by "logging in" every person that answers. You end up using the Membership bits, but they are not hooked up to anything.
Cookies are not a good idea for this for one specific reason. They are under the control of the user, not you.
If a user has cookies disabled (globally or just for your site), they won't be able to get to page 2 now matter how many times they've read page 1.
In addition, if they know what your cookie contains (i.e., it's not encrypted), they can easily create it themselves or forward the method to a friend to get them to create it.
Regarding your question on whether you could send the page 2 link to someone else, cookies belong to the computer. That means the "someone else" would almost certainly not have the correct cookie for properly viewing page 2: they'd get an error.
We implemented a similar scheme (many years ago so there may be better ways to do it now). It involved storing a special "one-time" key when delivering page 1 to an IP address. The links in that page 1 were modified to include this key as an argument so that, when you requested page 2, the key was sent through as well.
The keys had a 30-minute lifetime (configurable but we ended up at 30 minutes). In order for us to deliver a page 2, the request had to come from the same IP address and have the proper key.
This prevented forwarding of links to other places and ensured the links had limited lifetimes.
Whether that's a viable solution for you is a question only you can answer. I know we got a few complaints from people who bought up page 1, then went out for a coffee. When they got back, their attempt to access page 2 was unsuccessful. We fixed this by simply redirecting them to page 1 with a suitable error message that their key had timed out.
Not perfect but, since the users were educated as to why it was happening, they understood its necessity.
If I understand your question correctly then the link you send to your friend will not work as they will not have the cookie stored in their browser memory or on their machine. This would also be true if you stored the value in Session as they will be creating their own new session when they opened the link.
To get this kind of behaviour when sharing links you will need to pass the value in a querystring i.e. when you select the desired option on page 1 and sublit the form the postback takes the selected option and then redirects to page 2 with option appended to the url as a querystring value.