The issue is that there is a form I want to fill. It's submitted via a POST request. But technically I can use only GET requests (pass an URL with GET parameters). And I don't have access to a server where the site (with a form to fill) is located.
I've tried to use POST params in GET request, but it didn't work. The other thing that came to my mind was to send GET request to my own server, which will perform the desired POST request. But I need the request to be commited from my IP, but not from the server's one...
Can anybody give some piece of advice concerning solving this problem?
Is this homework? Seems odd that you wouldn't be able to use a POST.
Regardless,
The best way to do this would be to override the onclick event of your submit button; the JS function could poll for the fields you are looking to submit. Then use encodeURIComponent() on the values to get them sent to your webserver correctly.
Here you would be able to load the new page with the get?element=value&.... request.
http://www.w3schools.com/jsref/jsref_encodeURIComponent.asp
Firefox allows you to turn an HTML form (either GET or POST) with at least one regular text input field into a search keyword bookmark, although I'm not sure how easy it is to import and export an individual bookmark from one copy of Firefox to another.
Related
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.
I have a page with a list of items and above the list I have multiple links that act as filters. Clicking on the links causes an ajax request to be fired with a whole host of URL parameters. Any example set of params after clicking a few filters:
?letters=a-e&page=1&sort=alphabetically&type=steel
It is all working fine but I feel like the params on the URL are very messy, and the code behind has to do alot of checking to see which params exist, merge new ones, overwrite existing ones etc.
Is there a nicer way to accomplish this without URL parameters.
I guess the downside to that would be the fact a user would not be able to link to a specific filtered view or is there a way this could be accomplished too?
You have several options when working with long query strings. If this isn't really causing a problem (like requests dying) then you should ask yourself if it's really worth the effort to switch it to something else.
Use POST Requests
If the length of the query string is causing problem, you can switch to using POST requests instead of GET request from your filter links. That will prevent the URL from containing the filter parameters, but your controller can still deal with the parameters in the same way.
The link_to helper can be setup to use a different HTTP verb as follows:
link_to("My Filter", filter_path, method: :post)
Make sure you update your routes appropriately if you use this technique.
Use an Ajax Request to Refresh the Page
If you configure your filters to all be remote (Ajax) links, you can update the filters and refresh the contents of the page without ever changing the URL. This is the basic pattern of the solution:
Send a remote request to the server with the current filter options
Update the page contents based on those filters
Make sure the filters (and remote request) will submit all of the current parameters again
Store Filters in the User's Session
If you store the current filters in the session, whenever the user visits the base page, you can retrieve the stored filters and only display the appropriate information. Your filter links could still be GET requests (including the lengthy query strings), but instead of rendering the page after the filter request, you would redirect back to the main list with no extra query parameters. That would make it appear to the user that the URL never changed, and would even allow you to remember their last filter if they navigate away.
Sharing Links
Like you mentioned, sharing links becomes a problem with all of these solutions. You can provide a "share this filter" section on the page to help mitigate that. You would put a URL the user could copy in that section that includes the necessary information to recreate the filter. The links could contain the full query string or perhaps an encoded version of the filter.
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.
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
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.