How to hide bound form data play framework - post

In play framework, what causes bound form data to be hidden on a POST request?
for example if a form has fields Name and Age with values:
name: John
age: 20
What causes the post request to show
localhost:9000/adduser
vs
localhost:9000/adduser?name=John&age=20
Thanks

The cause of this is POST request itself.
This
localhost:9000/adduser?name=John&age=20
is a GET request.
It's good policy to keep actions that can modify data within POST requests and make server redirect to original page so that user won't see "do you want to resubmit form" alert.
It's also good style to keep actions that must be reproducible across machines within GET requests (such us search results so that one's able to copy'n'paste link and send it by email).

Related

Survey Monkey - Get form data - API

I'm trying to get the field values submitted through survey monkey forms. Since its in a seperate iframe, i cant access it from my domain (CORS). Is there any api to get the individual responses submitted through these forms?
You mean you're using a website collector and the responses are embedded on your website, and you want to read the responses in javascript when the user submits the form? Yes that won't work.
Either way I think the best way to do it is to use the API.
You can fetch the list of survey responses (and their details) see the docs.
To get the list of responses for a survey you would do:
GET /v3/surveys/<survey_id>/responses
You can filter by date or other fields (if you need be).
You can fetch the full details with
GET /v3/surveys/<survey_id>/responses/<response_id>
Alternatively, you can setup a webhook where you'll be notified every time a new response comes in, you can then make the request defined above to get the details of the response.
Hopefully those options work for you, I don't know your use case well enough to give other options.

Get Attendee Data w/ Website Workflow's 3rd Part Next Steps

I am working w/ the Event Brite API and I have a need that I am trying to figure out the best approach for. Right now, I have an event that people will be registering for. At the final step of the registration process, I need to ask them some questions that are specific to my event. Sadly, these questions are data-driven from my website, so I am unable to use the packaged surveys w/ Event Bright.
In a perfect world, I would use the basic flow detailed in the Website Workflow of the EB documentation, ending upon the "3rd Party Next Steps" step (redirect method).
http://developer.eventbrite.com/doc/workflows/
Upon landing on that page, I would like to be able to access the order data that we just created in order to update my database and to send emails to each person who purchased a seat. This email would contain the information needed to kick off the survey portion of my registration process.
Is this possible in the current API? Does the redirect post any data back to the 3rd party site? I saw a few SO posts that gave a few keywords that could be included in the redirect URL (is there a comprehensive list?). If so, is there a way to use that data to look up order information for that order only?
Right now, my only other alternative is to set up a polling service that would pull EB API data, check for new values, and then kick off the process on intervals. This would be pretty noisy for all parties involved, create delay for my attendees, and I would like to avoid it if possible. Thoughts?
Thanks!
Here are the full set of parameters which we support after an attendee places an order:
http://yoursite.com/?eid=$event_id&attid=$attendee_id&oid=$order_id
It's possible that order_id and attendee_id would not be a numeric value, in which case it would return a value of "unknown." You'll always have the event_id though.
If you want to get order-specific data after redirecting an attendee to your site, you can using the event_list_attendees method, along with the modified_after parameter. You'll still have to look through the result set for the new order_id, but the result set will be much smaller and easier to navigate. You can get more information here: http://developer.eventbrite.com/doc/events/event_list_attendees/
You can pass the order_id in your redirect URL in order to solve this.
When you define a redirect URL, Evenbrite will automatically swap in the order_id value in place of the string "$order_id".
http://your3rdpartywebsite.com/welcome_back/?order_id=$order_id
or:
http://your3rdpartywebsite.com/welcome_back/$order_id/
When the user completes their transaction, they will be redirected to your external site, as shown here: /http://developer.eventbrite.com/doc/workflows/
When your post-transaction landing page is loaded, grab the order_id from the request URL, and call the event_list_attendees API method to find the order information in the response.

Play Framework - GET vs POST

New to web development, my understanding is that GET is used to get user input and POST to give them output. If I have a hybrid page, eg. on StackOverflow, if I write a question, it POSTs a page with my question, but also has a text box to GET my answer. In my routes file, what method would the URL associated with my postQgetA() method specify - GET or POST?
From technical point of view you can use only GET to perform almost every operation, but...
GET is most common method and it's used when you ie. click on the link, to get data (and do not modify it on server), optionally you send id of the resource to get (if you need to get data of single user).
POST is most often used to sending new data to the server ie. from form - to store them in your database (or proccess in any other way)
There are also other request methods (ie. DELETE, PUT) you can use with Play, however some of them need to be 'emulated' via ie. ajax, as there is not possible to set method of the common link ie. to DELETE. It's described how to use non-GET/POST methods in Play! (Note, that Julien suggests there, using GET for delete action although is possible it's a broken semantics.)
There are also other discussions on StackOverflow where you can find examples and suggestions for choosing correct method for your routes.
BTW, if you sending some request, let's say it's POST you don't need to perform separate GET as sending a request generates a response in other words, after sending new question with POST first you're trying to save it to DB, if no errors render the page and send it back in response.

What methods are available to stop multiple postbacks of a form in ASP.NET MVC?

A common web problem is where a user clicks the submit button of a form multiple times so the server processes the form more than once. This can also happen when a user hits the back button having submitted a form and so it gets processed again.
What is the best way of stopping this from happening in ASP.NET MVC?
Possibilities as I see it are:
Disable the button after submit - this gets round the multiple clicks but not the navigation
Have the receiving action redirect immediately - browsers seem to leave these redirects out of the history
Place a unique token in the session and on the form - if they match process the form - if not clear the form for a fresh submit
Are there more?
Are there some specific implementations of any of these?
I can see the third option being implemented as an ActionFilter with a HtmlHelper extension in a similar manner to the anti-forgery stuff.
Looking forward to hearing from you MVC'ers out there.
Often people overlook the most conventional way to handle this which is to use nonce keys.
You can use PRG as others have mentioned but the downside with PRG is that it doesn't solve the double-click problem, it requires an extra trip to the server for the redirect, and since the last step is a GET request you don't have direct access to the data that was just posted (though it could be passed as a query param or maintained on the server side).
I like the Javascript solution because it works most of the time.
Nonce keys however, work all the time. The nonce key is a random unique GUID generated by the server (also saved in the database) and embedded in the form. When the user POSTs the form, the nonce key also gets posted. As soon as a POST comes in to the server, the server verifies the nonce key exists in its database. If it does, the server deletes the key from the database and processes the form. Consequently if the user POSTs twice, the second POST won't be processed because the nonce key was deleted after processing the first POST.
The nonce key has an added advantage in that it brings additional security by preventing replay attacks (a man in the middle sniffs your HTTP request and then replays it to the server which treats it as a legitimate).
You should always return a redirect as the HTTP response to a POST. This will prevent the POST from occuring again when the user navigates back and forth with the Forward/Back buttons in the browser.
If you are worried about users double-clicking your submit buttons, just have a small script disable them immediately on submit.
You might want to look at the Post-Redirect-Get (PRG) pattern:
This really isn't MVC specific, but the pattern we follow on our web pages is that actions are performed with AJAX calls, rather than full page POSTs. So navigating to a url never performs an action, just displays the form. The AJAX call won't be in the history
Along with the disabling of buttons, you can add a transparent div over the entire web page so that clicking does nothing. We do this at my work and add a little friendly label saying processing request..
The most elegant solution I found was to use ActionFilters:
Blog post is here

GET or POST, which method to use for submitting a form?

I'm writing a web form for my Ruby on Rails app. The form has a text field, some checkboxes, a set of radio buttons and two text boxes.
What are the pluses and minuses of using GET over POST and vice versa. I always thought you should use GET for retrieving the form and POST for submitting, but I've just learnt you can do both. Does it really make a difference? Cheers.
<% form_tag({ :action => "create" }, :method => "get") do %>
GET requests are always added to the URL, where as POST is submitted with the body of the request. As you note both can be used to retrieve and send data, but there are some distinctions:
As GET is sent with the URL you are limited in size to the maximum length of the query string. This varies from browser to browser, but is usually at least around 2000 characters (on modern browsers). This usually makes it inappropriate for sending large text fields (eg email).
AS the GET command is exposed in the query string it can be easily modified by the user
As the GET command is in the query string it does make it easier for users to bookmark a specific page, assuming your page will work with some state variables stored.
POST is usually more appropriate for sending data, as it is suits the nature of a request, mostly because of the limitations of the above.
The HTML specifications technically define the difference between both as "GET" means that form data is to be encoded (by a browser) into a URL while the "POST" means that the form data is to appear within a message body.
But the usage recommendation would be that the "GET" method should be used when the form processing is "idempotent", and in those cases only. As a simplification, we might say that "GET" is basically for just getting (retrieving) data whereas "POST" may involve anything, like storing or updating data, or ordering a product, or sending E-mail.
Depends on if you're being semantic or not. Both GET and POST hold intrinsic meaning if you're making an HTML-based API. But in general, GET is used for fetching data, POST is used for submitting data.
The biggest difference is that GET puts all the data in the URL (which can be limited in size), while POST sends it as a data part of the HTTP request. If you allow data entry with GET requests, you're also making a lot of web exploits a lot easier, like CSRF. Someone can just make a pre-filled link to the vulnerable form's action (say, a password change form?), send it to unsuspecting users who click it and unknowingly change their password.
In addition, no browser will warn the user if they refresh a GET page that does data entry (which would make a duplicate entry, if you're not careful), but on a POST, most browsers will show a warning.
I think other answers covered the main stuff. Also I want to add this bit. Using GET for critical data such as sending password over a GET request will expose the password more than POST because it'll be stored in browser's history cache, proxy caches, server logs etc.

Resources