My Google compute engine virtual machine is hosting apache which is serving my website. When my website sends a post request to http://localhost:8080 It returns a 404, even though the (golang) server running in the file over can see url get requests.
I've tried adding Apache proxy all / calls to that server, But this seems to only work on Get requests put into the url.
To show that my server can see GET requests
[negroni] 2019/10/23 08:29:27.048676 Started GET /api/v1/login
[negroni] 2019/10/23 08:29:27.048941 Completed 404 Not Found in 262.947µs
While i need to be able to have it see the POST request
(axios.post('/api/v1/login', {username, password}))
Full request looks like
http://localhost:8992/api/v1/login
Here is the 'General' section of chrome Devtools Network
Request URL: http://localhost:8992/api/v1/login
Referrer Policy: no-referrer-when-downgrade
Here are the Request Headers
Provisional headers are shown
Access-Control-Request-Headers: content-type
Access-Control-Request-Method: POST
DNT: 1
Origin: https://carterstestdomain.store
Sec-Fetch-Mode: cors
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36
Any help is greatly appreciated.
Fixed this by following
Apache and Node.js on the Same Server
Also, As with me, The problem could be comming from the request being http instead of https :)
Related
I have an API built on CakePHP. It works for the most part but every once in a while browser access to the API dies. The error message on the XHR request response is:
'Access to XMLHttpRequest at 'http://be:8888/api/pings' from origin 'http://localhost:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
However if I make exactly the same request via POSTMAN (or if I browse directly to the URL, rather than via XHR) it works without any trouble. I thought it might be a pre-flight OPTIONS issue but the request headers don't list a Request Method and the Apache access log shows these to be GET requests. There's nothing related in the Apache error log.
Restarting MAMP – i.e. Apache – does not fix the issue, nor does flushing the local DNS cache. The only thing that fixes it is a restart, after which it all works fine again for a few hours before eventually going on the blink again.
I can't think of what's causing this. I don't think it's a true CORS middleware error because the restart fixes it and the API is accessible normally. Also if I put a die in during the CORS middleware __invoke method it doesn't get that far (the die in the webroot index should be hit first anyway).
I get this error even if I disable the app by putting die('here'); at the start of the webroot index.php file.
Even if I delete the index.php files (both in the project root and webroot) so that browsing to the URL shows Apache's default error 404 not found: The requested URL /webroot/index.php was not found on this server, I still get the CORS errors when trying via XHR in the browser.
I've only noticed this issue since upgrading to Mac OS X Catalina.
What could be causing this?
[Update:]
Here's proof that it is working in the browser after a system restart:
Summary
URL: http://be:8888/api/clients
Status: 200 OK
Source: Network
Address: ::1.8888
Request
GET /api/clients HTTP/1.1
Accept: application/vnd.api+json
Content-Type: application/vnd.api+json
Origin: http://localhost:8080
Accept-Language: en-gb
Access-Control-Allow-Origin: *
Host: be:8888
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.5 Safari/605.1.15
Referer: http://localhost:8080/
Accept-Encoding: gzip, deflate
Connection: keep-alive
However, after a few hours it stops working. If it was actually a CORS issue my understanding is that it would NEVER work.
I'm not an Apache/PHP professional, but make sure you query HTTPS via HTTPS and http via http, other words, both sides should be same. Also, check the request header. And add "access-control-origin" in request header.
We are seeing random letters appear in access logs. The requests 404 since the content does not exist. The requests are made by a variety of users and other requests from the same ip usually look genuine. There is no way to request these from the site. Some of these requests even appear from internal traffic on our network.
Example:
157.203.177.191 - - [04/Feb/2018:23:51:20 +0000] "GET /VLTRP/content/dam/example/dotcom/images/ABtest/existing-customer-thumb.jpg HTTP/1.1" 404 60294 39082 "http://www.example.com/shop.html" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0" 2
Without the /VLTRP this is a genuine request. Has anyone seen something similar before?
For info we are running Apache/2.2.15 (Unix) with ModSec enabled. We do see similar behaviour on another site where we do not have ModSec configured. We see similar requests for internal, external and bot traffic.
I've got a Laravel 5.4 API, that works fine in Postman and the Browser. Localhost works fine- Laravel 5.4 is running on one port, and Vue in hot deploy mode is running fine.
However, when I move the Vue code to my production server I get this error:
Response for preflight is invalid (redirect)
In Chrome Developer Tools, the network tab shows this:
General
Request URL:http://backend-dev.xolas.io/api/v1/view/calendar/-30/90/
Request Method:OPTIONS
Status Code:301 Moved Permanently
Remote Address:217.182.66.247:80
Referrer Policy:no-referrer-when-downgrade
Response Headers
Connection:Keep-Alive
Content-Length:349
Content-Type:text/html; charset=iso-8859-1
Date:Mon, 10 Jul 2017 13:40:08 GMT
Keep-Alive:timeout=5, max=100
Location:http://backend-dev.xolas.io/api/v1/view/calendar/-30/90
Server:Apache/2.4.25 (Ubuntu)
Origin Headers
Accept:*/*
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:access-control-allow-origin,authorization
Access-Control-Request-Method:GET
Connection:keep-alive
Host:backend-dev.xolas.io
Origin:http://localhost:8080
Referer:http://localhost:8080/
User-Agent:Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.109 Mobile Safari/537.36
I've installed a CORS plugin on Laravel, still no joy.
My axios config is as follows:
axios.defaults.headers.common['Authorization'] = store.apiKey
axios.defaults.headers.get['Content-Type'] = 'application/json;charset=utf-8'
axios.defaults.headers.post['Content-Type'] = 'application/json;charset=utf-8'
axios.defaults.headers.common['Access-Control-Allow-Origin'] = 'https://' + store.endpoint + ', http://' + store.endpoint
Endpoint is Larvel API server, which works fine.
Any clues would help, since I'm at a loss on how to resolve this. Thanks in advance.
The server is is sending a redirect from:
http://backend-dev.xolas.io/api/v1/view/calendar/-30/90/
to:
http://backend-dev.xolas.io/api/v1/view/calendar/-30/90
Removing the trailing '/' in your request should prevent the 301. (Although that url is responding with a 500 Server Error.
Your browser’s sending a CORS preflight OPTIONS request before trying whatever request it is that your code’s actually trying to send itself, and then your Laravel backend is responding to that OPTIONS request with a 301 Moved Permanently redirect.
The server must respond to the OPTIONS preflight with a 2xx status — typically 200 or 204.
If the server doesn’t do that, the preflight fails and the browser never tries the actual request.
So you must change your Laravel backend to respond to that OPTIONS with a 200 or 204.
And the browser does a preflight to begin with because your request adds Authorization and Content-Type: application/json;charset=utf-8 & Access-Control-Allow-Origin headers.
You should remove the code that’s adding the Access-Control-Allow-Origin there, because that’s a response header and there’s never any need to send it in a request. But assuming you need the Authorization and Content-Type headers in the request in order for it to actually work as expected with your backend, then there’s no way you can avoid the browser preflight.
So you really must configure your Laravel backend to respond to OPTIONS with a 2xx success.
The specific scenario I'm dealing with is attempting to connect to a websocket connection behind an AWS elastic load balancer, whilst enforcing https/ssl rather than http/tcp.
To enable the TCP/SSL upgrade from http/s, the protocol on the load balancer has necessarily been set to TCP rather than HTTP on port 80 and SSL rather than HTTPS on 443, both of which are forwarded onto the instance port of 80 using TCP.
However, a side effect of setting the protocol to TCP/SSL is that the x-forwarded-proto header no longer gets set, as experienced here:
Amazon Elastic load balancer is not populating x-forwarded-proto header
This makes the next challenge of 301ing any incoming requests using http/tcp to https/ssl somewhat problematic, as this typically relies on the inspecting the x-forwarded-proto header.
A little more detail on the specifics of the situation: there exists a docker container with a Meteor.js process running inside of it, which resides in turn within an AWS Elastic Beanstalk Application (which has an Nginx proxy layer by default, but this isn't accessible due to the use of docker which simply pulls a container definition from docker hub), which sits behind the aforementioned ELB.
Ultimately I'm left inspecting the headers that I have available to my application by the time the request has gone through the ELB, Nginx and docker agent layers, trying to work out if the original request made by the client started with http or https
Incoming https:// request headers:
{
host: 'whatever.elasticbeanstalk.com',
'x-real-ip': '999.99.99.99',
'x-forwarded-for': '999.99.99.99',
'cache-control': 'max-age=0',
accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
'upgrade-insecure-requests': '1',
'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36',
'accept-encoding': 'gzip, deflate, sdch',
'accept-language': 'en-US,en;q=0.8'
}
Incoming http:// request headers:
{
host: 'whatever.elasticbeanstalk.com',
'x-real-ip': '999.99.99.99',
'x-forwarded-for': '999.99.99.99',
'cache-control': 'max-age=0',
accept: 'image/webp,image/*,*/*;q=0.8',
'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36',
'accept-encoding': 'gzip, deflate, sdch',
'accept-language': 'en-US,en;q=0.8',
'if-none-match': '"141699-1446507991000"',
'if-modified-since': 'Mon, 02 Nov 2015 23:46:31 GMT'
}
The only one of these that looks vaguely useful is the upgrade-insecure-requests header, but based on this
What is the "Upgrade-Insecure-Requests" HTTP header?
I'm pretty sure it's not.
Maybe I'm missing something however...
If the question is in fact "How can I ensure anyone visiting my website via http is redirected to https/ssl" (as indeed it turned out that this is what I meant), this is possible by
Setting the Elastic Load Balancer to forward HTTP on 80 to HTTP on 80 on the instance (rather than TCP on 80 as it was before) and then forward HTTPS on 443 to TCP on 80 on the instance.
"Assuming HTTPS/SSL" during the detection of the protocol: namely check if there exists an x-forwarded-proto, if it does, it's come from a http request, thus 301 to https. If one doesn't exist, assume it's https, don't redirect it (in practice I felt I might as well check to ensure the protocol was http before redirecting, but in the current set up I'm pretty sure that's the only scenario that can possibly occur).
When you use TCP, the ELB will not inject HTTP headers such as x-forwarded-proto or x-forwarded-for. You may be able to get what you need by configuring Proxy Protocol.
I moved my ModX website from localhost to a development server.
I updated the paths in my config files it seems to be doing fine, the frontend is working properly.
Only issue, when trying to load the manager at http://dev.noculture.asia/manager/, there is a request to connectors/lang.js.php: http://dev.noculture.asia/connectors/lang.js.php?ctx=mgr&topic=topmenu,file,resource,welcome,configcheck&action=
This request returns a 401 Unauthorized error and I have no idea why.
The logs aren't helpful at all:
Modx doesn't log any error, so I am guessing that means the error comes from Apache.
Apache error.log is empty, access.log only tells:
[11/Feb/2014:21:41:10 -0800] "GET /connectors/lang.js.php?ctx=mgr&topic=topmenu,file,resource,welcome,configcheck&action= HTTP/1.1" 401 391 "http://dev.noculture.asia/manager/" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/32.0.1700.102 Chrome/32.0.1700.102 Safari/537.36"
Any suggestion how to fix this?
I realized that a 401 error is related to authentication.
I deleted the cookie for this domain, which destroyed my session. I was asked to login again, and now the manager is working properly.