I'm trying to make a XHR request from my AngularJS instance running on port :8080 to my Structr instance running on port :8082
Thing is, Structr doesn't seem to accept OPTIONS requests on port:8080
Here is the Request header :
OPTIONS /structr/rest/issues HTTP/1.1
Host: localhost:8082
Connection: keep-alive
Cache-Control: max-age=0
Access-Control-Request-Method: GET
Origin: http://localhost:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36
Access-Control-Request-Headers: accept, -hx-password, -hx-user
Accept: */*
Referer: http://localhost:8080/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4,nl;q=0.2
Here is the Response headers from the server:
Access-Control-Allow-Headers:Content-Type
Access-Control-Allow-Methods:GET,PUT,POST
Access-Control-Allow-Origin:http://localhost:8080
Content-Length:44
Content-Type:application/json; charset=utf-8
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Server:Jetty(9.1.4.v20140401)
Set-Cookie:JSESSIONID=1w7n8c71lcbh31s7kwygtat69c;Path=/
The most interesting part IMHO is
Access-Control-Allow-Methods:GET,PUT,POST
I have to say that my understanding of java and HTTP Requests is really sparse so I don't really feel like digging in the source code...
Or maybe it's a simple Angular thing everyone knows but me...
Thanks to Axel Morgner the answer is :
There are two ways to solve it:
1: Let Structr serve also the AngularJS code.
2: Configure the REST > endpoint to accept OPTIONS using a ResourceAccess flag, see docs.structr.org/rest-user-guide#Securing > REST Endpoints.
Beware that when you create a Schema, structr automatically creates new resourceAccess nodes for the new possibles actions.
Related
I have been trying to use the following code using React fetch to get a response from the OpenWeather API:
fetch('api.openweathermap.org/data/2.5/weather?q=Milwaukee&APPID=1234567890')
.then(response => response.text())
.then(data => {
console.log(data)
When I skip react and just copy the url (api.openweathermap.org/data/2.5/weather?q=Milwaukee&APPID=1234567890) into the browser I get a totally valid response. (For example ) When I use the fetch code in my React application, however, I get the following error:
Request URL: http://localhost:3000/api.openweathermap.org/data/2.5/weather?q=Milwaukee&APPID=1234567890
Request Method: GET
Status Code: 431 Request Header Fields Too Large
Remote Address: 127.0.0.1:3000
Referrer Policy: no-referrer-when-downgrade
I am running my react application off localhost from create-react-app. Why can I access that API just fine from my browser but get an error in my app?
Extra Information
In case it is useful here is the link to sign up for a free OpenWeather API
Here is the rest of the information from the response header:
HTTP/1.1 431 Request Header Fields Too Large
x-powered-by: Express
connection: close
date: Wed, 18 Sep 2019 15:45:21 GMT
transfer-encoding: chunked
Or from the request header:
GET /api.openweathermap.org/data/2.5/weather?q=Milwaukee&APPID=1234567890 HTTP/1.1
Host: localhost:3000
Connection: keep-alive
Sec-Fetch-Mode: cors
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36
Accept: */*
Sec-Fetch-Site: same-origin
Referer: http://localhost:3000/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,es-US;q=0.8,es;q=0.7,ar-JO;q=0.6,ar;q=0.5
(My APPID is fake in all these examples, so the request won't work by just copying and pasting what I have)
It's a pretty "catchy" bug - you are missing http:// in front of your url, so:
fetch('https://api.openweathermap.org/data/2.5/weather?q=Milwaukee&APPID=1234567890')
Since you've missed it, url is resolved to this (you can see it in your Network tab):
http://localhost:3000/api.openweathermap.org/data/2.5/weather?q=Milwaukee&APPID=1234567890
I'm writing the client-side of an app with ReactJS, I'm stuck at getting data from a certain api. I get "No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access" error.
As I suppose the server is missing the "Access-Control-Allow-Origin" headers in order to enable CORS but what I don't understand is why when I'm trying to make an AJAX call with "Restlet Client - REST API testing" browser extension it actually works. I get a following success response. But It doesn't work inside my actual React Request. Is there a way I can to get rid of this error without any changes on the server side? Why does this extension actually work?
Connection: keep-alive
Content-Type: application/json; charset=UTF-8;
Date:
2017 Sep 22 22:45:40-1m 50s
Server: ..../1.6.2
Transfer-Encoding: chunked
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
My React code but nothing special in there, just testing if I'm getting a response
componentWillMount() {
const url = "https://myserver.ru/api/issue?perPage=10";
Request.get(url).then((response) => {
this.setState({
issues: response
});
});
}
If you are making a cross-site requests then browser will expect Access-Control-Allow-Origin headers from the server. The value of that header can be,
Access-Control-Allow-Origin: *
or
Access-Control-Allow-Origin: http://localhost:3000
When you are requesting from localhost, make sure it also need to add port number as well.
More about CORS documentation:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Hope it helps.
I was trying to POST my login credentials for one of my app built with Cordova and AngularJS. When I login from my browser, it works fine but when test the same in Android (also tested in iOS too, fails on both), the login fails and I get the following headers while debugging.
I saw the differences in these two headers, as in emulator the origin is
Origin: file://. It also has a warning sign for emulator saying "Provisional headers are shown"
Why is it failing in emulator and devices but works fine in browsers? Does cordova does anything internally while wrapping up the POST call?
I really don't understand why is it happening in emulators/devices but works fine in browsers.
In Browser - works fine
Remote Address:xx.xx.x.xxx:xxxx
Request URL:http://myEndpoint
Request Method:POST
Status Code:200 OK
Request Headers view source
Accept:application/json, text/plain, */*
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Content-Length:166
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Host:myHost:xxxx
Origin:http://myComputerName.org:xxxxx
Referer:http://myComputerName.org:xxxxx/myAppName/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
Form Dataview parsed
grant_type=mypassword&client_id=1234&client_secret=1234&username=userName&password=mypassword
Response Headersview source
Access-Control-Allow-Credentials:true
Access-Control-Allow-Origin:http://myComputerName.org:xxxxx
Content-Type:application/json;charset=UTF-8
Date:Thu, 12 Mar 2015 15:25:53 GMT
Server:Apache-Coyote/1.1
Set-Cookie:
Transfer-Encoding:chunked
======================================================================
In My Android Emulator --> Failed to login
Request URL:http://myEndpoint
Request Headers
Provisional headers are shown
Accept:application/json, text/plain, */*
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Origin:file://
User-Agent:Mozilla/5.0 (Linux; Android 5.0; sdk_phone_armv7 Build/LRX09D) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/37.0.0.0 Mobile Safari/537.36
X-DevTools-Emulate-Network-Conditions-Client-Id:1234
Form Dataview parsed
grant_type=mypassword&client_id=1234&client_secret=1234&username=myUserName&password=mypassword
I have this little angular app on the frontend which is a food list. So write a food and click submit and it will show the list.
When I add a food I query my backend wich is a sails app at localhost:1337 and it gets updated. The problem is I get redirected to
localhost:9000/#/food and get 404.
This is the faulty request
POST / HTTP/1.1
Host: localhost:9000
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image /webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Content-Type: application/x-www-form-urlencoded
Cookie:sails.sid=s%3A8gIjNxaZVE9dMr7nonXJzEaQ9hUcvcHm.Sp0K6ezep%2F7Y%2BV6TivtdRxqiBV 2S1LdH2IDNPWS9Ikk
Origin: http://localhost:9000
Referer: http://localhost:9000/
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
X-DevTools-Emulate-Network-Conditions-Client-Id: 137B2031-138E-4B6B-A3AE- FB8EE96E9015
HTTP/1.1 404 Not Found
Connection: keep-alive
content-length: 14
Content-Type: text/html; charset=utf-8
Date: Mon, 23 Feb 2015 12:21:51 GMT
X-Content-Type-Options: nosniff
The other request that gets code 200 and update the server model looks like this:
OPTIONS /food HTTP/1.1
Host: localhost:1337
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Access-Control-Request-Headers: accept, content-type
Access-Control-Request-Method: POST
Origin: http://localhost:9000
Referer: http://localhost:9000/
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
X-DevTools-Emulate-Network-Conditions-Client-Id: 137B2031-138E-4B6B-A3AE- FB8EE96E9015
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type, access-control-allow-origin, authorization,X-Requested-With
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
Access-Control-Allow-Origin: http://localhost:9000
Allow: GET,POST,PUT,HEAD,DELETE,TRACE,COPY,LOCK,MKCOL,MOVE,PURGE,PROPFIND,PROPPATCH, UNLOCK,REPORT,MKACTIVITY,CHECKOUT,MERGE,M- SEARCH,NOTIFY,SUBSCRIBE,UNSUBSCRIBE,PATCH,SEARCH,CONNECT
Connection: keep-alive
Content-Length: 175
Content-Type: text/html; charset=utf-8
Date: Mon, 23 Feb 2015 12:21:51 GMT
set-cookie: sails.sid=s%3A_kBdyRZgZ23Gh9YLkZfWBgnMody- jq-S.IY71%2BhJiBxTd19YIG2tgS2EOn1LPT%2BD9QAEQWtVB%2FbE; Path=/; HttpOnly
X-Powered-By: Sails <sailsjs.org>
At first I was looking at sails but I have CORS enabled and everything just like this:
https://github.com/tarlepp/angular-sailsjs-boilerplate/blob/master/backend/config/cors.js
So maybe it's more an angular issue. The request that fails is from the frontend to itself so just a redirect on itself when it has been updated on the server. I don't get why the request is denied...
If you want to take a look at the code:
http://okamuuu.hatenablog.com/entry/2014/04/10/135240
Issues seem the same as this Yeoman, Grunt, AngularJS and error 404 on POST form but that doesn't help me
Well, apparently your request is going to the port 9000:
Host: localhost:9000
Yet you said your app is running at port 1337.
So, in your $http requests, you need to specify the port. Otherwise, it will use the port your browser is currently connected to (9000) and there's no app there!
So, instead of
$http.get('/someUrl')
Try
$http.get('http://localhost:1337/someUrl')
I built a oData-Service which works well.
Now I want to query them with Breeze but I always get an 404 error.
In Fiddler I see first a 200 with empty Body and then follows the 404 with "No HTTP resource was found that matches the request URI".
But running in a normal browser the odata Service delivers the right data.
I debug it and set a breakpoint on the Server to see if the service is called correctly. After sending the request the breakpoint shows that the Service is called. But parallel to the break breeze calls the fail-method of
manager.executeQuery(query)
.then(querySucceeded)
.fail(queryFailed);
and e.message is empty.
Any idea??? :-/
Next entry...
I deactivate CORS and now I get the 404 immediately.
Here is the request:
OPTIONS xxx:8080/myDataService/odata/Person?$select=Name HTTP/1.1
Host: xxx:8080
Connection: keep-alive
Access-Control-Request-Method: GET
Origin:localhost:61244
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36
Access-Control-Request-Headers: dataserviceversion, accept
Accept: /
Referer: http://localhost:61244/index.html
Accept-Encoding: gzip, deflate, sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
and here the answer:
HTTP/1.1 404 Not Found
Content-Length: 178
Content-Type: application/json; odata.metadata=minimal
Server: Microsoft-HTTPAPI/2.0
OData-Version: 4.0
Date: Mon, 19 Jan 2015 12:11:48 GMT
{
"error":{
"code":"","message":"No HTTP resource was found that matches the request URI xxx:8080/myDataService/odata/Person?$select=Name'."
}
}
No surprise that the OPTION request passes; you've probably got the server set to say "OK" to every request ... and that's just fine for now.
The rejection has to do with the address of your GET request: xxx:8080/myDataService/odata/Person. Are you sure that's the right endpoint? The path is usually plural (Persons).
It's easy enough to just paste that url into a browser address bar and see what it does.