I have a form which is posted to an MVC3 controller that then has to be POSTED to an external URL. The browser need to go to the URL permanently so I thought a permanent redirect would be perfect.
However, how do I send the form POST data with the redirect?
I don't really want to send another page down to the browser to do it.
Thanks
A redirect will always to be a GET, not a POST.
If the 2nd POST doesn't need to come from the client, you can make the POST using HttpWebRequest from the server. Beware the secondary POST may hold up the return of the client request if the external server is down or running slowly.
A permanent redirect is wholly inappropriate here. First, it will not cause form values to be resubmitted. Second, the semantics are all wrong - you would be telling the browser "do not request this url again. instead, go here". However, you do want future submissions to go to your same url.
Gaz's idea could work. It involves your server, only.
Alternatively, send a form with the same submitted values and the external URL, and use client-side code to automatically submit it.
Related
I am a total newb to API and json so this might be basic. But couldn't find a solution by googling.
I want to change e-shop order status via API by clicking a hyperlink in an e-mail.
I activated an API and managed to change the order status by Postman by following command:
PUT {url}/api/v2/orders HTTP/1.1
Content-Type: application/json
Authorization: Basic {abcdefgh}
{
"orders": [
{
"order_number": "00001",
"status_id": "16",
}
]
}
Is there a way how to run this command by simply clicking a hyperlink?
And should I be concerned about security since the authorisation is hardcoded there?
CHeerS!
Email clients for safety reasons do not support the execution of scripts or anything else other than a GET request. As this would require the use of javascript/jquery to build up a payload and call the API with said payload.
You will need to take the client to a secure page to sign in and manage their order.
The hyperlink can perhaps take them to a sign-in page or register page.
Token authorization might work with email being the verification taking the user to a page to see their orders. But again, you won't be sure an authorized person opens the email.
Regarding hard coding any type of authorization, that is a big no.
Since clicking a hyperlink in an email is the same as typing out the address in the browser bar, you can't make POST requests through it. One way of doing what you want is to generate a onetime-use token, and simply put it in the url. When the user clicks the kyperlink, the GET request to the server will contain the token, which can be used for validation.
Is there a way how to run this command by simply clicking a hyperlink?
Not in general, no. Clicking on a link in an e-mail issues a GET request, which can't contain a body. That is: your "orders" JSON won't be included. It also won't know to include the Authorization header.
As far as I know, no common e-mail clients allow you to issue PUT or POST requests.
So: could you encode the request in the URL, and use a GET request instead? Absolutely you could. Don't do this.
There are several reasons for this. The most important is the one you mention:
And should I be concerned about security since the authorisation is hardcoded there?
Hardcoding authorization is a bad idea in general, but particularly in an email: (1) you can't guarantee that an email is encrypted, which exposes the credentials to anyone who can capture the message; (2) if you forward the email to me, I now have your credentials.
Moreover, if you include the authorization in the URL, that's now in the user's browser history, and if they share the link with anyone ("hey, look at this deal on paperclips!"...), well: same as above.
I am looking for a deeper explanation of the html form action attribute than is usually given. What is really happening when the user hits 'submit' in the browser? I assume that the browser sends some kind of message to the web server software. So the browser is communicating with for instance Nginx.
But the way people talk about the action attribute makes it sound as if the browser is really sending the data to some arbitrary URL. Like to a php script located at that URL, but that doesn't really make sense to me. Is the form data really being sent to the web server and then the web server parses the action attribute and attempts to somehow submit the parameters and values to a script located there? In that case the URL specified by the action attribute would really be more like a suggestion to the web server.
Can someone explain to me what is really going on? I find the idea of the form data being sent to a 'where' or anything other than to the web server quite confusing and I have not been able to find a deeper explanation anywhere. All paths seem to lead to the concept of the form data being sent to some URL as if that actually made sense.
How can we submit a form without Javascript and not by pressing any buttons?
I need to transfer a content to another file when a function works under certain conditions. Both the files are written in Perl. The pages are loaded in a webserver(same). I need to transfer a value, which the user doesn't want to know what I'm sending. So I came up with the post method is safe.
But there I didn't find any ways to redirect a URL where the values are transmitted in post method. So I came up with the form submission. But the problem is I need to use javascript or make user to press a button to complete the task.
The problem with Js is there some users who disable JS in their browsers.
So using it is not preferable. With the button,
I can't make the user to do that for me.
Is there any other scripting language, which supports such functionality?
There are some conditions that I can't use session
What I did is encryption for identifying the user from knowing what data is transmitted. The receiving page will decrypt it when it is required. But it's not what I needed.
I need to transfer a value, which the user doesn't want to know what I'm sending. So I came up with the post method is safe.
It isn't. If you pass it through the user's browser, then the user can see it.
Is there any other scripting language, which supports such functionality?
No. There is no programming language as well supported in browsers as JavaScript, and none that are harder to disable then JS.
Store the value on the server (you could use a session) and redirect the user with a normal 302 status and Location header. You can pass a session token via cookies or the query string.
You can't make a user do anything, unless you're writing for a browser the equivalent of a trojan.
But secondly, without something on the client side, you can't ensure that you can get information that you didn't have when you sent the page.
You could place some links, and know which links they clicked on by passing it through a central tracking program, but those links wouldn't have anything in them that didn't originate on the server without client script running.
Still, despite that you can entice a user to click on a link more than a simply functional button, in either case you can't get guaranteed new information from them. They can always close the tab, close the browser, or press the back button. This goes back to point #1: you can't make users do anything.
Is there a way to include additional request headers in form data, other than action and method? I am hoping to send some authentication credentials cross domain without making the user re-enter their login credentials. ie I want to build an Authentication header directly from form submission.
The domain is SSL enabled, so I considered including credentials in the URL, but as explained here this is a bad idea, as those credentials may be secure over the connection, but can be accessed through the browser by other apps potentially.
Larger Picture
I have access to the cross domain username and password through an AJAX request to the client server (home domain). I want to take those credentials and submit them through a non-AJAX request, so a user can download a document securely without the URL being publicly accessible.
To the specific question, I believe the answer is no - you can't control sending any extra headers from the form itself. There are some other things you can send with a form, but they are not useful to what you want to do: W3 Form Tag Specification
What you could do is do a form POST, which is the standard way to communicate when sessions cookies are out of the question and a query string won't do; just use a hidden field with some sort of token/hash of the credentials. Avoid clear-text of passwords like the plague, and really try to avoid reversible encryption of them too. This is just one of those areas you have to be extra careful to avoid creating an easily exploitable security vulnerability.
But generally speaking it works just fine, and anything that can do an AJAX GET should be able to do an AJAX POST.
I'm trying to parse a bunch of webpages from an adult website using Ruby:
require 'hpricot'
require 'open-uri'
doc = Hpricot(open('random page on an adult website'))
However, what I end up getting instead is that initial 'Site Agreement' page making sure that you're 18+, etc.
How do I get past the Site Agreement and pull the webpages I want? (If there's a way to do it, any language is fine.)
You're going to have to figure out how the site detects that a visitor has accepted the agreement.
The most obvious choice would be cookies. Likely when a visitor accepts the agreement, a cookie is sent to their browser, which is then passed back to the site on every subsequent request.
You'll have to get your script to act like a visitor by accepting the cookie, and sending it with every subsequent request. This will require programming on your part to request the "accept agreement" page first, find the cookie, and store it for use. It's likely that they don't use a specific cookie for the agreement, but rather store it in a session, in which case you just need to find the session cookie.
The 'Site Agreement' page probably has a link you have to click or form you have to submit to send back to the server to proceed. Read the source of that page to be sure. You could send that response back from your application. I don't know how to do that in Ruby, but I've seen similar tasks done using cURL and libcurl, which can probably be used from Ruby.
Install LiveHTTPHeaders plugin for Firefox and visit this site. Watch the headers and see what happens when you accept the agreement. You'll probably see that the browser sends some request (possibly a Post) and accepts some cookies. Then you'll have to repeat whatever browser does in your Ruby script.