I tried to make a post request in Postman (and in PHP) to a url to create a fulfillments, but for some reason, Shopify displays a link stating continue which points me to logging into Shopify.
I looked up the issue and this issue commonly seems to be attributed to cookies, but I disabled cookies and still have this same problem. I also tried with my local PC in docker and I assume the same issue persists.
Try this:
Click the Cookies button right below the request bar:
Remove cookies related to your Shopify store.
Send request again.
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'm trying to add a hosted payment solution to an old Symfony 2.6 project. This is the standard hosted solution where you embed Payment Gateway's form inside an iframe, to allow user to securely submit their CC information. When payment is processed Payment Gateway redirects the user back to my site using GET request and sends me the payment token as GET param.
This all happens inside the iFrame obviously and this whole process works fine, except for the last step.
When user is redirected back to my callback URL inside the iframe, Symfony for some reason doesn't recognize user's session and redirects user to the login. I get message: security.INFO: Populated SecurityContext with an anonymous Token in the log. That happens only for that one call, user remains logged in on the rest of the site. User logins are controlled by fos_userbundle, in the standard setup.
Callback URL looks like this: http://some.site/foo?paymentToken=12345, and if I enter that url directly into the browser it works just fine. Even when I set iframe's src directly to that url it loads fine. But when user is 302 redirect-ed back to that url from the payment gateway it fails (using Chrome browser).
Payment gateway is using https, my site is using regular http, so I guess it has something to do with switching the security levels? But have no idea how to solve it.
Since the redirect comes from the 3rd party server I can't control the headers or anything else about that request.
UPDATE: I've noticed that Chrome sends the header: upgrade-insecure-requests:1, not sure if it's causing the problems?
I can confirm that this is not a Symfony problem, but an issue with how Chrome handles redirects from secure to insecure sites (possibly a bug?).
Chrome doesn't send any cookies on 302 redirect from https to http page, and that's why user is not recognized properly. Everything works fine with Firefox.
This can be also you're testing the app in app_dev.php (developing mode) and the iframe is calling the production verision (app.php). Each application manage different sessions.
I have a strange issue with my Laravel project. Can't find out, when it first started - I can only login/logout opening the app in the incognito tab. And in the normal tab it won't log me out, when I am already logged in and after I deleted the session info in the storage I was unable to ever login.
I have set a SESSION_DOMAIN previously in the env and I faced another issue, unable to login with Laravel Socialite on www.* subdomain. Later I deleted the SESSION_DOMAIN property, because it did not solve the issue.
After some research I found that:
The problem has occurred because I set and SESSION_DOMAIN in the .env file. When I do that during logging in on the local environment, the problem occurs even when I am in the incognito tab. Though I can remove and then reload the incognito pages again, the problem disappears for incognito tabs.
I didn't use Laravel, so might not fully understand how SESSION_DOMAIN should work there, but the problem seems to be due to existing a cookie set on higher domain.
For example, your code is working on domain 'sales.domain.com'. When you create a session in Laravel, it would put a cookie that's valid on that domain. It then can be removed using the same "set cookie" request but with date in the past. This is how it normally works.
But if someone (maybe your code) some time ago also set a cookie with the same name, but valid on all subdomains or '.domain.com', it can't be removed by "set cookie" request that removes it from 'sales.domain.com'.
To check this, use Firebug or Chrome dev tools to see the request header when doing request to 'sales.domain.com' and just 'domain.com'. Note the "Cookie" header. If the same cookie is present on both request, this confirms my guess. You can solve this by clearing cookies in browser.
See also https://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path
Maybe you meet the problem with the subdomain cookie name. If subdomain uses same Laravel framework. Try to change Session Cookie Name in config/session.php to unique name between the main domain and the subdomain.
I experienced the same issue when trying to login to my utility provider to pay by bill online. I tried everything suggested from clearing cookies to the cache and several other suggestions that either did not apply or plain did not work. It wasn't until I started trying different options within settings that I came across my resolution. I thought deleting cookies was the fix until I refreshed the page and/or logged off and tried to login again that I received the blank page with the header "THE SPECIFIED URL CAN NOT BE LOCATED" and once again only worked if I went into incognito mode.
The resolution that fixed this issue completely for me was to go into settings and turn off "DO NOT TRACK". I hope this is helpful to at least one person.
Thank You
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
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.