If I visit the link http://mega.1280.com/file/EKOZKE/, enter the captcha code and click the Download button, I can download the file.
I wonder if I can submit the form without clicking the 'Download' button? I mean typing the captcha code directly on the address bar and hit Enter?
I try http://mega.1280.com/file/EKOZKE/?code_security=xxxxxx where 'code_security' is the name of the textbox of the captcha code but it failed. Any ideas?
The form has a POST method. You can't emulate a POST request with a different url, that's what GET requests do.
Even if the server doesn't check the method of the request, you still have to provide every mandatory data. If you look at what is sent by the form, you'll see there are 3 other parameters (action, btn_download, file_id), and more importantly several cookies that the server need to recover your php session (PHPSESSID), which is in turn needed to match your security_code with the provided CAPTCHA.
Bottom line: you can emulate the request, but not by submitting a simple GET request. You have to use a real user agent, one that is able to send post requests and handle cookies.
...But of course, that's exactly what CAPTCHA are here to prevent you to do :-).
edit: to reply to your comment "I just want to find out the technique that this website use to submit form." :
This website doesn't submit the form, actually. It's your browser that submits the form, and it does so by conforming to HTML and HTTP standards. On the webpage, the form is coded
<form name="frm_download" method="post" action="">
So when you click on the "submit" button, your browser collects all the data from the inputs (text, hidden, whatever) and sends a HTTP POST request to the same url that the form originated from, with a bunch of HTTP headers (including a Cookie header that contains all the stored cookies information attached to this server domain) and a body containing the form data : a list of key/value pairs.
The server receives the request. It can check that it's actually a POST request. It can and will retrieve all submitted pairs of data (parameters). It can retrieve the cookies, and will do so to restore your php session. It will then compare your security_code parameter with the correct data stored in your php session. If the CAPTCHA matches, then it will send you a response containing the file pointed by your file_id parameter.
Related
System I have to update has http-handlers that are accessible via address like
http://<server>/handlers?name=some-handler-name
I added http form with action tag that directs to one of this handlers like this:
<form ... action="/handlers?name=some-handler-name" >
My form is a part of a system and located right on the same server. Basically its accessible via adress like
http://<server>/handlers?name=my-handler-with-form
But when I submit my form - nothing is posted to some-handler-name handler because my http-request receives code 302 (redirect).
Do I use correct address in action method (what I want is my form data to be posted to address like http://server/handlers?name=some-handler-name)?
Is it possible to post data to url that has query string parameters?
I guess that system intercept my postback and for some reason redirects it
Correct address is important
Yes, it is possible to post data with query params
There would be some redirect rule set at the server side. You would need to work with server side dev or read server side deployment/code documentation.
GET is used to retrieve remote data, and POST is used to insert/update remote data
But when we use <form> to send data we can put in action either POST or GET and in both cases data will be sent. In this case data will not be retrieved or inserted just will be sent to the server.
Do these GET and POST methods in the <form> are not the same as GET and POST from the description above?
The form action will tell your browser how to send the form data.
In case of GEt the form data will be present as query string arguments, in case of POST as a multipart/form-data body. And, of course, this will also alter the method of the query (as GET or POST).
This is for the client part of the protocol.
Now, on the server side, GET and POST SHOULD not behave in the same way.
GET is indempotent
POST is not
It means the server (or the server chain, you could have a Reverse Proxy Cache in the chain) MUST expect that a POST is doing something to the application data, so the application or state is not the same after the POST (maybe you now have a session, or you've just deleted something, or added something). End this means you cannot re-play a POST two times without risks. In fact nobody should never replay the POST, that's one action.
If your form is posted as a GET that's a diffrent story. Your just asking for an url (wich contains your form data in the query string of the url), and you get a result, but replaying the same url several times SHOULD NOT be a problem, we could also cache the result and reuse this cached result for someone requesting the same url (so having the same elements in the form, which are now in the url).
So your application MUST NOT perform data alteration if the method is GET. Not deleting something, not creating something, etc.
So why would you send a form as GET? Maybe just to obtain a filtered page result where everybody should obtain the same page result with the same filters. But certainly not to post a registration form (or an admin-level-delete-this-user action).
I am trying to record a simple login and logout flow for a .Net application. After I submit the login credentials the welcome page's URL has a large alpha numeric number. This number is required to continue to the next steps.
On Fiddler I have noticed that the login credential submission request results in a 302 response and this response contain an a=129characterstring that i need in my subsequent requests.
On JMeter I have added a recording controller and on the HTTP(S) Test Script Recorder I have Follow Redirects and Use KeepAlive checked (See below screenshot)
I have also recorded with Follow Redirects unchecked and different options for Grouping and HTTP Sampler Settings.
But with none of them I am able to record/capture the 302 response that i see on fiddler. Instead the login credential submission request always returns a 200 response, even if the login fails.
It is not as if that JMeter is not recording redirect requests, further down the scenario flow I have another redirect request which is captured.
I can't be the only one who is/has faced this problem. Does anyone have any suggestions on what I should be doing differently to get the 302 response?
To do this:
Record with default options, the redirect Http Request triggered by 302 will be disabled by default.
Then you will need after this to uncheck "Follow Redirect" in the first one, and add a Regular Expression Post Processor to extract the data you want.
Then enable the commented second request and inject the extracted variable.
The default process when authenticating user on OpenAM/OpenSSO works with a 302 http redirection, opening OpenAM/OpenSSO authentication formular. The original URL is stored into "goto" parameter, which allows OpenAM/OpenSSO to redirect the user back on orignal URL after correct authentication.
This works well when using HTTP GET method (i.e. when entering URL), but it is not suitable for POST method. For instance, if the session expires while the user posts a HTML form, the data are lost because HTML form inputs are not present in goto parameter.
Do you know it it is possible to configure J2EE Agent in order it re-posts user HTML form after valid authentication ?
Both the Java EE and the Web agents support post data preservation, see the documentation.
I know you send a cookie to a user's browser via the HTTP header, but how do you do this after the header has been sent. For example you set a value in a form you want to grant session wide scope to.
Thanks!
You can't. Cookies are only set in the header. HTTP provides no way to set them elsewhere.
If you want to set a cookie based on form data, then you do it in the response to the form submission request.
If you want to use data both for generating a cookie and generating a form, then get that data into a variable before you send the header and use it in both locations.
(You could generate JavaScript to set the cookie in the HTML body … but that would be unnecessarily complex and unreliable).
If you want to set a cookie after you've already sent a response header, you have to make the client load something else that can set the cookie. This might be through an Ajax response, an image link, or something else. You might fire this off automatically or ask the user to update something.