Why aren't the POST params that are being set by a html form on another domain being received by my PHP script being hosted by Heroku?
Context:
I've got a simple html form which is sending some user data to a PHP script I've put on Heroku. The form is on a different site/domain, but as I understand the Same Origin Policy shouldn't be breaking the request. In fact, I've tested sending the request from the form to my local machine and the script worked fine.
The request fires perfectly normally from the html form, but by the time it gets to my PHP script, the $_POST array is empty. After checking the Heroku logs, it actually looks like the POST request gets received as a GET by my script.
Is there simply a config/routing thing I haven't done (I'm new to Heroku)?
I took a look at a couple of other questions/answers like this one, but no solution has worked yet for me.
Many thanks in advance for help
UPDATE 1 (4/4/12)
It appears that the POST requests are being moved as CoR has described in his answer. I can't figure out how to stop this from happening though. From researching around, it appears that this moving of POST requests only happens if you're not making them via https.
For now I've submitted and changed the forms method to GET, which works fine. It would of course be nice to know if one can enable POST requests on their Heroku app without setting up SSL.
UPDATE 2 (6/4/12)
I've just opened a ticket with Heroku to find out whether the only way to support POST requests is if you enable SSL. I of course looked through their docs for an answer before asking it here, but nothing relating to POSTs being moved as CoR has answered is described. I will post (😉...😪) answer on here when they get back to me.
Okay! Finally got it! After one of the super awesome Heroku team getting back to me in like 10 mins, it turned out to be a silly error.
My form was sending it's request to http://MYAPP.heroku.com, whereas one's Heroku app is actually at http://MYAPP.herokuapp.com. That's all. So obviously my request was getting moved when it was sent to http://MYAPP.heroku.com.
What's more, when (correctly) using the herokuapp.comdomain, you can send requests over HTTPS, although sending POST requests over HTTP will work fine.
The SLL Add-On is only if you have a custom domain and would like to enable SSL for it.
It took me few days to chew url redirection to understandable definitions.
Here they are:
301 – Permanently moved: breaks POST
302 – Temporarily moved: legacy, will change POST to GET
303 - Temporarily moved: WILL change POST to GET
307 - Temporarily moved: NOT change POST to GET
EDIT:
it appears that this moving of POST requests only happens if you're
not making them via https.
Yes, I forgot that people are using redirections usually to unify trailing slash, www. AND enforce http or https protocol.
As you might have guesses 301 or 302 redirections can break POST. Fix it by using 307 or write to website admin and he may or may not 'fix it'.
It depends if it will break something else, or maybe that website want to force it users to always use https! In that case 301 is desirable solution because sending POST over unsecure http protocol is automatically discarded/transformed to GET request.
It doesn't matter if server is using https if for example first login data was send by http.
It would of course be nice to know if one can enable POST requests on
their Heroku app without setting up SSL.
Although technically possible, it is valid server policy to disable POST over http and enforce it to use only https.
Related
I have a problem with my Laravel 9.x App (modifying from Laravel Breeze by switching from Tailwind to Bootstrap 5). Everything works fine in local, nothing serious happen. But when I deploy it on DO Server, the problem begin. The problem is, I got 419 Page Expired after doing a POST request (Login/Register/Logout) at a certain time. However, sometimes it works fine, I can register & login, but when I'm try to logout it returns 419 Page Expired. I've checked every single form to put #csrf and I still got 419 Page Expired. Then I'm trying to comment out the \App\Http\Middleware\VerifyCsrfToken::class on my live server, and every POST request works fine BUT, it didn't generate login session for me. Any ideas to fix this issue?
Then I'm trying to comment out the \App\Http\Middleware\VerifyCsrfToken::class on my live server, and every POST request works fine BUT, it didn't generate login session for me.
This sounds like you site isn't using HTTPS and the browser is discarding the cookies in between the requests. This can also happen if you are using HTTPS but posting to HTTP (or vise-versa).
This behavior is expected if the cookie is set with the Secure flag. I've also seen some browsers do this anyway even if the Secure flag is not set.
In Laravel, this feature is not enabled by default. It is enabled via the .ENV variable called SESSION_SECURE_COOKIE being set to true. You can see this yourself by checking the config/session.php file.
This is a good feature to have enabled.
If you have setup any CORS (Cross-Origin Resource Sharing) policies then you may want to make sure they are not blocking parts of the request as it can have a similar effect. Something like https://www.example.com is not considered the same as https://example.com if a wildcard was not used when defining the CORS policy. These policies are a bit in-depth, so if none of this sounds familiar then you probably don't have one at all. If unsure, an easy way to check is to look at the developer console in your browser. They typically complain in red text about something being blocked by CORS if it is happening.
I am developing an application in IONIC. I am making a $http.get request in Angular JS and its giving me 404 error when I successfully login and trying to load the user profile using the token sent in the authentication header.
It produces error in chrome, although I enabled CORS. Please check the screenshot:
Now if I try the url in POSTMAN, everything is ok. See the screenshot below:
I am stuck with this error, can someone help me?
What Ionic says
There are two ways to solve the issue: The first, and easier, solution is to just allow all origins from your API endpoint. However, we can’t always control the endpoint we are accessing. What we need, then, is a request that does not specify an origin.
We can do this by using a proxy server. Let’s look how the Ionic CLI provides
Reference
What works but isn't completely good to use
A simple solution is just add a CORS plugin into your browser and everything will work.
Plugin Link
Proxy server
If you want a proxy server there is this tutorial:
Link
I am making a page that responds to an AJAX request with a certain string when another certain string is provided as a GET variable. In order to avoid problems with the "same origin" policy, I have found that I can include this line of PHP at the top of the page:
header('Access-Control-Allow-Origin: *');
There's no sensitive data being passed whatsoever, it's actually keywords passed back and forth from several different domains, (its an SEO related application). Due to this, hundreds of different domains will be using it, so if possible I would like to avoid specifying each one. Are there any risks to using this line? If so, what are they?
Also, if this page was located under an HTTPS URL is it still accessible?
Any advice, suggestions or concerns are most welcome. Thank you!
If the access truly is public, I'd say this is a good solution. However, if you want to limit the access to your site, you'll probably want to list explicitly each domain origin allowed.
Since you say your response doesn't include any sensitive information, you probably don't need to worry about hosting your service over HTTPS. The one reason you might is if a client HTTPS page tries to access your non-HTTPS service. In that case, I would guess they'd get a warning about unsecure information being sent/received when your AJAX service is called, and maybe even just a silent fail. If this is a common enough case, then I'd say looking into the HTTPS service. Make sure your HTTPS certificate is certified properly, because if the client's browser cannot verify the certificate the AJAX request will silently fail (as opposed to prompting when you navigate directly to an HTTPS page)! Also, I don't know how it will go in your case, but whenever I've worked with HTTPS, I've usually had to tweak things to get them to function properly.
Long story short, I'd start with HTTP and then evaluate the need of HTTPS. Good luck!
So I was asked to look at reconstructing a section of a website which I didn't build. One of the issues I'm running into is a contact form which is being loaded through an iFrame from another server. Obviously, the form's action submits to the other server, and the information is stored in a database for the client to see later.
I've never had to deal with something like this before and I'm wondering if I need to go through some sort of API the host may be able to provide, or can I recreate the form so I can style it and just have it submit to the same server. Sorry for the noob level of this question, but I'm just looking to be pointed in the right direction.
While what you are planning to do, technically works (I have done it myself on several occasions), it is possible the remote host might reject POST data from locations other than itself.
For example, if your site is running at www.example.com and the host site is running www.host.com The server running at host.com will be able to determine if you are sending POST data from example.com. This again, is only a problem if they are cross site checking.
Since you don't have access to their server to know, you will just have to try it and see.
Actually, this type of reject might or might not happen: Since a server needs to read the referrer to reject, but the referrer isn't sent by each and any browser.
Additionally, beware of protection mechanisms like session ids. Or some kind of authorization hash injected into forms as a hidden field.
Just wandering, how is https works? Also how is php able to get the https post? Is it just works like the normal get post in php??
Exmaple:
If there have a system having a https post to a websiet test.php , can I just get the post by using $_POST under test.php?
Yes, the decryption is done by the server's ssl layer automatically.
Yeah. Php doesn't handle the HTTP bs HTTPS. apache does. PHP behaves the same. So to answer your question - yes
Once your server is set up to handle https it's pretty much transparent to apps running on your server. Everything works the same way as HTTP, except the URL scheme and port will be different.
Please try to make questions more clear in the future, reading them yourself again.
For information on HTTPS, why not check wikipedia (or any other source) first?
http://en.wikipedia.org/wiki/HTTPS
HTTPS encrypts the communication between client and server.
Abstract that away and you still have HTTP. Thus, PHP will not even know it was HTTPS that was communicated over (other than protocol, url etc it may ask/check for. but nothing you need to keep in mind when working with it)
So yes, $_POST works with HTTPS just like with HTTP.